Si vous concevez un pipeline de données pour alimenter un outil d'intelligence d'affaires ou former un modèle d'apprentissage automatique, l'une des premières décisions que vous devez prendre est l'endroit où la transformation a lieu : avant que les données n'atterrissent dans votre entrepôt ou après. Cela signifie que vous devez choisir entre des pipelines d'extraction, de transformation, de chargement (ETL) et des pipelines d'extraction, de chargement, de transformation (ELT).

Le choix détermine la vitesse à laquelle les analystes peuvent accéder aux données brutes, la quantité de calcul que vous dépensez et l'endroit où vous la dépensez, et la facilité avec laquelle vous pouvez vous adapter lorsque votre modèle de données change. Le marché des outils mondiaux de pipeline de données devrait valoir 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.

Ci-dessous, nous verrons comment chaque modèle fonctionne, quand l'ETL ou l'ELT est le plus judicieux et comment les connecteurs spécialisés s'intègrent aux 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 des données brutes et les transforme à l'intérieur de l'entrepôt en utilisant son propre calcul.

• L'ELT est le modèle par défaut pour la plupart des équipes de données modernes. L'ETL demeure populaire pour les destinations limitées, les exigences de gouvernance strictes 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 remanie et les filtre, puis vous chargez le résultat traité dans une destination, comme un entrepôt de données ou un magasin de données.

Avec l'ETL, un moteur de traitement distinct effectue le gros du travail avant que les données n'atteignent la destination. L'entrepôt reçoit des données structurées prêtes à être interrogées plutôt que les enregistrements sources bruts. Le retraitement à partir de la source implique soit de réextraire soit de conserver une copie brute séparée ailleurs.

L'ELT, qui signifie « extraire, charger, transformer », inverse les deux dernières étapes. Les données brutes atterrissent d'abord à la destination, puis les transformations s'exécutent à l'intérieur de l'entrepôt en utilisant son propre calcul.

Ce changement est devenu pratique lorsque les entrepôts de données en nuage ont rendu l'exécution de transformations Structured Query Language (SQL) sur de grands ensembles de données peu coûteuse et rapide. Au lieu d'un moteur de transformation séparé situé entre la source et la destination, votre entrepôt est l'environnement de transformation.

Comment fonctionne l'ETL?

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

Voici comment fonctionne l'ETL :

• Extraire : Un connecteur ou un travail d'ingestion extrait des données de la source, comme une base de données, une interface de programmation d'application (API) de paiement, une plateforme de logiciel en tant que service (SaaS) ou un fichier plat. Cette étape gère l'authentification, la pagination, la logique d'actualisation incrémentielle par rapport à la logique d'actualisation complète et les limites de débit.

• Transformer : Les données extraites passent dans une couche de traitement où elles sont nettoyées (par ex., valeurs nulles gérées, conversion de types), remodelées (par ex., jointures, agrégations, changement de nom des colonnes), filtrées et parfois enrichies de données de référence provenant d'autres sources.

• Charger : L'ensemble de données traité se charge dans la destination en tant qu'écrasement complet, mise à jour/insertion ou ajout, selon la façon dont le pipeline est configuré.

Il est toujours judicieux d'utiliser l'ETL dans ces situations spécifiques :

• Destinations contraintes : Les anciens entrepôts de données ou systèmes sur site dont la puissance de calcul est limitée ne peuvent pas exécuter efficacement de grandes transformations sur place. Par conséquent, le chargement de données prétransformées est la seule option réaliste.

• Exigences strictes en matière de gouvernance : Certaines organisations doivent s'assurer que les informations d'identification ou les données financières sensibles n'arrivent jamais sous forme brute dans l'entrepôt. La transformation et le masquage en amont répondent à cette exigence sur le plan de l'architecture.

• Environnements de périphérie : L'Internet des objets (IoT) et les systèmes embarqués qui transmettent des données à une infrastructure centrale ne peuvent souvent pas envoyer de grandes charges utiles brutes, ce qui fait de la transformation locale avant la transmission une nécessité pratique.

• Dette de pipeline hérité : De nombreuses organisations matures disposent de pipelines ETL qui fonctionnent de manière fiable depuis des années. Leur reconstruction en tant qu'ELT comporte un risque qui ne vaut peut-être pas la peine d'être pris.

Comment fonctionne l'ELT?

Les pipelines ELT extraient et chargement des données sources brutes ou légèrement formatées directement vers la destination. Les transformations sont exécutées ensuite, activées selon un calendrier ou à la demande, en utilisant le calcul de l'entrepôt lui-même.

Par exemple, un connecteur peut extraire des données d'une source et les écrire dans un schéma brut de votre entrepôt. Un ingénieur ou une ingénieure analytique écrit des modèles d'outils de création de données (dbt) qui lisent à partir de ce schéma brut, appliquent la logique d'affaires et créent des tables nettoyées que les outils d'intelligence d'affaires (BI) peuvent interroger. Lorsque la logique doit changer, il suffit de mettre à jour le modèle et de l'exécuter de nouveau par rapport aux données qui s'y trouvent déjà.

L'ELT est un choix judicieux pour ces raisons :

• Accès plus rapide aux données brutes : Les données arrivent rapidement dans l'entrepôt, ce qui permet aux équipes de commencer à les explorer et à les valider avant la fin de la couche de transformation.

• Améliorations moins coûteuses : La modification d'une transformation en ETL implique souvent de modifier un pipeline, de retraiter et de recharger. En ELT, vous n'avez qu'à mettre à jour un modèle SQL et l'exécuter à nouveau par rapport aux données que vous possédez déjà.

• Calcul à l'échelle de l'entrepôt : Les entrepôts en nuage sont conçus pour traiter rapidement de grands ensembles de données, ce qui signifie que vous appliquez un calcul sérieux à la transformation plutôt que de développer une couche intergicielle distincte indépendamment.

• Historique brut complet : Puisque les données brutes sont toujours dans l'entrepôt, vous pouvez dériver n'importe quelle table en aval à partir de zéro, ce qui est important lorsque les définitions d'affaires changent ou que vous devez déboguer un problème de qualité des données.

Comment choisir entre ETL et ELT?

Les grandes organisations exécutent généralement les 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 appropriée.

Voici ce que vous devez prendre en considération.

Volume et vélocité des données

Les données à volume et à fréquence élevés favorisent généralement un pipeline de données ELT. Les entrepôts infonuagiques 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 entrepôt augmente lorsque les transformations sont lourdes, et le stockage des données brutes engendre des coûts.

Les pipelines à plus faible volume dotés d'une logique de transformation stable et bien définie peuvent rester sur l'ETL sans trop de problèmes.

Propriété des transformations

Si vos transformations sont basées sur SQL et gérées par des spécialistes en analytique qui doivent s'adapter rapidement, l'ELT avec dbt ou un outil similaire est probablement le choix le plus approprié.

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

Accès aux données brutes

Si les analystes ont besoin d'accéder aux données sources brutes (par exemple, pour une exploration ad hoc, un audit ou parce que la logique de transformation est encore en développement), l'ELT est le meilleur choix par défaut. Les pipelines ETL qui ne préservent 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, l'ETL vous offre une application architecturale de cette exigence.

L'ELT peut satisfaire bon nombre des mêmes exigences grâce à la sécurité au niveau des colonnes et aux contrôles d'accès au niveau de l'entrepôt, mais l'implémentation diffère et mérite d'être examinée en fonction de vos obligations de conformité.

Flux de travail de l'équipe

Une équipe possédant une grande maîtrise de SQL et des habitudes de contrôle de version avec dbt tirera plus de valeur d'une configuration ELT que de la maintenance d'un pipeline ETL personnalisé qu'elle n'a pas conçu. La compatibilité avec la méthode de travail de votre équipe est un facteur légitime.

Comment les connecteurs de données s'intègrent-ils aux pipelines ETL et ELT?

Les outils génériques ETL et ELT gèrent un large éventail de sources grâce à des connecteurs configurables. Cette étendue est utile, mais elle comporte des compromis.

Les données de paiements en sont un bon exemple. Le modèle de données de Stripe couvre les événements, les paiements, les remboursements, les contestations, les transactions de solde, les clients, les abonnements et les factures. Un connecteur générique qui ne suit pas le rythme des versions de l'API de Stripe ou qui gère mal la logique de synchronisation incrémentielle peut produire des erreurs difficiles à détecter jusqu'à ce qu'elles affectent un tableau de bord ou un rapprochement financier.

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

• Conçu et maintenu par Stripe : Étant donné que Stripe possède le connecteur et reflète directement l'infrastructure interne de Stripe, vous pouvez synchroniser les données de manière fiable de façon continue tout en assurant l'exhaustivité et l'exactitude, quelle que soit la quantité de données que vous possédez et sans limite de débit de l'API.

• Synchronisation directe de l'entrepôt : Les données sont acheminées vers Amazon Redshift, Snowflake, Databricks, et plus encore, sans passer par un connecteur tiers, ce qui permet de conserver les données financières sensibles hors de l'infrastructure d'un autre fournisseur.

• Ensemble de données complet de Stripe : La synchronisation couvre les objets Stripe, les rapports financiers préétablis et les ensembles de données sélectionnés afin d'accélérer l'analyse et la création de rapports.

• Configuration allégée : La connexion est configurée dans le Dashboard Stripe, sans codage requis. Si vous exécutez déjà des pipelines ELT pour d'autres sources, les données de Stripe s'intègrent au même modèle.