Les pipelines de données suivaient autrefois 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 (extraire, transformer, charger, ou ETL) avait du sens lorsque le stockage coûtait cher et que les systèmes de destination n'étaient pas assez puissants pour effectuer des calculs lourds.

Mais les entrepôts infonuagiques ont tout changé, et l'ELT (extraire, charger, transformer) est devenu le modèle par défaut de nombreuses équipes d'analyse. Bien que l'ETL traditionnel conserve une part de marché de près de 40 %, il perd rapidement du terrain au profit d'autres types de pipelines de données tels que l'ELT.

Ci-dessous, nous expliquons ce qu'est l'ELT, comment cela fonctionne, et où il s'applique et ne s'applique pas.

Points clés

• Un processus ELT (extraire, charger, transformer) charge d'abord les données brutes dans un entrepôt infonuagique, puis les transforme. Cela donne aux analystes un accès plus rapide aux données et plus de flexibilité pour améliorer les modèles.

• Les entrepôts infonuagiques sont bien adaptés à l'ELT car ils séparent le stockage du calcul, croissent de manière élastique et permettent aux analystes d'écrire une logique de transformation en Structured Query Language (SQL).

• Travailler avec un fournisseur de paiements qui se synchronise directement avec votre entrepôt sans passer par une infrastructure tierce réduit la complexité du pipeline et l'exposition à la sécurité.

Qu'est-ce que l'ELT et comment ça marche?

L'ELT (extraire, charger, transformer) est un modèle d'intégration de données articulé autour de trois étapes : extraire les données des systèmes sources, les charger brutes dans une destination centrale, puis les transformer à l'intérieur de la destination pour l'analyse, la production de rapports ou l'apprentissage automatique.

Voici comment fonctionne un flux de travail ELT typique dans la pratique :

• Extraire : Un connecteur ou une tâche de pipeline tire des enregistrements d'un système source (de manière incrémentielle, selon un calendrier ou déclenché par des événements) et les écrit dans la destination dans leur structure d'origine.

• Charger : Les tables brutes atterrissent dans l'entrepôt, souvent dans un schéma dédié, préservant les noms de champs, les types de données et les relations exactement tels qu'ils existaient dans la source.

• Transformer : La logique de transformation s'exécute à l'intérieur de l'entrepôt car les outils basés sur SQL, tels que l'outil de construction de données (dbt), permettent aux équipes de contrôler les versions de ces modèles, de les tester et de construire des ensembles de données par-dessus la couche brute.

Puisque les données brutes atterrissent en premier, les analystes peuvent les interroger immédiatement, et plusieurs vues en aval peuvent être construites à partir d'une seule source sans avoir à extraire à nouveau. Si un modèle de transformation est incorrect, vous le réécrivez et l'exécutez à 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'endroit où la transformation se produit : à l'extérieur de la destination dans l'ETL, à l'intérieur de la destination dans l'ELT.

Voici les plus grandes différences entre l'ETL et l'ELT :

• Disponibilité des données : Dans un pipeline ETL, les données ne peuvent pas être interrogées tant qu'elles n'ont pas été transformées et chargées. Dans l'ELT, les données brutes atterrissent en premier, de sorte que les analystes peuvent travailler avec elles pendant que les tâches de transformation s'exécutent séparément.

• Vitesse d'amélioration : Modifier une transformation dans un pipeline ETL signifie souvent reconstruire le pipeline lui-même. Dans l'ELT, vous mettez à jour un modèle SQL et l'exécutez à nouveau sur des données qui se trouvent déjà dans l'entrepôt.

• Emplacement du 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 le calcul de l'entrepôt de données, qui évolue de manière élastique et est déjà payé.

• Conservation des données brutes : L'ETL rejette généralement les états intermédiaires une fois que la sortie transformée est produite. L'ELT préserve la couche brute par défaut, ce qui signifie que vous pouvez retraiter les données historiques lorsque les exigences changent.

Pourquoi l'ELT est-il adapté aux entrepôts de données infonuagiques modernes?

Les propriétés suivantes font de l'ELT un choix naturel pour les entrepôts infonuagiques :

• Stockage et calcul séparés : Les plateformes comme Snowflake et BigQuery débitent séparément pour le stockage des données et leur interrogation. Vous pouvez déposer autant de données brutes que vous le souhaitez, et les tâches de transformation ne consomment des ressources de calcul que lorsqu'elles sont exécutées.

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

• Stockage en colonnes : Les entrepôts infonuagiques stockent les données dans un format en colonnes, ce qui rend les requêtes analytiques (agrégations, filtres, jointures sur de vastes ensembles de données) considérablement plus rapides que le stockage par lignes.

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

Quand l'ELT est-il un bon choix?

L'ELT n'est pas la bonne réponse pour chaque pipeline de données, mais il correspond à un ensemble de conditions reconnaissables.

Voici où l'ELT a tendance à bien fonctionner :

• Ensembles de données volumineux ou à croissance rapide : Si vous synchronisez des millions d'événements par jour, exécuter des transformations avant le chargement nécessite une infrastructure de pipeline importante. Charger à l'état brut et transformer à l'intérieur de l'entrepôt est plus pratique à l'échelle.

• Logique de transformation changeant fréquemment : Si les transformations vivent à l'intérieur de l'entrepôt en tant que modèles SQL, la mise à jour des exigences analytiques ne nécessite pas le redéploiement de l'infrastructure du pipeline.

• Cas d'utilisation multiples en aval : Les données brutes dans l'entrepôt peuvent alimenter un tableau de bord d'intelligence d'affaires, un magasin de caractéristiques d'apprentissage automatique et un rapport des opérations simultanément. Vous construisez un seul pipeline et modélisez les données différemment pour chaque utilisateur.

• Équipes disposant d'une capacité d'ingénierie analytique : L'ELT déplace la propriété de la transformation vers la couche d'analyse. Les équipes utilisant des outils tels que dbt sont bien adaptées à cela.

L'ELT n'est pas un bon choix dans les circonstances suivantes :

• Contraintes réglementaires sur les données brutes : Certains environnements de données de soins de santé et de données financières interdisent l'atterrissage de données sensibles avant le masquage ou le filtrage. Dans ces cas, les transformations doivent se produire 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 en premier de l'ELT crée plus de problèmes qu'elle n'en résout.

• Petits ensembles de données stables : Si un pipeline ETL simple fait l'affaire, l'ajout d'une infrastructure de transformation d'entrepôt représente des frais généraux sans grand avantage.

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

L'atterrissage de données brutes dans un entrepôt est puissant, mais cela peut s'accompagner de défis en matière de gouvernance et de coûts.

Examinez ces défis potentiels de l'ELT.

Contrôle d’accès

Les tables brutes contiennent souvent des données qui ne devraient pas être largement accessibles, comme les informations d'identification, les dossiers financiers ou les identifiants internes. Dans l'ETL, les champs sensibles peuvent être masqués ou supprimés avant même que les données n'atteignent leur destination. Mais dans l'ELT, les données atterrissent en premier. Sans sécurité au niveau des lignes, masquage des colonnes ou rôles d'entrepôt étroitement définis, les analystes peuvent interroger des champs qu'ils ne devraient pas pouvoir voir.

Qualité des données

Les mauvaises données provenant de sources en amont atterrissent dans votre entrepôt avant que toute vérification ne soit effectuée. Les champs nuls, les enregistrements en double, les changements de schéma et les incompatibilités de type peuvent se propager dans les modèles en aval si vous n'intégrez pas de tests de qualité dans la couche de transformation avec le cadre de test de dbt ou les fonctions de qualité des données natives de l'entrepôt.

Gestion des coûts

Les tâches de transformation s'exécutent sur la capacité de calcul de l'entrepôt, et un SQL mal écrit (comme des analyses non limitées, des filtres de partition manquants ou des rafraîchissements de table complète redondants) peut générer des coûts substantiels. Définir des limites sur les coûts de requête, utiliser des modèles incrémentiels lorsque cela est possible, et surveiller l'utilisation du calcul valent la peine d'être intégrés à votre flux de travail dès le début.

Comment un flux de travail ELT gère-t-il les données de paiements?

De nombreuses équipes construisent une intégration personnalisée avec l'interface de programmation d'applications (API) de leur fournisseur de paiements ou utilisent un connecteur tiers. Mais les intégrations personnalisées nécessitent une maintenance continue à mesure que l'API change, et les connecteurs tiers impliquent l'acheminement de données financières sensibles par l'infrastructure d'un fournisseur supplémentaire.

Stripe Data Pipeline est une option native intégrée directement au Dashboard de Stripe. Elle synchronise les données et les rapports Stripe avec Snowflake, Databricks, Amazon Redshift, et d'autres en quelques clics. Il n'y a pas de code, pas de configuration de connecteur et pas d'identifiants distincts à gérer. La synchronisation s'exécute à l'aide de l'infrastructure de Stripe, de sorte qu'aucun système tiers ne traite vos données financières en transit.

Quelques spécificités qui valent la peine d'être connues :

• Couverture historique : Stripe Data Pipeline comprend les données historiques depuis le début 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 (p. ex., paiements, clients, abonnements), ce qui facilite la construction de modèles de transformation par-dessus sans un nettoyage approfondi de la couche brute.

• Exhaustivité des données : En plus des données d'objets brutes, Stripe Data Pipeline comprend l'accès à des rapports financiers préconstruits et à des ensembles de données organisés, ce qui peut accélérer la production de rapports et réduire le travail de transformation pour des cas d'utilisation courants tels que le revenu récurrent mensuel (RRM) et l'analyse de la fraude.