You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pas prioritaire mais je pose ça là pour réflexion futures
Le traitement ETL intégrant le calcul des metrics, prend déjà pas mal de temps, environ 1h pour 10 jours de données de juin 2024. il y a peut être des optimisations qui pourraient améliorer le temps de calcul mais en l'état on peut que prévoir que ce temps va augmenter avec le temps et les futurs traitement ETL
J'identifie deux cas au moins ou cela pourrait poser problème:
l'intégration d'un complément de positions spire pour boucher des trous de positions liés à des problème de récupération des positions spire sur le endpoint des positions live. c'est déjà arrivé suite à un disque full, cela pourrait arriver pour d'autres raisons et pour un temps potnetiellement significatif car le process n'est pas vraiment supervisé actuellement. Dans ce cas il est toujours possible de demander un dataset au prestataire pour récupérer les données manquantes reste que l'intégration des ces données et leur insertion dans des données pré-existantes n'est pas forcément prévu et aisé à l'heure actuelle
le recalcul complet des données calculées et statistuqes suite à une évolution majeure sur pour laquelle nous souhaiterions retraiter un historique conséquent de données dans le passé.
Ces deux cas de figure nécessitent actuellement la suppression de tout ou partie des données calculée et engendre un temps de recalcul potentiellement de plusieurs jours. Plusieurs pendants lesquels il ne seraient potentiellement pas possible d'avoir des données récentes
L'introduction d'un traitement pas lot borné (timestamp start, timetstamp end) permettrait de venir insérer les données manquante sur une période donnée tout comme retraiter de manière progressive toutes les données avec de nouveau algorithmes sans avoir de coupure de service ni de données
Ce traitement par lôt implique par contre que le traitement ETL doit savoir venir insérer et/ou mettre à jour des positions/segments/exursions déjà existantes et assurer la continuité des données pré-existante. Globalement il faut modifier l'ETL pour qu'il prennent on compte les données passées comme les données futures par rapport à sa fenêtre de date de traitement par lôt
Ce n'est pas une évolution prioritaire mais c'est quelques chose qui permettrait de gagner pas mal en robustesse du traitement ETL et qualité/complétude des données tout en maintenant un service continu.
A méditer donc
The text was updated successfully, but these errors were encountered:
rv2931
changed the title
[ETL] introduire un traitement par lôt borné sur données existantes
[BACLEND] introduire un traitement par lôt borné sur données existantes
Dec 11, 2024
rv2931
changed the title
[BACLEND] introduire un traitement par lôt borné sur données existantes
[BACKEND] introduire un traitement par lôt borné sur données existantes
Dec 11, 2024
Une meilleure stratégie plus simple finalement, même beaucoup plus simple, ça serait de créer des lots par mmsi ou par ordre alphabétique
Ça traitera pas petit lot mais par contre ça traitera les positions sur toutes la période rapidement, lot de bateau par lot de bateau. On peut donc envisager de supprimer les données liées à un bateaux complètement et recalculer ses données entièrement
Je vais faire un test avec un bateau qui bcp d'excursions voire combien de temps ça prend
Pas prioritaire mais je pose ça là pour réflexion futures
Le traitement ETL intégrant le calcul des metrics, prend déjà pas mal de temps, environ 1h pour 10 jours de données de juin 2024. il y a peut être des optimisations qui pourraient améliorer le temps de calcul mais en l'état on peut que prévoir que ce temps va augmenter avec le temps et les futurs traitement ETL
J'identifie deux cas au moins ou cela pourrait poser problème:
Ces deux cas de figure nécessitent actuellement la suppression de tout ou partie des données calculée et engendre un temps de recalcul potentiellement de plusieurs jours. Plusieurs pendants lesquels il ne seraient potentiellement pas possible d'avoir des données récentes
L'introduction d'un traitement pas lot borné (timestamp start, timetstamp end) permettrait de venir insérer les données manquante sur une période donnée tout comme retraiter de manière progressive toutes les données avec de nouveau algorithmes sans avoir de coupure de service ni de données
Ce traitement par lôt implique par contre que le traitement ETL doit savoir venir insérer et/ou mettre à jour des positions/segments/exursions déjà existantes et assurer la continuité des données pré-existante. Globalement il faut modifier l'ETL pour qu'il prennent on compte les données passées comme les données futures par rapport à sa fenêtre de date de traitement par lôt
Ce n'est pas une évolution prioritaire mais c'est quelques chose qui permettrait de gagner pas mal en robustesse du traitement ETL et qualité/complétude des données tout en maintenant un service continu.
A méditer donc
The text was updated successfully, but these errors were encountered: