Que fait Construction de Pipelines d'Ingestion ?
Quand l'utiliser
- Extraction de bases de données, API, fichiers ou SaaS vers un entrepôt/lac.
- Conception d'extraction incrémentale, de marques de haut niveau ou de CDC.
- Gestion de la pagination des API, des limites de débit et des tentatives.
- Décision entre EL géré (Fivetran/Airbyte) et code personnalisé.
- Ne PAS utiliser pour transformer des données déjà arrivées (utiliser les compétences dbt/Spark).
Workflow
- [ ] Décider du mode d'extraction : instantané complet vs incrémental vs CDC
- [ ] Choisir une marque de haut niveau fiable (updated_at, LSN/binlog, séquence)
- [ ] Déposer les données brutes immuablement (ajout), puis transformer en aval
- [ ] Rendre le chargement idempotent (upsert/écrasement de partition par clé)
- [ ] Gérer la pagination, les limites de débit, les tentatives et les données tardives
- Choisir le mode. Rechargement complet (petites tables de dimension), incrémental par une marque de haut niveau (la plupart des tables de faits), ou CDC (OLTP à fort volume où vous avez besoin de suppressions et de chaque modification).
- Choisir une marque de niveau supérieur fiable.
updated_atne fonctionne que si la source le met toujours à jour ; sinon utilisez les positions du journal de base de données (LSN/binlog/SCN) ou une séquence monotone. Stockez la dernière marque de haut niveau et reprenez à partir de celle-ci. - Déposer les données brutes immuablement. Ajoutez les extractions brutes (bronze) avec des métadonnées de chargement ; effectuez les transformations en aval pour pouvoir rejouer sans re-pull de la source.
- Chargement idempotent. Upsert par clé naturelle ou écraser la partition, afin que les tentatives et les chevauchements ne dupliquent pas (voir
writing-idempotent-transformations). - Soyez robuste face à la pagination, aux limites de débit et aux données tardives.
Schémas
Extraction incrémentale avec chevauchement pour les données tardives :
-- Tirer une petite fenêtre de chevauchement après la dernière marque de haut niveau pour
-- capturer les mises à jour tardives, puis upsert par clé afin que le chevauchement ne crée pas
-- de doublons.
SELECT * FROM source.commandes
WHERE date_modification >= :derniere_marque - INTERVAL '3 jours';
CDC — lisez le journal de la base de données (Debezium/natif) pour capturer les insertions, les mises à jour et les suppressions (que l'extraction basée sur une marque de haut niveau manque). Appliquez les modifications avec MERGE, en utilisant la position de validation du changement pour l'ordre.
Pagination d'API + limites de débit — suivez les jetons curseur/page suivante ; reculez et réessayez en cas de 429/5xx avec un backoff exponentiel et de la gigue (jitter) ; vérifiez la progression afin qu'un échec reprenne au milieu du flux.
Géré vs personnalisé — utilisez Fivetran/Airbyte pour les connecteurs standard (ils gèrent la dérive du schéma, l'état incrémental, les tentatives) ; n'écrivez du code personnalisé que pour des sources inhabituelles ou pour un contrôle strict/des besoins de coût.
Pièges courants
- Marque de haut niveau
updated_atlorsque la source ne la définit pas de manière fiable — manque silencieusement des lignes ; validez ou passez au CDC basé sur le journal. - Pas de fenêtre de chevauchement — les mises à jour tardives sont perdues entre les exécutions.
- Extraction basée sur une marque de haut niveau en prévision de suppressions — elle ne peut pas les voir ; utilisez le CDC ou une réconciliation complète périodique.
- Transformer pendant l'extraction — rend la relecture impossible ; déposez d'abord les données brutes.
- Ignorer les limites de débit/les cas limites de pagination — extractions partielles qui semblent complètes ; vérifiez et comptez les enregistrements.
- Chargement non idempotent — les tentatives et les fenêtres de chevauchement dupliquent les lignes.