Je constate un problème dans le comportement du traitement clean_positions.
Je pars d'une base "vide", c'est-à-dire ne comportant des données uniquement dans les tables dim_vessel, dim_port et dim_zones.
La table spire_ais_data est également chargé avec un historique de 9623017 entre le 11/04 et le 17/06.
1er lot
La première exécution du traitement clean_positions s'exécute sur un lot d'une semaine (du 11/04 au 18/04):
[bloom INFO @ 08:35:50] DEBUT - Nettoyage des positions
[bloom INFO @ 08:35:50] Lecture des nouvelles positions de Spire en base
[bloom INFO @ 08:36:00] Traitement des positions entre le 2024-04-11 21:20:02.512986+02:00 et le 2024-04-18 21:05:03.201126+02:00
[bloom INFO @ 08:36:00] 1008757 nouvelles positions de Spire
[bloom INFO @ 08:37:12] Ecriture de 1008085 positions dans la table vessel_positions
[bloom INFO @ 08:38:33] FIN - Nettoyage des positions en 163.49s
=> 1008085 positions chargés dans la table vessel_positions
L'exécution du traitement create_update_excursions_segments sur ce lot donne le résultat suivant:
[bloom INFO @ 08:43:28] DEBUT - Création / mise à jour des excursions et des segments
[bloom INFO @ 08:43:28] Lecture des nouvelles positions depuis le 1970-01-01 00:00:00+00:00
[bloom INFO @ 08:43:44] 1008085 nouvelles positions
[bloom INFO @ 08:43:44] Création des excursions
[bloom INFO @ 08:46:24] 4067 excursion(s) créées
[bloom INFO @ 08:46:24] 3137 excursion(s) cloturés
[bloom INFO @ 08:46:24] Création des segments
[bloom INFO @ 08:47:20] 226627 segment(s) créés
[bloom INFO @ 08:47:42] Mise en relation des segments avec les zones et calcul des statistiques d'excursion
[bloom INFO @ 08:48:51] 4067 excursions mises à jour
[bloom INFO @ 08:55:39] 226627 segments mis à jour
[bloom INFO @ 08:55:40] 12987 associations(s) créées
[bloom INFO @ 08:55:46] 4067 derniers segments mis à jour
[bloom INFO @ 08:55:47] FIN - Création / mise à jour des excursions et des segments en 739.13s
==> à partir des 1008085 présentes dans vessel_positions, le traitement créé 226627 segments et 4067 excursions
2ième lot
Le deuxième lot traite la semaine suivante d'historique du 18/04 au 25/04. L'exécution du traitement clean_position donne le résultat suivant:
[bloom INFO @ 09:01:31] DEBUT - Nettoyage des positions
[bloom INFO @ 09:01:31] Lecture des nouvelles positions de Spire en base
[bloom INFO @ 09:01:41] Traitement des positions entre le 2024-04-18 21:05:03.201126+02:00 et le 2024-04-25 21:05:03.159649+02:00
[bloom INFO @ 09:01:41] 1006195 nouvelles positions de Spire
[bloom INFO @ 09:08:01] Ecriture de 2497942 positions dans la table vessel_positions
[bloom INFO @ 09:12:21] FIN - Nettoyage des positions en 650.27s
=> Problème: le traitement lit 1006195 enregistrements à partir de spire_ais_data mais génère 2497942 enregistrements dans vessel_positions
Le traitement ne devrait générer qu'au maximum autant de données que lues dans spire_ais_data. J'ai l'impression que le traitement réalise une jointure et génère des enregistrements en double. A analyser
Je constate un problème dans le comportement du traitement
clean_positions
. Je pars d'une base "vide", c'est-à-dire ne comportant des données uniquement dans les tablesdim_vessel
,dim_port
etdim_zones
. La tablespire_ais_data
est également chargé avec un historique de 9623017 entre le 11/04 et le 17/06.1er lot
La première exécution du traitement
clean_positions
s'exécute sur un lot d'une semaine (du 11/04 au 18/04):=> 1008085 positions chargés dans la table vessel_positions
L'exécution du traitement
create_update_excursions_segments
sur ce lot donne le résultat suivant:==> à partir des 1008085 présentes dans vessel_positions, le traitement créé 226627 segments et 4067 excursions
2ième lot
Le deuxième lot traite la semaine suivante d'historique du 18/04 au 25/04. L'exécution du traitement clean_position donne le résultat suivant:
=> Problème: le traitement lit 1006195 enregistrements à partir de
spire_ais_data
mais génère 2497942 enregistrements dansvessel_positions
Le traitement ne devrait générer qu'au maximum autant de données que lues dans
spire_ais_data
. J'ai l'impression que le traitement réalise une jointure et génère des enregistrements en double. A analyser