Revenir au contenu principal

Qu'est-ce que l'architecture des pipelines de données ?

par Équipe Databricks

  • Une architecture de pipeline de données bien conçue sépare l'ingestion, la transformation, le stockage et la mise à disposition en couches distinctes, le choix du modèle (batch, streaming, médaillon, Kappa, etc.) étant dicté par vos exigences de latence et de coût, et non par la convention.
  • L'ELT a largement remplacé l'ETL en tant qu'approche dominante, car les plateformes cloud modernes permettent de charger d'abord les données brutes et de les transformer sur place, préservant ainsi la flexibilité pour le retraitement et la réutilisation en aval.
  • Databricks unifie les pipelines batch et streaming sur une seule et même plateforme (Lakeflow + Delta Lake + Unity Catalog), éliminant ainsi les infrastructures redondantes et les failles de gouvernance qui fragilisent les architectures traditionnelles de type Lambda.

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.

Comment fonctionne l'architecture d'un pipeline de données ?

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.

Les couches fondamentales d'un pipeline de données

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.

Ingestion

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.

Traitement et transformation

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.

Stockage

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).

Mise à disposition et consommation

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.

Combien d'étapes comporte un pipeline de données ? (3 vs 4 vs 5)

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ÉtapesQuand l'utiliser
À 3 étapesSources → Traitement → DestinationExplications de haut niveau, présentations pour les décideurs, contenu d'introduction
À 4 étapesIngestion → Traitement → Stockage → Mise à dispositionLe plus courant dans l'ingénierie des données moderne. Équilibre entre clarté et niveau de détail
À 5 étapesCollecte → Ingestion → Traitement → Stockage → AnalyseAnalyses 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.

Modèles d'architecture de pipeline de données courants

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.

Architecture batch

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.

Architecture streaming

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.

Architecture Lambda

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.

Architecture Kappa

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.

Architecture médaillon (modèle lakehouse)

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.

ETL vs ELT : comment l'ordre de transformation façonne l'architecture

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.

ETLELT
OrdreExtract → Transform → LoadExtract → Load → Transform
Lieu de la transformationDans un outil de traitement distinct, avant le stockageAu sein de la destination (lakehouse ou warehouse)
Cas d'usage typeWarehouses sur site existants, validation stricte avant chargementLakehouses et warehouses cloud modernes
Points fortsDes données plus propres arrivent dans le stockage. Schémas prévisiblesFlexible, évolutif, maintient les données brutes disponibles pour un retraitement
CompromisMoins flexible. Plus difficile de réutiliser les données brutes plus tardNécessite une puissance de calcul performante à la destination
Rapport

Le guide pratique de l'IA agentique pour l'entreprise

L'ETL est-il identique à un pipeline de données ?

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).

Meilleures pratiques pour l'architecture des pipelines de données

Ces 10 principes de conception distinguent les pipelines évolutifs de ceux qui tombent en panne.

  1. Séparez l'ingestion de la transformation. Séparez l'arrivée des données brutes et le nettoyage des données dans des étapes différentes afin que les problèmes de l'une ne se répercutent pas sur l'autre.
  2. Concevez pour l'idempotence. Un pipeline doit pouvoir être réexécuté en toute sécurité sans créer d'enregistrements en double ni corrompre les résultats. C'est essentiel pour gérer les pannes et les rattrapages de données.
  3. Intégrez des contrôles de qualité des données. Des contrôles rigoureux de qualité des données valident le schéma, les plages de valeurs, le nombre de valeurs nulles et la fraîcheur à chaque étape, et signalent immédiatement les erreurs au lieu de laisser des données incorrectes se propager en aval.
  4. Planifiez la dérive de schéma. Les systèmes sources évoluent. Les pipelines doivent détecter l'ajout, la suppression ou le renommage de colonnes et gérer ces changements de manière fluide au lieu de s'interrompre.
  5. Utilisez des formats de stockage ouverts. Les formats comme Delta Lake et Apache Iceberg évitent le verrouillage propriétaire et permettent à plusieurs outils de lire les mêmes données sans duplication.
  6. Découplez les couches de pipelines. La division des niveaux du modèle médaillon (Bronze, Silver et Gold) en pipelines distincts facilite la planification, la surveillance et le dépannage de chacun d'eux de manière indépendante.
  7. Contrôlez les versions de tout. Stockez le code et la configuration des pipelines dans Git afin que les modifications soient examinées, traçables et réversibles.
  8. Traitez la gouvernance comme une priorité absolue. Appliquez des autorisations cohérentes, un suivi du lignage et des contrôles d'audit à chaque étape avec un outil comme Unity Catalog, plutôt que de les greffer à la fin.
  9. Adaptez la taille du streaming par rapport au batch. Utilisez le streaming uniquement là où la fraîcheur des données est réellement cruciale, et optez par défaut pour le batch partout ailleurs afin de maîtriser les coûts.
  10. Surveillez de bout en bout. Suivez la fraîcheur, le volume et la qualité des données, ainsi que les temps d'exécution des pipelines, afin de détecter les problèmes avant que les utilisateurs en aval ne s'en aperçoivent.

Pourquoi l'architecture des pipelines de données est importante

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.

L'architecture des pipelines de données sur Databricks

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.

Foire aux questions

Qu'est-ce que l'architecture des pipelines de données en termes simples ?

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.

Quelle est la différence entre l'architecture Lambda et l'architecture Kappa ?

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.

Quand faut-il utiliser des pipelines batch ou streaming ?

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.

Quelle est la différence entre l'architecture logique et l'architecture physique des pipelines ?

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.

Adaptez votre architecture à la tâche à accomplir

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.

Découvrez comment Databricks unifie les pipelines batch et streaming, le stockage et la gouvernance sur une seule plateforme.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original

Recevez les derniers articles dans votre boîte mail

Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.