Pipeline de données : Définition et mise en oeuvre

Le pipeline de données est l’ensemble des process & outils qui organisent la circulation des données dans le SI et les transformations nécessaires à vos cas d’usage métiers qui nécessitent l’utilisation de données.

Comment sont extraites les données générées par vos sources de données ? Comment sont-elles chargées dans votre base de référence ? Comment sont-elles transformées pour devenir exploitables par vos outils de BI et d’activation ? Le pipeline de données répond à ces 3 questions.

Nous allons voir que l’approche ETL classique cède progressivement le pas devant les approches modernes, cloud et ELT, plus souples et moins coûteuses.

Certaines entreprises tiennent à développer des pipelines de données sur-mesure. Est-ce une bonne idée ? Nous vous partagerons notre avis sur le sujet en fin d’article.

Qu’est-ce qu’un Pipeline de données ? [Définition]

La définition d’un « pipeline » d’après Wikipédia : « Tuyau servant au transport à grande distance et en grande quantité de fluides (pétrole, gaz naturel…) ». Si vous savez ce qu’est un pipeline et que vous savez ce que sont des données, vous comprendrez assez facilement le concept de pipeline de données.

Un pipeline de données est une notion utilisée pour décrire la manière dont la donnée circule entre les bases et les outils du système d’information de l’entreprise. Un pipeline de données organise le transfert de données d’un système à l’autre.

Mais c’est là où s’arrête la comparaison avec le pipeline pétrolier et gazier : Le pipeline de données ne fait pas simplement que transporter la donnée, il la transforme dans son chemin – ce chemin qui commence là où est générée la donnée (les sources de données) et qui s’achève dans les outils d’exploitation de la donnée : BI et activation (CRM, marketing…). Le pipeline de données ne se réduit pas à de la tuyauterie, c’est aussi une machinerie – une raffinerie pour filer la métaphore.

Les 4 étapes de traitement d’un pipeline de données

Première étape – Collecte & Extraction

Tout d’abord, la donnée est collectée ou extraite à partir des sources de données de l’entreprise. Ces sources de données peuvent être des fichiers Excel, des bases de données et autres applications diverses et variées.

A ce stade du chemin, la donnée est dans son état brut. Elle n’est ni structurée, ni classée. Elle n’a fait l’objet d’aucune transformation, et a fortiori d’aucuns traitements. On trouve des données de nature très différentes. A ce stade, les données de l’entreprise ne sont pas encore exploitables, même si elles constituent la matière première de toutes exploitables possibles.

Deuxième étape – Gouvernance des données

Ensuite, la donnée est organisée, nettoyée. Elle passe par le filtre des règles de gouvernance des données définies par l’entreprise. Ls données sont filtrées, triées. Mais, à ce stade, les données qui passent le filtre ne sont toujours pas exploitables. Elles doivent être raffinées, transformées.

Troisième étape – Transformation des données

Les données sont ensuite transformées en informations exploitables par l’entreprise. Cette étape de transformation se réalise au moyen d’un certain nombre d’opérations sur les données :

• Nettoyage des données. Les données n’ayant pas de valeur (parce qu’inutiles ou invalides) pour l’entreprise sont supprimées.
• Normalisation. La normalisation décrit la manière dont les données retenues doivent être formatées et stockées dans la base (dessins d’enregistrement).
• Dédoublonnage. Les doublons de données (données rendondantes) sont identifiés et supprimés. A ce propos, il ne faut pas confondre dédoublonnage et déduplication. Il y a doublon lorsqu’une donnée est présente plusieurs fois dans la même base, dans le même fichier. Il y a duplication lorsque la même donnée est présente dans  plusieurs fichiers ou bases. Au niveau qui nous intéresse, c’est bien de dédoublonnage dont on parle. La déduplication intervient à un stade plus avancé du trajet des données et constitue une opération clé pour la construction d’un Référentiel Client Unique.
• Vérification. Les outils utilisées pour le pipeline de données vérifient automatiquement la validité des données et détectent les anomalies. La vérification est garante de la fiabilité et de la qualité des données qui seront exploitées en BI et en activation.
• Classement. Les données sont organisées en catégories, en fonction de leur état et de leur format.

Quatrième étape – Exploitation des données

La dernière étape est la mise à disposition des données transformations aux différents systèmes utilisateurs de données. Ces systèmes sont de deux natures :

• Les outils de Business Intelligence, de BI, qui servent à analyser les données, à les présenter sous forme de rapports. Les outils de Data Vizualisation font partie de cette catégorie. Ces outils servent à découvrir des enseignements à partir des données et à prendre des décisions data-driven.
• Les outils d’activation : CRM, Marketing Automation, outils du service client, plateformes publicitaires…

Le pipeline de données est garant de la disponibilité des données, mais aussi de leur qualité, de leur sécurité.

L’ordre de ces étapes peut varier :

• Si vous utilisez un outil ETL (Extract – Transform – Load), les données seront transformées avant d’être chargées dans une base de données (en colonnes, généralement relationnelle > ces bases de données sont de type Data Warehouse).
• Si vous utilisez un outil ELT, les données seront d’abord chargées en vrac dans la base (qui sera de type Data Lake) avant d’être transformées.

ETL, Cloud, ELT – Les différents types de Data Pipelines

Il existe plusieurs types de pipelines de données. Nous allons vous en présenter les principaux : l’ETL, l’ETL Cloud et l’ELT.

L’approche traditionnelle : l’ETL

L’ETL est l’approche classique pour construire un pipeline de données. Le nom de cette famille d’outils décrit le cheminement de la donnée : Extract – Transform – Load. En bon français : Extraire, transformer et charger. Les ETL sont l’approche dominante depuis les années 1970. Nous n’avons clairement pas affaire à une nouvelle famille d’outils. C’est d’ailleurs important d’avoir cet historique en tête. Les ETL ont connu leur heure de gloire à une époque où les ordinateurs, le stockage et la bande passante étaient rares et très chers. Les ETL sont toujours utilisés mais ils commencent à avoir quelque chose d’anachronique à l’heure du Cloud. La puissance des machines a incroyablement augmenté, le coût du stockage incroyablement diminué.

Mais revenons au fonctionnement de l’ETL. Un ETL est un outil qui permet d’extraire les données à partir des sources de données (n’importe quelle application, fichier, base, etc.) pour l’acheminer dans un Data Warehouse. Mais, si vous lisez ce blog, vous savez qu’un Data Warehouse est une base organisée qui n’accepte que des données structurées. Or, les données en provenance des sources de données ne sont pas structurées. Si certaines le sont, elles ne le sont pas toutes de la même manière. Bref, on ne peut pas faire directement entrer les données extraites des sources dans la base de données DWH. Il faut au préalable les transformer. C’est ce que fait l’ETL. Il extrait les données à partir de connecteurs, leur applique des transformations et enfin seulement les charge dans la base de destination : le Data Warehouse.

Historiquement, les ETL ont été utilisés pour charger des données en batch (sous forme de lots) dans les bases de destination, souvent à large échelle. Il existe désormais des ETL qui permettent de charger la donnée en temps réel ou en quasi temps réel. C’est ce que l’on appelle le « streaming de données ». Avec ces outils plus modernes, les données arrivent en continu dans la base.

Le schéma ci-dessous présente les étapes à suivre pour construire un pipeline de données ETL :

Si vous voulez construire un pipeline de données ETL pour faire de la BI, vous devez commencer par identifier les sources de données à utiliser et les objectifs du reporting. Ensuite, vous définissez un modèle de données, qui détermine la manière dont ces données apparaîtront dans le reporting. De ce modèle découlent les transformations à opérer sur les données. Vous créez et configurez ensuite le pipeline de données ETL (via l’outil ETL que vous aurez sélectionné) pour qu’il réalise les transformations nécessaires sur les données. Ces données sont ensuite chargées dans la base de données (de type Data Warehouse), à laquelle est connectée un outil de BI qui permet de créer des visualisations de données (reporting). Voici très schématiquement la démarche à adopter.

Nous avons déjà montré les limites inhérentes à cette architecture IT associant un outil ETL à un Data Warehouse. Nous vous renvoyons vers les articles publiés sur le sujet sur le blog Cartelis. Ces limites tiennent précisément au fait que la donnée est transformée avant d’être chargée. En quoi est-ce problématique ? C’est assez simple à comprendre : tout le dispositif est designé et « fixé » a priori sur la base de cas d’usage précis. Changer quelque chose dans le process d’extraction (ajout ou suppression de sources, changements des modalités et/ou conditions d’extraction), dans le process de transformation (nettoyage, normalisation, modèle de données…), dans le process de chargement dans la base cible sont des opérations complexes et coûteuses. Faire évoluer un pipeline de données ETL n’est pas une mince affaire. Un pipeline basé sur un dispositif ETL + Data Warehouse est rigide.

Découvrez quelle est la différence entre un Data Lake et un Data Warehouse.

Voici deux autres inconvénients des pipeline de données ETL :

• Les outils ETL ne sont pas accessibles aux petites et moyennes entreprises. Pour construire et maintenir un pipeline de données ETL, vous aurez besoin de data engineers. Toutes les organisations n’ont pas les moyens de monter une DSI…A cela s’ajoute un coût d’hébergement important si vous choisissez un ETL « On Premise ». « On Premise » signifie que vous devez installer l’ETL sur vos machines, sur vos serveurs (« On Premise » s’oppose à « Cloud »).
• Les pipelines de données ETL sont assez complexes à mettre en œuvre. Ils sont construits à base de codes custom dictés par les besoins spécifiques des transformations spécifiques.

L’approche moderne : Cloud

N’importe quel observateur peut constater que l’une des grosses tendances technologiques est la réduction du coût des machines, du stockage et de la bande passante. L’une des conséquences, c’est que les Data Warehouses peuvent dorénavant gérer des volumes énormes de données. Cette réduction des coûts est ce qui a permis l’essor du « Big Data ». Les organisations n’ont plus besoin de discriminer les sources de données pour optimiser la vitesse de traitement. Elles peuvent toutes les accueillir. Cette facilité à accueillir de gros volumes de données est une aubaine pour les analystes qui voient leur pouvoir d’analyse démultipliés. Parallèlement, le coût de transfert des données via l’internet a considérablement baissé.

Ces tendances ont permis l’essor du Cloud. Le Cloud désigne l’utilisation de ressources informatiques à distance, via internet, sur un mode décentralisé. De plus en plus d’applications et de services sont accessibles dans le Cloud. L’avantage du Cloud est qu’il permet de se libérer des contraintes des infrastructures physiques.

L’hébergement cloud résout la plupart des problématiques de scale et d’accessibilité. Les entreprises peuvent ajouter ou supprimer des ressources de stockage en quelques clics et les utilisateurs accéder à des tableaux de bord et des rapports via des interfaces web.

On observe depuis quelques années l’explosion du nombre de solutions ETL Cloud. Stitch Data et Fivetran sont deux exemples emblématiques.

Découvrez notre comparatif complet des outils ETL : Cloud, On-Premise et Open Source.

L’approche moderne : l’ELT

Le Cloud a permis une modernisation du marché des outils ETL. Mais une nouvelle famille d’outils a émergé : c’est ce que l’on appelle les ELT, pour Extract-Load-Transform. Ces outils mettent en oeuvre une nouvelle approche en matière de pipeline de données. L’idée est simple : il s’agit de streamer la donnée et de la charger dans la base de destination sans la transformer. Autrement dit, on inverse la séquence utilisée dans les pipeline de données classiques. On charge avant de transformer.

Le développement des outils ELT est inséparable de l’essor du Cloud que nous avons analysé plus haut. Les outils ELT sont par construction des outils Cloud, c’est-à-dire des technologies SaaS. Seul le Cloud permet en effet un streaming temps réel. Correctement implémenté, un pipeline de données ELT permet d’intégrer la donnée en continu, avec le minimum d’intervention manuel et de codes custom.

L’inversion des étapes de chargement et de transformation résout les principales problématiques des ETL, c’est-à-dire :

• Le problème de la complexité. Un pipeline de données ELT est un pipeline simplifié. Il permet de charger les données dans la base de manière simple, puisqu’il n’y a pas de transformations. Dans les infrastructures ETL classiques, c’est sur les data engineers (c’est-à-dire des profils techniciens, non-business) que repose tout le travail de construction et de maintenance de la tuyauterie. Dans une infrastructure ELT, ce sont les analystes, les data scientists, qui transforment la donnée stockée dans la base en utilisant du SQL. Avec une infrastructure ELT, ce sont les analystes et plus largement les utilisateurs métier qui reprennent le contrôle sur le pipeline de données.
• Le problème de la rigidité. Un pipeline ELT est plus résilient, plus facile à faire évoluer. La raison est simple : on ne prédétermine pas les transformations en amont (en phase de design du pipeline). Les transformations sont effectuées après que les données aient rejoint la base dans leur forme brute. Typiquement, l’ajout d’une nouvelle source de données n’oblige pas à redesigner le pipeline et de faire appel aux data engineers. Ce sont les analystes qui gèrent – et ça se gère de manière assez simple !
• Le problème du coût. Un pipeline de données ELT est moins coûteux car plus simple à maintenir. Cette simplicité découle des points précédents. On l’a vu, le rôle des ingénieurs data dans la maintenance du pipeline est réduit, ce qui permet de leur libérer du temps pour des tâches à plus forte valeur ajoutée (machine learning…). Dans les faits, la maintenance du pipeline de données (des phases « Extraction » & « Chargement ») est souvent externalisée et automatisée. Un ELT permet à l’entreprise de concentrer ses efforts sur ce qui importe le plus : la transformation des données et, derrière, leur exploitation en BI ou en activation.

3 exemples d’architectures de Pipeline de données

Il existe plusieurs modèles d’architecture pour un pipeline de données : l’architecture simple, l’architecture streaming et l’architecture lambda.

Architecture Simple

Dans cette architecture simple, le pipeline de données est basé sur un process en batch. Il est construit selon le process ETL classique. On a en début de chaîne une source de données qui génère un grand nombre de data points que vous allez pousser dans un Data Warehouse ou une base de BI après plusieurs opérations de transformation.

Architecture streaming

Dans ce modèle d’architecture, la donnée extraite est processée en même temps qu’elle est générée. La donnée récupérée des sources est délivrée en continue et en quasi-temps-réel aux outils d’analyse et d’activation. C’est l’opposé de l’approche batch qui consiste à basculer les données extraites des sources dans la base sous forme de lots, de manière discontinue donc. Les enjeux autour du temps réel rende l’architecture streaming de plus en plus incontournable. Les pipelines de données construits sur cette approche utilisent plusieurs applications, contrairement au pipeline de données ETL simple, qui ne repose que sur une technologie : l’ETL.

Architecture Lambda

Cette architecture combine l’approche batch et l’approche streaming. L’architecture Lambda est populaire dans les environnements Big Data puisqu’elle permet aux développeurs de tenir compte à la fois des cas d’usage du streaming en temps réel et des cas d’usage historique du batch processing. L’une des clés de cette architecture est qu’elle encourage le stockage des données dans leur format brut, ce qui facilite l’évolution du pipeline de données.

Construire un Pipeline de données sur-mesure : Est-ce vraiment une bonne idée ?

Lorsque l’on a des cas d’usage bien spécifiques et assez complexes, la tentation est grande de construire un pipeline de données ELT sur-mesure. Mais il faut bien y réfléchir à deux fois avant de se lancer dans une telle entreprise. Nous allons voir que, en général, ce n’est pas l’approche la plus appropriée et qu’il est plus pertinent d’opter pour une solution ELT sur l’étagère. Précisons que nous ne discuterons ici que de l’approche ELT Cloud. Nous avons vu les limites des pipelines de données ETL traditionnels.

Construire un pipeline de données ELT sur-mesure est à la fois chronophage et coûteux

Aujourd’hui, pratiquement 80% du temps des Data Scientists est passé à construire des pipeline de données, tâche pour laquelle les Data Scientists ont des aptitudes limitées et un intérêt assez faible. Or, créer et assurer la maintenance d’un pipeline de données sur-mesure est chronophage, en plus d’être coûteux (le temps c’est de l’argent, à plus forte raison quand on parle du temps d’un Data Scientist). Supposons que vous souhaitiez créer 5 connecteurs, pour votre CRM, votre solution de ticketing, votre plateforme publicitaire, votre outil de gestion de projet et votre système de gestion des abonnements. Dites-vous qu’il vous faudra compter environ 5 semaines de temps de travail par connecteur (à supposer que les APIs soient dociles et bien documentées). Chaque connecteur nécessitera probablement une semaine de travail de maintenance par trimestre. Faites-le calcul, cela fait entre 45 semaines de jour-homme par an. On parle de jour-homme de Data Scientist ou d’ingénieur data. Cela fait donc un sacré budget !

Vous n’êtes pas sans savoir que les entreprises utilisent désormais des dizaines et des dizaines d’applications. Vous aurez largement besoin de plus de 5 connecteurs…

La morale de l’histoire

Il y a 5 raisons qui incitent à la prudence si vous avez un projet de pipeline sur-mesure (et potentiellement chaque raison est suffisante pour changer d’avis) :

• Le temps passé à construire et maintenir le pipeline de données sera fatalement du temps qui pourrait être utilisé pour des tâches à plus forte valeur ajoutée et plus gratifiante pour vos ingénieurs data / data scientists.
• Maintenir l’intégrité du pipeline de données est complexe et générera à la longue de l’épuisement et de la frustration pour les personnes qui en ont la responsabilité. Pour tous les professionnels de la data, la maintenance des données est une corvée.
• Votre pipeline de données a vocation à évoluer, en général dans le sens d’une complexification. Vous voudrez forcément à un moment ou à un autre ajouter une nouvelle source de données. Cela créera régulièrement des moments d’arrêt.
• Il y aura un décalage entre le moment où la BI fait une demande de données et le moment où elle découvre des enseignements à partir de l’analyse des données. Ce qui peut conduire à prendre de mauvaises décisions – des décisions basées sur des enseignements tirés de données obsolètes.

La morale de l’histoire est qu’il est plus intéressant d’externaliser le pipeline de données en utilisant une solution ELT sur l’étagère. C’est notre conviction. Inutile de chercher à réinventer la roue. Vous l’aurez sans doute deviné, la solution que nous privilégions aujourd’hui dans nos accompagnements est l’approche ELT Cloud. C’est clairement vers de ce type de pipeline de données que tend la flèche de l’histoire.

Si vous avez des remarques, des commentaires ou que vous souhaitez discuter de votre projet data, n’hésitez pas à nous contacter.

CRM / Data - Plus de 15 ressources & templates gratuits à télécharger.

Découvrir