Analytique, streaming, entrepôts de données, data lakes et data mesh

Deux charges de travail différentes : OLTP et OLAP

Tout ce chapitre a jusqu’ici porté sur le traitement transactionnel en ligne (OLTP) : de nombreuses lectures et écritures petites et rapides d’enregistrements individuels, comme passer une commande, enregistrer un paiement ou mettre à jour la position d’un livreur. L’analytique pose un autre type de question. Quel a été le chiffre d’affaires par type de cuisine et par région, semaine après semaine, sur les deux dernières années ? touche des millions de lignes, ne lit que quelques colonnes de chacune et ne modifie rien. C’est le traitement analytique en ligne (OLAP), et il diffère tellement de l’OLTP qu’exécuter les deux sur la même base de données ne sert généralement bien ni l’un ni l’autre : une seule grosse requête analytique peut saturer les disques et le cache de tampons dont dépend l’étape de paiement, et le schéma normalisé qui garantit la justesse des transactions oblige les analystes à joindre une douzaine de tables.

La réponse architecturale classique consiste à séparer les charges de travail. Les systèmes opérationnels gardent leurs propres bases de données, détenues par leurs services comme l’a décrit la section 7.1. Les données sont copiées, en continu ou périodiquement, vers une plateforme analytique conçue pour les parcours de données : un stockage en colonnes qui ne lit que les colonnes nécessaires, une forte compression, des moteurs de requêtes massivement parallèles et des schémas pensés pour l’analyse. Le reste de cette section explique comment cette plateforme est conçue, comment les données y parviennent, ce que le streaming change et à qui appartient le résultat.

Entrepôts de données et modélisation dimensionnelle

Un entrepôt de données (data warehouse) est une base de données conçue pour l’analyse, qui intègre des données nettoyées provenant de nombreux systèmes opérationnels et en conserve l’historique. Deux écoles ont façonné la conception des entrepôts, et les praticiens en débattent encore. Bill Inmon, souvent appelé le père de l’entrepôt de données (Building the Data Warehouse, 1992), prône une conception descendante : un entrepôt intégré, normalisé, à l’échelle de l’entreprise, est construit d’abord comme source unique de vérité, et des data marts départementaux en sont ensuite dérivés. Ralph Kimball (The Data Warehouse Toolkit, publié pour la première fois en 1996, troisième édition avec Margy Ross en 2013) prône une conception ascendante : construire des modèles dimensionnels un processus métier à la fois, et les intégrer au moyen de dimensions conformes partagées (une seule définition convenue du client, de la date ou du restaurant, utilisée par tous les modèles). L’approche d’Inmon offre une intégration plus forte pour un coût initial plus élevé ; celle de Kimball produit plus tôt des résultats exploitables, mais demande de la discipline pour que les dimensions restent conformes. De nombreuses plateformes modernes mélangent les deux : une couche nettoyée et intégrée qui alimente des modèles dimensionnels destinés à la consommation.

Le schéma en étoile de Kimball reste le modèle analytique le plus enseigné. Une table de faits centrale enregistre des événements métier à un grain déclaré (une ligne par ligne de commande, par paiement, par signal de position d’un livreur), avec des mesures numériques comme la quantité, le montant et les minutes, et des clés étrangères vers des tables de dimensions. Chaque dimension contient des attributs descriptifs servant à filtrer et à regrouper : les dates (avec jour de la semaine, mois et indicateur de jour férié précalculés), les restaurants (nom, type de cuisine, ville), les clients et les plats. Les requêtes se réduisent à une table de faits jointe à quelques petites dimensions, ce que les moteurs en colonnes exécutent très efficacement. Les attributs qui changent au fil du temps, comme un restaurant qui change de ville, sont gérés par des techniques de dimension à évolution lente (slowly changing dimension) ; la plus courante, le type 2, ajoute une nouvelle ligne de dimension avec des dates de validité, si bien que les faits historiques pointent toujours vers les attributs qui étaient vrais à l’époque.

-- Revenue and average delivery time by cuisine and weekday for last quarter.
-- One join per dimension; the fact table is scanned, never updated.
SELECT r.cuisine,
       d.weekday,
       SUM(f.line_total_pence) / 100.0 AS revenue_gbp,
       AVG(f.delivery_minutes)          AS avg_delivery_min
FROM   fact_order_line f
JOIN   dim_date       d ON d.date_key       = f.date_key
JOIN   dim_restaurant r ON r.restaurant_key = f.restaurant_key
WHERE  d.quarter = '2026-Q2'
  AND  r.region  = 'North West'
GROUP  BY r.cuisine, d.weekday
ORDER  BY revenue_gbp DESC;
-- Caveat: delivery_minutes is per order, so averaging it over order LINES
-- weights big orders more. Grain decisions matter (see the worked example).

Faire entrer les données : ETL, ELT et capture des données modifiées

Les données parviennent à l’entrepôt par des pipelines. Dans l’ETL classique (extract, transform, load : extraire, transformer, charger), un outil séparé extrait les données des systèmes sources, les nettoie et les remodèle sur ses propres serveurs, et ne charge que le résultat. Depuis que les entrepôts cloud ont rendu le stockage bon marché et le calcul élastique, l’ELT est devenu courant : extraire et charger d’abord les données brutes, puis les transformer à l’intérieur de l’entrepôt avec du SQL, souvent géré sous forme de modèles versionnés et testés avec un outil comme dbt. L’ELT conserve les données brutes, de sorte que les transformations peuvent être corrigées et relancées ; son risque est que des données à caractère personnel brutes se diffusent plus loin que nécessaire.

La manière dont les données sont extraites compte tout autant. Les copies complètes nocturnes sont simples, mais lentes et vite périmées. La capture des données modifiées (CDC) lit le journal de réplication propre à la base de données (le write-ahead log de PostgreSQL, le binlog de MySQL) avec un outil comme Debezium et diffuse chaque insertion, mise à jour et suppression sous forme d’événement, avec une faible latence et peu de charge sur la source. Quel que soit le mécanisme, lire directement les tables d’un autre service couple la plateforme analytique au schéma privé de ce service, exactement le problème décrit à la section 7.1. Le patron le plus robuste consiste pour chaque service à publier délibérément ses données, par des événements ou un export convenu, dans le cadre d’un contrat de données.

Data lakes, lakehouses et formats de table ouverts

Un data lake (lac de données), terme attribué à James Dixon (2010), stocke des données brutes provenant de nombreuses sources sous leur forme d’origine, généralement sous forme de fichiers sur un stockage objet bon marché comme Amazon S3, souvent dans des formats en colonnes comme Apache Parquet. Il reporte le schéma au moment de la lecture des données, ce qui convient aux data scientists qui veulent le détail brut et aux données dont l’usage n’est pas encore connu. Les lacs se sont fait la réputation de devenir des marécages de données (data swamps) : sans propriétaires, documentation ni contrôles de qualité, personne ne fait confiance à ce qu’ils contiennent. Les fichiers sur un stockage objet n’ont pas non plus ce qu’offre un entrepôt : transactions, mises à jour et suppressions, application du schéma et lectures cohérentes pendant l’écriture des données.

Le lakehouse (Armbrust, Ghodsi, Xin et Zaharia, CIDR 2021) ajoute ces fonctionnalités d’entrepôt par-dessus les fichiers ouverts du lac. La technologie qui le permet est le format de table ouvert (open table format) : Delta Lake (créé chez Databricks), Apache Iceberg (créé chez Netflix) et Apache Hudi (créé chez Uber). Chacun tient une couche de métadonnées (un journal de transactions ou une arborescence de fichiers manifestes) qui enregistre quels fichiers de données composent chaque version d’une table. Cela apporte des validations atomiques, des écritures concurrentes avec contrôle de concurrence optimiste, l’évolution des schémas, les mises à jour et suppressions au niveau des lignes (nécessaires pour les demandes d’effacement) et le voyage dans le temps (time travel) : interroger une table telle qu’elle était dans une version antérieure. Comme le format est ouvert, plusieurs moteurs (Spark, Trino, Flink et, de plus en plus, les entrepôts cloud eux-mêmes) peuvent lire et écrire les mêmes tables, ce qui réduit la dépendance au fournisseur. De nombreux lakehouses organisent les données en couches, popularisées par Databricks sous le nom d’architecture en médaillon : bronze pour les données brutes ingérées, argent pour les données nettoyées et conformes, or pour les modèles de niveau métier comme les schémas en étoile.

Traitement de flux : temps de l’événement, fenêtres et filigranes

Les pipelines batch répondent à des questions sur la veille. Certaines questions ne peuvent pas attendre : cette carte est-elle utilisée frauduleusement en ce moment, les livreurs de Manchester sont-ils en retard ce soir, quels restaurants faut-il mettre en pause parce que leurs cuisines sont débordées ? Des processeurs de flux comme Apache Flink, Kafka Streams et Spark Structured Streaming calculent en continu sur des flux d’événements non bornés. Les concepts essentiels viennent du modèle Dataflow de Google (Akidau et ses collègues, VLDB 2015).

Le premier est la différence entre le temps de l’événement (event time), le moment où quelque chose s’est réellement produit, et le temps de traitement (processing time), le moment où le système l’observe. Ils diffèrent à cause des délais réseau, des nouvelles tentatives, du traitement par lots et des appareils qui se retrouvent hors ligne : le téléphone d’un livreur, dans un ascenseur, enregistre une remise à 19:03 mais transmet l’événement à 19:13. Tout résultat censé refléter la réalité (commandes par tranche de cinq minutes, délai moyen de livraison par heure) doit être calculé selon le temps de l’événement, sinon il se décalera dès que le pipeline ralentit et sera faux lorsqu’il sera rejoué.

Le deuxième est celui des fenêtres, qui découpent un flux non borné en morceaux finis à agréger : les fenêtres bascules (tumbling) sont fixes et ne se chevauchent pas (toutes les cinq minutes), les fenêtres glissantes (sliding) se chevauchent (les dix dernières minutes, mises à jour chaque minute) et les fenêtres de session regroupent par clé des rafales d’activité séparées par une période d’inactivité (la session de navigation d’un client).

Le troisième est le filigrane (watermark) : l’estimation évolutive, faite par le processeur, que tous les événements jusqu’à un temps d’événement donné sont probablement arrivés. Lorsque le filigrane dépasse la fin d’une fenêtre, le résultat de la fenêtre peut être émis. Les filigranes sont des heuristiques ; certains événements arrivent donc encore après la fermeture de leur fenêtre. Le pipeline a besoin d’une règle explicite pour ces données tardives : les ignorer, les envoyer vers une sortie secondaire pour une correction ultérieure, ou garder les fenêtres ouvertes pendant un retard autorisé et émettre des résultats mis à jour. Attendre plus longtemps donne des réponses plus complètes ; émettre plus tôt en donne de plus fraîches. Ce compromis entre latence et complétude est la version propre au traitement de flux d’un compromis entre attributs de qualité, et il doit être tranché avec le métier.

Architectures Lambda et Kappa

Comment combiner les résultats batch et streaming ? L’essai de Nathan Marz de 2011, How to beat the CAP theorem, a décrit ce qui est devenu l’architecture Lambda : un jeu de données maître immuable alimente une couche batch qui recalcule périodiquement des vues exactes à partir de toutes les données, et une couche rapide (speed layer) qui calcule en temps réel des vues approximatives des données récentes ; les requêtes fusionnent les deux, et chaque exécution batch remplace les approximations de la couche rapide. Lambda apporte exactitude et faible latence, et la couche batch sert de filet de sécurité contre les bugs du streaming. Son coût est que la même logique doit être écrite, et maintenue identique, dans deux frameworks différents.

En 2014, Jay Kreps, l’un des créateurs d’Apache Kafka, a remis en question cette conception et proposé l’architecture Kappa, un nom qu’il avançait à moitié en plaisantant. N’utilisez qu’un processeur de flux, et conservez l’entrée dans un journal assez longtemps pour pouvoir la rejouer. Pour changer la logique, lancez une seconde instance du nouveau job qui lit depuis le début du journal et écrit dans une nouvelle table de sortie, et faites basculer les lecteurs vers celle-ci une fois qu’elle a rattrapé son retard. Une seule base de code, et retraiter revient simplement à rejouer. Kappa dépend d’une longue conservation du journal et de processeurs de flux assez bons pour gérer correctement le temps de l’événement et l’état, ce que fournissent les moteurs modernes. Aujourd’hui, la plupart des nouvelles conceptions penchent vers un streaming de style Kappa avec un lakehouse pour l’historique, tandis que les conceptions de style Lambda persistent là où le recalcul par lots sur de très longs historiques coûte moins cher ou là où les pipelines batch existants inspirent confiance.

Data mesh : la propriété des données analytiques

À mesure que les organisations grandissaient, les équipes de données centrales sont devenues des goulets d’étranglement : chaque nouvelle source et chaque nouvelle question faisaient la queue derrière une seule équipe qui ne comprenait très bien ni les systèmes sources ni les questions métier. En 2019, Zhamak Dehghani, alors chez Thoughtworks, a proposé le data mesh (développé ensuite dans son livre de 2022, Data Mesh). Il applique aux données analytiques la même décentralisation que les microservices ont appliquée aux systèmes opérationnels, et il repose sur quatre principes.

Propriété par domaine : les équipes les plus proches des données, comme celles des commandes, des paiements ou des livreurs, détiennent et servent leurs données analytiques, tout comme elles détiennent leurs services. La donnée en tant que produit : chaque équipe publie des produits de données (data products) faciles à découvrir, documentés, dignes de confiance, adressables et sécurisés, avec un propriétaire et des objectifs de qualité, en traitant les autres équipes comme des clients. Plateforme de données en libre-service : une équipe plateforme fournit le stockage, les pipelines, le catalogue et le contrôle d’accès qui rendent la publication d’un produit de données peu coûteuse, afin que chaque domaine n’ait pas à les réinventer. Gouvernance computationnelle fédérée : les règles globales (identifiants, classifications de confidentialité, normes d’interopérabilité) sont convenues conjointement et appliquées automatiquement par la plateforme plutôt que par un comité de revue central.

Le data mesh est une conception organisationnelle autant qu’une architecture, et les avis divergent sur le moment où il devient rentable. Ses partisans mettent en avant l’échelle : il supprime le goulet d’étranglement central et place la qualité des données là où se trouve la connaissance. Ses détracteurs font remarquer qu’il exige des équipes de domaine matures, une plateforme solide et un réel investissement, et que les organisations plus petites sont généralement mieux servies par une plateforme centrale bien gérée, avec une propriété claire de chaque jeu de données. La loi de Conway (section 3.7) s’applique directement : l’architecture des données reflétera la structure que l’organisation adopte réellement.

Qualité, lignage, catalogues et confidentialité

Les données analytiques ne sont utiles que si l’on s’y fie. Les contrôles de qualité des données s’exécutent dans les pipelines et testent la fraîcheur (le chargement du jour est-il arrivé ?), le volume (le nombre de lignes a-t-il chuté de moitié ?), le schéma (une colonne a-t-elle changé de type ?), la validité (les montants sont-ils positifs et les codes postaux bien formés ?) et l’unicité. Un contrôle en échec doit arrêter le pipeline ou mettre les données en quarantaine plutôt que de les publier en silence. Le lignage des données (data lineage) enregistre d’où vient chaque jeu de données et quelles transformations l’ont produit, de sorte que lorsqu’un chiffre semble faux, ou qu’un schéma source change, vous pouvez en retracer l’impact en amont et en aval ; la spécification OpenLineage normalise la façon dont les pipelines le rapportent. Un catalogue de données rend les jeux de données faciles à découvrir, avec leurs descriptions, propriétaires, classifications et lignage en un seul endroit.

Les plateformes analytiques concentrent les données, ce qui les rend attrayantes pour les attaquants et risquées au regard du droit de la protection des données. Appliquez la minimisation des données (ne copiez pas les champs personnels dont aucune analyse n’a besoin), pseudonymisez les identifiants lorsque c’est possible, classifiez les colonnes pour que les politiques d’accès suivent les données, faites respecter les durées de conservation par une suppression automatisée, et veillez à ce que les demandes d’effacement atteignent le lac et l’entrepôt autant que les systèmes opérationnels ; les formats de table ouverts y aident parce qu’ils prennent en charge les suppressions au niveau des lignes. La section 8.7 présente les obligations en détail.