ETL vs ELT : Choisir le Bon Pattern de Pipeline de Données
#data-engineering#etl#elt#data-pipelines#cloud
Le passage d'ETL (Extract-Transform-Load) à ELT (Extract-Load-Transform) reflète la façon dont les entrepôts cloud modernes ont changé l'économie du traitement de données. Comprendre quand utiliser chaque pattern — ou un hybride — est essentiel pour des architectures de données scalables.
La Différence Fondamentale
| Dimension | ETL | ELT |
|---|---|---|
| Lieu de transformation | Serveur intermédiaire / cluster Spark | Dans l'entrepôt cible |
| Coût de calcul | Compute séparé (Spark, Dataflow) | Compute de l'entrepôt (BigQuery, Snowflake, Redshift) |
| Données brutes dans l'entrepôt | Non — seules les données transformées arrivent | Oui — les données brutes arrivent d'abord |
| Flexibilité | Le schéma doit être défini à l'avance | Schema-on-read, itération libre |
| Latence | Plus élevée (la transformation est un goulot) | Plus faible (charger d'abord, transformer ensuite) |
| Idéal pour | Transformations complexes, systèmes legacy | Analytics, stacks cloud-native |
Quand l'ETL Reste Pertinent
- Contrôle qualité à l'ingestion — rejeter les mauvaises données avant qu'elles n'entrent dans l'entrepôt
- Suppression des données personnelles — les données sensibles ne doivent jamais arriver brutes dans l'entrepôt
- Enrichissement complexe — jointures avec des APIs externes ou des flux temps réel pendant le traitement
- Contrôle des coûts — le compute de l'entrepôt est cher ; Spark sur des instances spot peut être 5–10x moins cher pour les transformations lourdes
Quand l'ELT Est le Standard Moderne
- Entrepôt cloud avec compute élastique — BigQuery, Snowflake, Databricks scalent le compute à la demande
- Analytics exploratoire — conserver les données brutes, transformer plus tard selon l'évolution des questions métier
- Workflows dbt — transformation SQL dans l'entrepôt, versionné, testé
- Délai de mise en valeur réduit — données disponibles en heures, pas en semaines
La Stack ELT Moderne
Sources → Ingestion (Fivetran/Airbyte) → Entrepôt (Snowflake/BigQuery) → Transform (dbt) → BI (Looker/Metabase)
| Couche | Outils | Rôle |
|---|---|---|
| Extract & Load | Fivetran, Airbyte, Stitch, AWS DMS | Déplacer les données brutes vers l'entrepôt |
| Transform | dbt, Dataform, SQLMesh | Modélisation SQL dans l'entrepôt |
| Orchestration | Airflow, Dagster, Prefect | Planifier et surveiller les pipelines |
| Qualité | dbt tests, Great Expectations, Soda | Valider les données transformées |
Approches Hybrides
La plupart des architectures réelles sont hybrides : ELT pour les pipelines analytiques, ETL pour les pipelines opérationnels/conformité.
| Pattern | Cas d'usage |
|---|---|
| ELT + streaming ETL | Analytics batch via ELT ; features temps réel via Kafka + Flink |
| ETL pour l'ingestion, ELT pour la modélisation | Supprimer les données personnelles à l'extraction, modéliser dans l'entrepôt |
| Reverse ETL | Pousser les données transformées de l'entrepôt vers les systèmes opérationnels (CRM, marketing) |
Cadre de Décision
| Question | Si oui → | Si non → |
|---|---|---|
| Votre cible est un entrepôt cloud ? | ELT | Envisager ETL |
| Besoin de transformations temps réel ? | Streaming ETL | ELT batch |
| Les données personnelles doivent être supprimées avant le chargement ? | ETL (ou hybride) | ELT |
| Votre équipe est SQL-first ? | ELT + dbt | ETL avec Spark/Python |
| Les questions métier changent souvent ? | ELT (conserver les données brutes) | ETL (schéma fixé OK) |
Ressources
- Documentation dbt — Le standard pour la transformation ELT
- The Modern Data Stack — Paysage d'outils et patterns d'architecture
- Comparaison Airbyte vs Fivetran — Open-source vs managé
- Fundamentals of Data Engineering — Joe Reis & Matt Housley
:::