Auparavant, les pipelines de données suivaient une séquence stricte : extraire les données des systèmes sources, les transformer dans un format propre et structuré, puis charger le produit fini dans une base de données. Cette séquence (extract, transform, load, ou ETL) était judicieuse lorsque le stockage coûtait cher et que les systèmes de destination n’étaient pas suffisamment puissants pour effectuer des calculs lourds.

Cependant, les entrepôts dans le cloud ont changé la donne, et l’ELT (extract, load, transform) est devenu le modèle par défaut pour de nombreuses équipes d’analyse. Même si l’ETL traditionnel conserve une part de marché de près de 40 %, il cède rapidement du terrain à d’autres types de pipelines de données, comme l’ELT.

Ci-dessous, nous abordons ce qu’est l’ELT, comment il fonctionne, et dans quels cas il convient de l’utiliser ou non.

Points clés

• Un processus ELT (extract, load, transform) commence par charger les données brutes dans un entrepôt dans le cloud avant de les transformer. Les analystes bénéficient ainsi d’un accès plus rapide aux données et d’une plus grande flexibilité pour améliorer les modèles.

• Les entrepôts dans le cloud sont bien adaptés à l’ELT, car ils séparent le stockage du calcul, se développent de manière élastique, et permettent aux analystes d’écrire la logique de transformation en langage de requête structuré (SQL).

• Travailler avec un prestataire de paiement qui se synchronise directement avec votre entrepôt sans passer par une infrastructure tierce réduit la complexité du pipeline et les risques en matière de sécurité.

Qu’est-ce que l’ELT et comment fonctionne-t-il ?

L’ELT (extract, load, transform) est un modèle d’intégration de données qui repose sur trois étapes : l’extraction des données des systèmes sources, leur chargement brut dans une destination centrale, puis leur transformation à l’intérieur de cette destination à des fins d’analyse, de reporting ou de machine learning.

Voici comment fonctionne un workflow ELT classique dans la pratique :

• Extraction : un connecteur ou une tâche de pipeline extrait des enregistrements d’un système source (de manière incrémentielle, selon une planification, ou en réponse à des événements) et les inscrit dans la destination en conservant leur structure d’origine.

• Chargement : les tables brutes arrivent dans l’entrepôt, souvent dans un schéma dédié, en conservant les noms des champs, les types de données et les relations tels qu’ils existaient dans la source.

• Transformation : la logique de transformation s’exécute dans l’entrepôt, car des outils basés sur SQL, tels que le data build tool (dbt), permettent aux équipes de contrôler les versions de ces modèles, de les tester et de créer des ensembles de données sur la couche brute.

Dans la mesure où les données brutes arrivent en premier, les analystes peuvent les interroger immédiatement, et plusieurs vues en aval peuvent être créées à partir d’une seule source sans avoir à extraire de nouveau les données. Si un modèle de transformation est incorrect, vous le réécrivez et l’exécutez de nouveau sur des données qui se trouvent déjà dans l’entrepôt.

En quoi l’ELT diffère-t-il de l’ETL dans la pratique ?

La principale différence architecturale entre l’ETL et l’ELT réside dans l’emplacement de la transformation : à l’extérieur de la destination pour l’ETL, à l’intérieur pour l’ELT.

Voici les principales différences entre l’ETL et l’ELT :

• Disponibilité des données : dans un pipeline ETL, les données ne peuvent pas faire l’objet de requêtes tant qu’elles n’ont pas été transformées et chargées. Avec l’ELT, les données brutes arrivent en premier, ce qui permet aux analystes de travailler dessus pendant que les tâches de transformation s’exécutent séparément.

• Vitesse d’amélioration : la modification d’une transformation dans un pipeline ETL implique souvent la reconstruction du pipeline lui-même. Avec l’ELT, vous mettez à jour un modèle SQL et l’exécutez de nouveau sur des données qui se trouvent déjà dans l’entrepôt.

• Emplacement des ressources de calcul : les transformations ETL s’exécutent sur l’infrastructure du pipeline (un serveur ou un service distinct que vous provisionnez à cette fin). Les transformations ELT s’exécutent sur les ressources de calcul du data warehouse, qui se développent de manière élastique et sont déjà payées.

• Conservation des données brutes : l’ETL ignore généralement les états intermédiaires une fois que le résultat transformé est produit. L’ELT préserve la couche brute par défaut, ce qui signifie que vous pouvez retraiter les données historiques lorsque les exigences évoluent.

Pourquoi l’ELT est-il adapté aux data warehouses dans le cloud moderne ?

Les propriétés suivantes font de l’ELT un choix naturel pour les entrepôts dans le cloud :

• Stockage et calcul séparés : les plateformes telles que Snowflake et BigQuery, facturent séparément le stockage des données et leur interrogation. Vous pouvez charger autant de données brutes que vous le souhaitez, et les tâches de transformation ne consomment des ressources de calcul que lors de leur exécution.

• Mise à l’échelle élastique : vous pouvez créer les ressources de calcul dont vous avez besoin, exécuter la tâche, puis réduire de nouveau ces ressources. L’entrepôt gère la parallélisation.

• Stockage en colonnes : les entrepôts dans le cloud stockent les données sous forme de colonnes, ce qui rend les requêtes analytiques (agrégations, filtres, jointures sur de grands ensembles de données) considérablement plus rapides que le stockage basé sur des lignes.

• SQL natif : la plupart des analystes et des ingénieurs d’analyse connaissent déjà le langage SQL. L’exécution de transformations à l’intérieur de l’entrepôt signifie que les personnes qui comprennent la logique de l’entreprise peuvent écrire et gérer directement les modèles de transformation.

Quand est-il judicieux d’utiliser l’ELT ?

L’ELT n’est pas la solution idéale pour tous les pipelines de données, mais il répond à un ensemble de conditions bien précises.

Voici les cas dans lesquels l’ELT a tendance à bien fonctionner :

• Ensembles de données volumineux ou à croissance rapide : si vous synchronisez des millions d’événements par jour, l’exécution des transformations avant le chargement nécessite une infrastructure de pipeline importante. Le chargement des données brutes et leur transformation dans l’entrepôt s’avèrent plus pratiques à grande échelle.

• Logique de transformation qui change fréquemment : si les transformations se trouvent dans l’entrepôt sous la forme de modèles SQL, la mise à jour des exigences en matière d’analyse ne nécessite pas le redéploiement de l’infrastructure du pipeline.

• Plusieurs cas d’usage en aval : les données brutes stockées dans l’entrepôt peuvent alimenter simultanément un tableau de bord de veille stratégique, un magasin de fonctionnalités de machine learning et un rapport d’opérations. Vous créez un seul pipeline et modélisez les données différemment pour chaque utilisateur.

• Équipes disposant de capacités d’ingénierie analytique : l’ELT transfère la responsabilité de la transformation à la couche d’analyse. Les équipes qui utilisent des outils tels que dbt sont bien adaptées à cet effet.

L’ELT n’est pas adapté dans les cas suivants :

• Contraintes réglementaires relatives aux données brutes : certains environnements de données financières et de santé interdisent l’arrivée de données sensibles avant leur masquage ou leur filtrage. Dans ces cas, les transformations doivent avoir lieu en amont.

• Schémas de destination rigides : si votre destination ne peut pas accueillir de données brutes ou semi-structurées, l’approche de chargement d’abord de l’ELT crée plus de problèmes qu’elle n’en résout.

• Petits ensembles de données stables : si un simple pipeline ETL fait l’affaire, l’ajout d’une infrastructure de transformation d’entrepôt constitue une charge supplémentaire sans réel avantage.

Quels sont les défis liés à l’ELT ?

L’arrivée de données brutes dans un entrepôt est un atout de taille, mais cela peut s’accompagner de défis en matière de gouvernance et de coûts.

Considérez ces défis potentiels liés à l’ELT.

Contrôle d’accès

Les tables brutes contiennent souvent des données qui ne devraient pas être largement accessibles, telles que des informations d’identification personnelles (PII), des dossiers financiers ou des identifiants internes. Avec l’ETL, les champs sensibles peuvent être masqués ou supprimés avant même que les données n’atteignent leur destination. Toutefois, dans le cas de l’ELT, les données arrivent en premier. Sans sécurité au niveau des lignes, masquage de colonnes ou rôles d’entrepôt strictement définis, les analystes peuvent interroger des champs qu’ils ne devraient pas pouvoir consulter.

Qualité des données

Les données de mauvaise qualité provenant de sources en amont arrivent dans votre entrepôt avant l’exécution de tout contrôle. Les champs nuls, les enregistrements en double, les modifications de schéma et les incohérences de type peuvent se propager dans les modèles en aval si vous n’intégrez pas de tests de qualité à la couche de transformation à l’aide du framework de test dbt ou des fonctionnalités de qualité des données natives de l’entrepôt.

Gestion des coûts

Les tâches de transformation s’exécutent sur les ressources de calcul de l’entrepôt, et un code SQL mal écrit (comme des analyses illimitées, des filtres de partition manquants ou des actualisations redondantes de tables complètes) peut engendrer des coûts importants. Il est utile d’intégrer dès le départ des limites sur les coûts des requêtes, l’utilisation de modèles incrémentiels dans la mesure du possible, et la surveillance de l’utilisation des ressources de calcul dans votre workflow.

Comment un workflow ELT gère-t-il les données de paiement ?

De nombreuses équipes créent une intégration personnalisée en s’appuyant sur l’interface de programmation d’application (API) de leur prestataire de services de paiement ou utilisent un connecteur tiers. Cependant, les intégrations personnalisées nécessitent une maintenance continue à mesure que l’API évolue, et les connecteurs tiers impliquent d’acheminer des données financières sensibles via l’infrastructure d’un prestataire supplémentaire.

Stripe Data Pipeline est une option native intégrée directement au Dashboard Stripe. L’outil synchronise les données et les rapports Stripe avec Snowflake, Databricks, Amazon Redshift, et d’autres outils en quelques clics. Vous n’avez pas besoin d’utiliser de code ni de configurer de connecteur, et vous n’avez pas d’identifiants distincts à gérer. La synchronisation s’exécute à l’aide de l’infrastructure de Stripe, ce qui signifie qu’aucun système tiers ne gère vos données financières en transit.

Voici quelques informations utiles à connaître :

• Couverture historique : Stripe Data Pipeline inclut des données historiques à partir de la création de votre compte Stripe plutôt qu’à partir du moment où vous activez la synchronisation.

• Schéma : les données atterrissent dans des tables qui reflètent le modèle de données de Stripe (par exemple, paiements, clients, abonnements), ce qui facilite la création de modèles de transformation sans nécessiter de nettoyage approfondi au niveau de la couche brute.

• Exhaustivité des données : outre les données brutes des objets, Stripe Data Pipeline inclut l’accès à des rapports financiers préconfigurés et à des ensembles de données sélectionnés, ce qui peut accélérer le reporting et réduire le travail de transformation pour les cas d’usage courants, tels que le revenu récurrent mensuel (MRR) et l’analyse de la fraude.