L'architecture des pipelines de données est la conception de bout en bout de la manière dont les données sont collectées, traitées, stockées et acheminées depuis les systèmes sources vers les personnes, les applications et les modèles qui les utilisent. Le mot « architecture » fait référence au plan, et non au pipeline lui-même. Il englobe les choix concernant la circulation des données, l'endroit où elles sont transformées et les outils qui gèrent chaque étape du processus.
Une bonne architecture est adaptée au cas d'usage plutôt que choisie sur étagère. Un pipeline de données conçu pour la détection des fraudes en temps réel est très différent de celui qui produit un rapport de ventes nocturne, même si tous deux déplacent des données d'une source vers une destination. Cette page de glossaire présente les couches fondamentales communes à chaque pipeline, les modèles d'étapes courants, les principaux modèles d'architecture et les meilleures pratiques pour garantir la fiabilité des pipelines à grande échelle.
Un pipeline de données déplace les données à travers une série d'étapes, et chaque étape a un rôle précis : collecter les donn ées, les nettoyer, les stocker et les rendre exploitables. L'architecture est le plan de connexion de ces étapes. Elle définit ce qui arrive aux données à chaque étape, dans quel ordre et selon quelles règles.
Les décisions d'architecture se situent à deux niveaux. La conception logique définit les étapes existantes et le rôle de chacune : c'est le « quoi ». La conception physique définit les outils et l'infrastructure spécifiques qui exécutent chaque étape : c'est le « comment ». L'orchestration (la planification et la coordination automatiques de chaque étape) et la surveillance ne dépendent pas d'une seule étape. Elles s'appliquent à l'ensemble du pipeline. Les plateformes modernes ont également éliminé une ancienne frontière. Avec Lakeflow, Databricks unifie les pipelines batch et streaming sur une base unique, évitant ainsi aux équipes de devoir concevoir et maintenir deux systèmes parallèles.
Quel que soit le modèle choisi par une équipe, chaque pipeline de données repose sur les quatre mêmes couches. Chaque couche répond à une question différente sur les données : comment elles entrent, comment elles deviennent utiles, où elles résident et qui les consomme.
L'ingestion extrait les données des systèmes sources pour les injecter dans le pipeline : bases de données, applications, API, fichiers stockés dans le cloud, flux d'événements et capteurs. L'ingestion de données se présente sous deux formes. L'ingestion batch extrait les données selon un calendrier défini, par exemple toutes les heures ou chaque nuit. L'ingestion en streaming capture les données en continu au fur et à mesure que les événements se produisent. De nombreux pipelines utilisent également le change data capture (CDC), une méthode qui suit les modifications au niveau des lignes dans une base de données source afin que le pipeline ne déplace que les nouveautés ou les mises à jour au lieu de tout recharger.
C'est dans cette couche que les données brutes sont nettoyées, restructurées, enrichies et préparées pour leur utilisation. Les tâches types comprennent la correction des valeurs manquantes, la standardisation des formats, la jointure de jeux de données et l'application de règles métier, c'est-à-dire les tâches mêmes qui sont au cœur de l'ETL. Le traitement suit la même répartition que l'ingestion. Le traitement batch traite de grands volumes de données ensemble, tandis que le traitement de flux (stream processing) traite les enregistrements un par un ou par micro-lots à mesure qu'ils arrivent.
Le stockage est l'endroit où les données traitées atterrissent afin de pouvoir être interrogées, analysées ou fournies à des modèles. La destination est généralement un data lake, un data warehouse ou un lakehouse, un système unique qui combine les avantages des deux. Le format importe tout autant que l'emplacement. Les formats ouverts comme Lakehouse Storage et Apache Iceberg permettent à plusieurs outils de lire les mêmes données sans avoir à les copier d'un système à l'autre. Delta Lake ajoute également des fonctionnalités de fiabilité telles que les transactions ACID (une garantie que les écritures réussissent complètement ou échouent totalement, évitant ainsi la corruption) et le time travel (la possibilité d'interroger des versions antérieures d'une table).
La dernière couche fournit les données préparées aux personnes et aux systèmes qui en ont besoin : les analystes qui exécutent des requêtes SQL, les utilisateurs métier qui travaillent sur des tableaux de bord, les data scientists qui entraînent des modèles et les applications qui appellent des API. Les destinations vont des outils de BI aux plateformes de ML en passant par les systèmes opérationnels, un data warehouse se trouvant souvent au centre des charges de travail analytiques. Sur l'ensemble des quatre couches, l'orchestration et l'observabilité assurent la liaison : planification des tâches, suivi de la qualité des données et déclenchement d'alertes en cas de problème.
Différentes sources décrivent les pipelines de données comme comportant trois, quatre ou cinq étapes, ce qui est source de confusion. La réalité est plus simple. Ces trois modèles décrivent le même travail sous-jacent à différents niveaux de détail.
| Modèle | Étapes | Quand l'utiliser |
|---|---|---|
| À 3 étapes | Sources → Traitement → Destination | Explications de haut niveau, présentations pour les décideurs, contenu d'introduction |
| À 4 étapes | Ingestion → Traitement → Stockage → Mise à disposition | Le plus courant dans l'ingénierie des données moderne. Équilibre entre clarté et niveau de détail |
| À 5 étapes | Collecte → Ingestion → Traitement → Stockage → Analyse | Analyses techniques détaillées. Divise la « récupération des données » en collecte (depuis la source) et ingestion (dans le pipeline) |
Le nombre d'étapes est un choix de terminologie. Le travail effectué par le pipeline reste le même.
Les modèles d'architecture sont les conceptions établies parmi lesquelles les équipes choisissent lors de la construction de pipelines. Le bon choix dépend des exigences de latence, du volume de données et de la manière dont les données seront utilisées en aval.
L'architecture batch traite les données par lots planifiés : toutes les heures, chaque nuit ou chaque semaine. Elle convient aux rapports, aux analyses historiques, aux données d'entraînement de ML et à tout cas d'usage où un délai de quelques minutes ou heures est acceptable. Les pipelines batch sont plus simples à concevoir, moins coûteux à exploiter et plus faciles à déboguer que leurs équivalents en streaming. Le compromis réside dans la fraîcheur des données. Lorsque les décisions dépendent de ce qui s'est passé il y a quelques secondes, le batch ne peut pas suivre.
L'architecture streaming traite les données en continu, enregistrement par enregistrement, au fur et à mesure de leur génération. Elle répond aux cas d'usage où une réponse en moins d'une minute est essentielle : détection des fraudes, personnalisation en temps réel et surveillance de l'IoT. Le compromis réside dans le coût. Les pipelines de streaming coûtent généralement plus cher à exécuter et à exploiter que les pipelines batch car ils nécessitent une infrastructure active en permanence.
L'architecture Lambda exécute deux chemins parallèles. Un chemin batch fournit des données historiques précises, un chemin de streaming fournit des données rapides et fraîches, et une couche de mise à disposition fusionne les résultats. Cette conception fonctionne, mais elle présente un inconvénient bien connu. Maintenir deux pipelines implique de dupliquer le code, la logique et de doubler la charge opérationnelle.
L'architecture Kappa simplifie Lambda en utilisant un seul pipeline de streaming pour tout. Lorsqu'une analyse historique est nécessaire, le flux est rejoué depuis le début. Kappa convient aux équipes qui souhaitent une fraîcheur de niveau streaming sans le coût de maintenance de deux systèmes parallèles.
L'architecture médaillon est un modèle populaire sur les plateformes lakehouse qui organise les données en trois niveaux de qualité : Bronze (brutes, telles qu'ingérées), Silver (nettoyées et conformes) et Gold (organisées, prêtes pour l'usage métier). Comme l'indique la documentation Databricks, « l'architecture médaillon utilise trois couches : bronze, silver et gold, chacune ayant un but distinct dans le pipeline ». Chaque niveau peut fonctionner comme son propre pipeline, ce qui facilite la planification, la surveillance et le dépannage, car les problèmes restent isolés à une seule couche.
L'ETL et l'ELT diffèrent par le moment où les données sont transformées. L'ETL (extract, transform, load) transforme les données avant de les charger dans le stockage. L'ELT (extract, load, transform) charge d'abord les données brutes et les transforme au sein de la destination. Les plateformes cloud modernes telles que Databricks, Snowflake et BigQuery ont fait de l'ELT le modèle dominant car le stockage et le calcul cloud sont désormais suffisamment bon marché et élastiques pour transformer les données sur place. Pour une comparaison plus approfondie, consultez ETL vs ELT.
| ETL | ELT | |
|---|---|---|
| Ordre | Extract → Transform → Load | Extract → Load → Transform |
| Lieu de la transformation | Dans un outil de traitement distinct, avant le stockage | Au sein de la destination (lakehouse ou warehouse) |
| Cas d'usage type | Warehouses sur site existants, validation stricte avant chargement | Lakehouses et warehouses cloud modernes |
| Points forts | Des données plus propres arrivent dans le stockage. Schémas prévisibles | Flexible, évolutif, maintient les données brutes disponibles pour un retraitement |
| Compromis | Moins flexible. Plus difficile de réutiliser les données brutes plus tard | Nécessite une puissance de calcul performante à la destination |
Non. L'ETL est un type de pipeline de données, mais tous les pipelines de données ne sont pas des ETL. Un pipeline de données est la catégorie générale : tout système qui déplace des données d'un endroit à un autre. L'ETL est une approche spécifique au sein de cette catégorie, définie par la transformation des données avant qu'elles n'arrivent dans le stockage. Les pipelines peuvent également être de type ELT, en streaming, uniquement de réplication (déplacement de données sans aucune transformation) ou reverse ETL (envoi de données de l'entrepôt vers les systèmes opérationnels).
Ces 10 principes de conception distinguent les pipelines évolutifs de ceux qui tombent en panne.
L'architecture des pipelines détermine si les équipes peuvent faire confiance à leurs données, si les décisions reposent sur des informations fraîches et si les projets d'IA et de ML passent du prototype à la production. C'est ce qui fait la différence entre une plateforme de données dont la valeur s'accroît et une autre qui génère des tickets d'assistance.
Une architecture fragile engendre de réels coûts : des tableaux de bord obsolètes, des métriques contradictoires, des déploiements de ML ratés et des ingénieurs qui passent plus de temps à éteindre des incendies qu'à construire. L'approche moderne du lakehouse s'attaque à la cause profonde. En unifiant le batch et le streaming, l'analytique et l'IA, ainsi que la gouvernance sur une plateforme unique comme la plateforme Databricks, les équipes éliminent les transferts fragiles entre systèmes qui font échouer les architectures traditionnelles.
Databricks propose chaque couche de l'architecture des pipelines sur une seule plateforme. Lakeflow Connect gère l'ingestion à partir de bases de données, d'applications SaaS, de sources de fichiers et de flux d'événements. Lakeflow Spark Declarative Pipelines construit des pipelines ETL batch et streaming avec des contrôles de qualité des données intégrés, et Lakeflow Jobs orchestre et planifie les exécutions de pipelines sur l'ensemble de la plateforme. En dessous, Delta Lake fournit le format de stockage ouvert ainsi que des fonctionnalités de fiabilité telles que les transactions ACID et le voyage dans le temps (time travel), tandis que Unity Catalog applique la gouvernance, le lignage et le contrôle d'accès à chaque étape.
Puisque les pipelines batch et streaming s'exécutent sur le même moteur et écrivent dans le même stockage, les équipes n'ont pas besoin de maintenir des systèmes parallèles de type Lambda. Une seule définition de pipeline peut alimenter à la fois le rapport nocturne et le tableau de bord en temps réel.
C'est le plan qui définit comment les données passent de leur lieu de création à leur lieu d'utilisation. Ce plan couvre la manière dont les données sont collectées, nettoyées et préparées, l'endroit où elles sont stockées et la façon dont elles sont transmises aux personnes et aux applications qui en ont besoin.
L'architecture Lambda exécute deux pipelines parallèles, un en batch et un en streaming, et fusionne leurs résultats dans une couche de service (serving layer). L'architecture Kappa utilise un seul pipeline de streaming pour tout et rejoue le flux lorsqu'une analyse historique est nécessaire. Kappa est plus simple à exploiter, tandis que Lambda persiste dans les environnements où les parcours batch et streaming ont évolué séparément.
Utilisez le streaming lorsque la valeur des données chute en quelques secondes ou minutes, comme pour la détection des fraudes, la personnalisation en temps réel ou la surveillance des équipements. Utilisez le batch pour tout le reste, y compris les rapports, les analyses historiques et les données d'entraînement de ML. Le batch est plus simple et moins coûteux, c'est donc le choix par défaut le plus logique jusqu'à ce qu'un cas d'usage prouve qu'il nécessite des données en temps réel.
L'architecture logique définit les étapes d'un pipeline et le rôle de chacune d'elles, indépendamment de tout outil. L'architecture physique associe ces étapes à des technologies et infrastructures spécifiques. Les équipes finalisent généralement la conception logique en premier, puis choisissent les plateformes pour la mettre en œuvre.
L'architecture des pipelines de données est la conception sous-jacente à la manière dont les données se déplacent et deviennent utiles. La bonne architecture est celle qui équilibre la fraîcheur, le coût et la fiabilité pour la tâche spécifique à accomplir, qu'il s'agisse d'un rapport de ventes nocturne ou d'un contrôle des fraudes s'exécutant en quelques millisecondes.
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.