Patterns prioritaires du Hub

Juin 2025

CR écrit par Arnaud Monnier

La séance avait pour but de discuter et valider les implémentations proposées des patterns prioritaires afin de pouvoir initier les backlogs des équipes d’implémentation.

Présentation technique des patterns

Une présentation illustrative de l’atterrissage technique des patterns a été faite (i.e. les développements logiciels), afin de faciliter la visualisation et la compréhension de tous les participants.
Notamment, les sujets suivants ont été abordés :

• Gestion du chargement de données incluant de multiples fonctionnalités, telles que les contrôles techniques des contrats d’interface, la gestion des rejets et quotas de rejets.
• Gestion des réconciliations au niveau des tables pour chaque flux (et non pas au niveau de plusieurs sources fonctionnelles entre elles), avec des algorithmes spécifiques pour des modes FULL et toutes les variations de DELTA (APPEND, INCREMENTAL, etc.).
• Data Flow Catalog : contrats d’interface (modèle d’échange) pour les flux se traduisant par des ingestions en Table.
• Note : le thème du « Flow Catalog » et des contrats d’interface fera l’objet d’un ou plusieurs ateliers dédiés.

Priorisation des patterns

• La logique de priorisation des patterns du Hub est partagée en séance, et ne génère pas d’objection : la priorisation est validée.
• Patterns prioritaires :
  • P0, Patterns fichier (EBCDIC, CSV) : couvrant une grande partie des flux existants vers l’infocentre Dommages développé en SAS.
  • P0, Pattern CDC tactique : pour couvrir les besoins de réplication temporaires des DWH et Datamarts Vie vers BigQuery afin de démarrer la traduction des usages SAS Vie.
  • P1, Pattern « Connexion Directe » : associé aux patterns Fichier en P0, permet de gérer des extractions des bases opérationnelles Oracle et DB2, réalisées par le hub pour le compte.

Orchestration de domaine

Dans tous les slides visuels déclinant les patterns, le logo d’Airflow doit être interprété comme « Airflow ou Kestra » tant que la décision finale sur l’orchestrateur de Domaine Data n’est pas finalisée.

Détail des Patterns « Fichiers »

• Les patterns d’acquisition de fichier, avec espace de partage géré par le hub ou par le partenaire source, sont validés.
• Seules les déclinaisons pour des sources on-premise sont prioritaires à ce stade.
• La roadmap du pattern Fichier, qui prévoit de développer en premier lieu les patterns sans capacité de rejeu, est également validée.
• Le sous-pattern pour le chargement des fichiers EBCDIC, s’appuyant sur une asset Google, est également validé, malgré le fait qu’il stocke des fichiers intermédiaires ORC plutôt que PARQUET.
• Cette validation est faite sous 2 réserves :
  1. Que les tests fonctionnels soient concluants ou que Google soit en mesure d’adresser les évolutions requises dans un temps compatible avec le planning projet.
  2. Hichem Beddiaf et Yannick Gaudin ajoutent une seconde réserve : la vraie préférence serait de ne pas avoir à consommer de l'EBCDIC en direct.
     Il faut prévoir l’implication des équipes Source Pacifica, pour évaluer leur capacité à retravailler leur flux afin de fournir d’autres formats qu’EBCDIC.

Ingestion fichier en mode « évènementiel »

• Ce mode permet d’effectuer des chargements de fichier individuels au moment de leur mise à disposition sans attendre un scheduling spécifique, et peut lisser les besoins de compute.
• Néanmoins, une déclinaison telle que celle proposée en séance, qui bypasserait l’ordonnanceur Airflow/Kestra, complique l’observabilité (i.e. nécessite des travaux plus aboutis sur l’observabilité de N systèmes).
• Également, il empêche de mettre en place des algorithmes efficients de réconciliation de table en mode multi-fichier (N fichiers ingérés = N réconciliations, au lieu d’1 réconciliation globale en mode non-évènementiel), s’appuyant sur les pipelines quotidiens.
• Finalement, il devra être implémenté « on-premise » et non dans le cloud, et devra donc s’appuyer sur une intégration des triggers de Minio plutôt que des intégrations natives GCS et des cloud functions de Google, rendant l’implémentation plus longue.

Orientations validées du dossier Hub de CAA

• O1 : Favoriser les ordonnanceurs de domaine Data plutôt que TWS/OPC — Validé
• O3 : Mode d’utilisation de CFT et alimentations en Y — Validé
• O6 : Gestion des rejets dans le Hub — Validé
• O7 : Favoriser les formats natifs des lakehouses choisis (i.e. charger directement dans BigQuery sans autre format « table » intermédiaire) — Validé
• O8 : Toutes les couches RAW/ENHANCED/OPTIMIZED sur le même hébergement — Validé
• O9 : Le hub gère l’efficience des mouvements de données inter-hébergement — Validé

Orientations à discuter lors d’ateliers spécifiques

• O2 : Favoriser Airflow en tant qu’orchestrateur [en cours, choix de solution détaillé]
• O4 : Hébergement de l’orchestrateur programmable [à planifier]
• O5 : Favoriser l’événementiel, en particulier pour notifier les Domaines cibles de la fin des ingestions [à planifier]

Détail des patterns d’acquisition en « Connexion Direct » aux DBs et APIs

• L’acquisition en Connexion directe étend les capacités des patterns Fichiers (i.e. les données sont sauvegardées en PARQUET sur la couche intermédiaire avant d’être chargées en lakehouse comme les autres types de fichier) — Validé
• Pour des flux legacy issus de connexion directe aux DB opérationnelles effectuées par l’ETL Informatica, nous nous interfacerons avec Informatica par échange de fichier tant que ses pipelines ne sont pas dans le périmètre des migrations de code — Validé
• Cas spécifique des fichiers SAS7BDAT — Validé
  1. Nous favoriserons des accès à SAS via ODBC [update : driver ODBC SAS, disponible pour l’infocentre PACIFICA, mais pas sur les clusters SAS de PREDICA] afin de laisser à SAS la responsabilité de lire son propre format.
  2. Dans tous les cas, des convertisseurs et loaders « Tactiques » de fichier SAS vers BigQuery devront être créés en soutien du chantier 2. Nous pourrons réutiliser ce code lors des phases de migration de