Projets / agentic-file-ingestion
Ingestion agentique de fichiers et migration d'un ETL legacy
Remplacement d'un parc ETL legacy par PySpark en conservant le lineage, et un flux d'ingestion où un agent en sandbox écrit des loaders pour les formats de fichiers inconnus.
- Période
- 2026
- Rôle
- Tech Lead Data & IA, avec deux développeurs
- Contexte
- Grande société de services avec un parc de données legacy
- Cloud
- AWS
[ Architecture ]
Comment ça marche
Lancez un scénario pour suivre une requête à travers le système. Sélectionnez un composant pour lire son rôle et ses flux.
un partenaire
Export mensuel avec une feuille renommée
Le même export que le mois dernier, mais une feuille et deux en-têtes de colonnes ont été renommés.
export.xlsx
- Appuyez sur Envoyer un fichier à nouvelle structure pour suivre la requête à travers le système.
- 01PartenaireEnvoie le fichier mensuel
- 02Boîte mail & fileFichier stocké tel quel · tâche en file
- 03Détecteur layoutSignature différente de tous les loaders approuvés
- 04Agent de codeLoader candidat et tests écrits à partir d'un échantillon
- 05Checks & validationContrôles OK · l'opérateur valide · fichier rejoué
- 06PublicationPublié de façon atomique · lineage écrit
- ✓Le fichier est publié et la nouvelle structure devient un loader approuvé : la prochaine fois, aucun modèle n'est nécessaire.
- 01PartenaireEnvoie le fichier mensuel
- 02Boîte mail & fileFichier stocké tel quel · tâche en file
- 03Détecteur layoutSignature identique à un loader approuvé · aucun appel au modèle
- 04PublicationPublié de façon atomique · lineage écrit
- ✓Le fichier est chargé et publié sans aucun appel au modèle.
Problème
Un outil ETL legacy doit être remplacé par PySpark dans le cloud sans perdre la trace des jobs qui alimentent chaque table. Par ailleurs, des fichiers clients arrivent par e-mail avec des formats qui changent, et chaque changement casse un chargement.
Données
Les définitions des jobs legacy, le catalogue des tables, des baselines de sortie figées et des exemples de fichiers clients. Rien ne sort de l’environnement du client.
Approche
- Les jobs sont analysés pour reconstruire le lineage entre jobs et tables, puis du code PySpark en est généré et complété par un agent.
- Un job migré est accepté lorsque ses sorties correspondent à la baseline figée.
- Un format connu exécute un loader approuvé sans appel au modèle ; un format inconnu passe par un agent de code en sandbox, puis par des contrôles côté plateforme et une validation humaine.
Évaluation
L’inventaire, une preuve de concept de transformation et le premier flux d’ingestion ont été démontrés au client.
Résultat
Plus de mille jobs legacy ont été inventoriés et leur lineage reconstruit, ce qui donne au client une cartographie du parc qui n’existait pas auparavant.
Mon rôle
Tech lead avec deux développeurs : roadmap, méthodes de lineage et d’acceptation, conception du flux d’ingestion, première application opérateur et proposition d’architecture cloud.