Si vous concevez un pipeline de données pour alimenter un outil de business intelligence ou entraîner un modèle de machine learning, l’une des premières décisions à prendre concerne l’emplacement de la transformation : avant que les données n’arrivent dans votre data warehouse ou après. Cela signifie que vous devez choisir entre les pipelines ETL (extraire, transformer, charger) et ELT (extraire, charger, transformer).

Ce choix détermine la rapidité avec laquelle les analystes peuvent accéder aux données brutes, la capacité de calcul allouée à chaque étape, et la facilité d’adaptation en cas de modification de votre modèle de données. Le marché mondial des outils de pipeline de données devrait atteindre 48,33 milliards de dollars d’ici 2030, et l’ETL perd du terrain au profit de l’ELT et d’autres types de pipelines.

Nous vous expliquons ci-après le fonctionnement de chaque modèle, les cas d’utilisation pour l’ETL et l’ELT, et la place des connecteurs spécialisés dans les deux approches pour des sources de données spécifiques.

Points clés

• L’ETL transforme les données avant qu’elles n’atteignent la destination. L’ELT charge les données brutes et les transforme au sein du data warehouse en utilisant sa propre capacité de calcul.

• L’ELT est le modèle par défaut pour la plupart des équipes chargées des données modernes. L’ETL reste populaire pour les destinations contraintes, les exigences strictes en matière de gouvernance et les pipelines existants.

• Les connecteurs spécialisés pour des sources de données spécifiques peuvent réduire le risque de problèmes de qualité des données que les connecteurs génériques introduisent parfois.

Pipelines ETL vs ELT : quelle est la différence ?

ETL signifie « extraire, transformer, charger ». Dans un modèle ETL, vous extrayez des données d’un système source, vous les faites passer par une couche de transformation qui les nettoie, les remodèle et les filtre, puis vous chargez le résultat traité dans une destination, telle qu’un data warehouse ou un data mart.

Avec l’ETL, un moteur de traitement distinct effectue le gros du travail avant que les données n’atteignent la destination. Le data warehouse reçoit des données structurées prêtes à être interrogées plutôt que les enregistrements sources bruts. Le retraitement depuis la source implique de procéder à une nouvelle extraction ou de conserver une copie brute distincte ailleurs.

L’ELT, qui signifie « extraire, charger, transformer », inverse les deux dernières étapes. Les données brutes arrivent d’abord à la destination, puis les transformations s’exécutent au sein du data warehouse à l’aide de sa propre capacité de calcul.

Ce changement est devenu possible lorsque les data warehouses en cloud ont permis d’exécuter rapidement et à moindre coût des transformations SQL (Structured Query Language) sur de grands ensembles de données. Au lieu d’un moteur de transformation distinct situé entre la source et la destination, votre data warehouse devient l’environnement de transformation.

Comment fonctionne le modèle ETL ?

Un pipeline ETL s’exécute en trois étapes, chacune ayant une responsabilité distincte.

Voici comment fonctionne l’ETL :

• Extraction : un connecteur ou une tâche d’ingestion extrait des données de la source, telle qu’une base de données, une API (interface de programmation d’application) de paiement, une plateforme SaaS (software-as-a-service) ou un fichier plat. Cette étape gère l’authentification, la pagination, la logique de synchronisation incrémentielle par rapport à une logique d’actualisation complète, et les limites d’appels.

• Transformation : les données extraites sont transférées vers une couche de traitement où elles sont nettoyées (par exemple, gestion des valeurs nulles, typage), remodelées (par exemple, jointures, agrégations, renommage de colonnes), filtrées et parfois enrichies avec des données de référence provenant d’autres sources.

• Chargement : l’ensemble de données traité est chargé dans la destination sous forme d’écrasement complet, de mise à jour/insertion ou d’ajout, selon la configuration du pipeline.

L’ETL reste pertinent dans ces situations spécifiques :

• Destinations contraintes : les data warehouses plus anciens ou les systèmes sur site dont la capacité de calcul est limitée, ne peuvent pas exécuter efficacement de grandes transformations sur place. Le chargement de données prétransformées est donc la seule option réaliste.

• Exigences strictes en matière de gouvernance : certaines organisations doivent s’assurer que les informations d’identification personnelles ou les données financières sensibles n’arrivent jamais dans le data warehouse sous forme brute. La transformation et le masquage en amont répondent à cette exigence d’un point de vue architectural.

• Environnements de périphérie : l’Internet des objets (IoT) et les systèmes embarqués qui transmettent des données vers une infrastructure centrale ne peuvent souvent pas envoyer de gros volumes bruts, ce qui rend indispensable une transformation locale avant la transmission.

• Dette liée aux pipelines existants : de nombreuses organisations matures disposent de pipelines ETL qui fonctionnent de manière fiable depuis des années. Les reconstruire sous forme d’ELT comporte un risque qui n’en vaut pas toujours la peine.

Comment fonctionne le modèle ELT ?

Les pipelines ELT extraient et chargent les données sources brutes ou légèrement formatées directement vers la destination. Les transformations s’exécutent ensuite, déclenchées à intervalles réguliers ou à la demande, en utilisant la capacité de calcul du data warehouse.

Par exemple, un connecteur peut extraire des données d’une source et les écrire dans un schéma brut au sein de votre data warehouse. Un ingénieur analytique écrit des modèles dbt (data build tools) qui lisent ce schéma brut, appliquent la logique métier et créent des tables nettoyées pouvant être interrogées par les outils de business intelligence (BI). Lorsque la logique doit être modifiée, il suffit de mettre à jour le modèle et de l’exécuter à nouveau sur les données déjà présentes.

L’ELT est un choix judicieux pour les raisons suivantes :

• Accès plus rapide aux données brutes : les données arrivent rapidement dans le data warehouse, ce qui permet aux équipes de commencer à les explorer et à les valider avant que la couche de transformation ne soit terminée.

• Améliorations moins coûteuses : la modification d’une transformation dans l’ETL implique souvent de modifier un pipeline, de retraiter et de recharger. Dans l’ELT, il suffit de mettre à jour un modèle SQL et de l’exécuter à nouveau sur les données que vous possédez déjà.

• Capacité de calcul à l’échelle du data warehouse : les data warehouses en cloud sont conçus pour traiter rapidement de grands ensembles de données, ce qui signifie que vous allouez une importante capacité de calcul à la transformation des données plutôt que de développer une couche middleware distincte.

• Historique brut complet : les données brutes étant toujours dans le data warehouse, vous pouvez dériver n’importe quelle table en aval à partir de zéro, ce qui est important lorsque les définitions métier changent ou que vous devez résoudre un problème de qualité des données.

Comment choisir entre ETL et ELT ?

Les grandes organisations exécutent généralement ces deux modèles de traitement de données en parallèle pour différentes sources. Les besoins de votre organisation vous aideront à déterminer la méthode la plus adaptée.

Voici les éléments à prendre en compte.

Volume et vélocité des données

Les données à fort volume et à haute fréquence favorisent généralement un pipeline de données ELT. Les warehouses en cloud les gèrent bien, et le coût d’exécution d’un moteur de transformation lourd en amont augmente rapidement. En contrepartie, la facture de calcul de votre warehouse augmente lorsque les transformations sont lourdes, et le stockage des données brutes engendre des coûts.

Les pipelines à plus faible volume avec une logique de transformation stable et bien définie peuvent rester sur ETL sans grande difficulté.

Responsabilité des transformations

Si vos transformations sont basées sur SQL et gérées par des ingénieurs analytiques qui doivent s’adapter rapidement, ELT avec dbt ou un outil similaire est probablement plus adapté.

Si vos transformations sont codées en Python ou Java, et qu’elles sont gérées par une équipe d’ingénierie des données, ETL peut s’intégrer naturellement dans votre chaîne d’outils existante.

Accès aux données brutes

Si les analystes doivent accéder aux données sources brutes (par ex., pour une exploration ad hoc, un audit, ou parce que la logique de transformation est encore en développement), ELT est l’option par défaut recommandée. Les pipelines ETL qui ne conservent pas les données brutes rendent ce type d’accès difficile à intégrer a posteriori.

Gouvernance et conformité

Si des données spécifiques doivent être masquées ou anonymisées avant d’atteindre une destination partagée, ETL permet d’appliquer cette exigence au niveau de l’architecture.

ELT peut satisfaire plusieurs des mêmes exigences grâce à la sécurité au niveau des colonnes et aux contrôles d’accès au niveau du warehouse, mais la mise en œuvre diffère et mérite d’être examinée au regard de vos obligations de conformité.

Flux de travail de l’équipe

Une équipe maîtrisant parfaitement SQL et habituée au contrôle de version avec dbt tirera davantage parti d’une configuration ELT que de la maintenance d’un pipeline ETL personnalisé qu’elle n’a pas créé. La compatibilité avec les méthodes de travail de votre équipe est un critère légitime.

Quelle est la place des connecteurs de données dans les pipelines ETL et ELT ?

Les outils ETL et ELT génériques gèrent un large éventail de sources via des connecteurs configurables. Cette polyvalence est utile, mais elle implique des compromis.

Les données relatives aux paiements en sont un bon exemple. Le modèle de données de Stripe couvre les événements, les paiements, les remboursements, les litiges, les opération sur solde, les clients, les abonnements et les factures. Un connecteur générique qui ne suit pas le contrôle des versions de l’API de Stripe ou qui gère mal la logique de synchronisation incrémentielle peut générer des erreurs difficiles à détecter jusqu’à ce qu’elles affectent un Dashboard ou un rapprochement financier.

Stripe Data Pipeline répond directement à ce problème :

• Création et gestion par Stripe : comme Stripe est propriétaire du connecteur et reproduit directement son infrastructure interne, vous pouvez synchroniser les données de manière fiable et continue tout en garantissant leur exhaustivité et leur précision, quel que soit le volume de données et sans aucune limite d’appels à l’API.

• Synchronisation directe du data warehouse : les données sont transférées vers Amazon Redshift, Snowflake, Databricks et d’autres solutions, sans passer par un connecteur tiers, ce qui permet de conserver les données financières sensibles en dehors des infrastructures de fournisseurs supplémentaires.

• Ensemble de données Stripe complet : la synchronisation couvre les objets Stripe, les rapports financiers préconçus et les ensembles de données organisés afin d’accélérer l’analyse et la création de rapports.

• Configuration légère : la connexion se configure dans le Dashboard Stripe, sans aucun code. Si vous exécutez déjà des pipelines ELT pour d’autres sources, les données Stripe s’intègrent dans le même modèle.