Architecture big data : lacs, lakehouses, formats et traitements

Peu de domaines du logiciel ont autant souffert du vocabulaire des éditeurs que les plateformes de données. Le terme « big data » a été inventé pour décrire un vrai problème, des jeux de données qu'aucune machine seule ne pouvait contenir ni traiter en un temps acceptable, puis il a été appliqué à presque tout. Résultat : bien des organisations font tourner des clusters distribués sur des données qui tiendraient sur un ordinateur portable.

Ce guide prend au sérieux les décisions d'architecture et regarde avec scepticisme le discours marketing. Il traite de la façon dont les données arrivent, de l'endroit où elles sont stockées, de leur format, de qui peut les modifier et de la manière dont elles sont traitées, sans oublier la section que la plupart des guides de ce genre omettent : comment savoir que vous n'avez besoin de rien de tout cela. Le fonctionnement interne de HDFS, YARN et Spark est détaillé dans le guide de l'écosystème Hadoop ; ici, on s'intéresse à la forme de la plateforme.

Les trois V à l'épreuve

Volume, vélocité et variété forment une liste de contrôle utile, mais une piètre méthode de décision. Chacun mérite une question plus exigeante.

Volume. Le chiffre qui compte n'est pas la quantité de données existante, mais la quantité qu'une requête touche. Une archive d'événements de cent téraoctets interrogée un jour à la fois, c'est un problème de cent gigaoctets avec un bon partitionnement. La compression et le stockage colonnaire réduisent couramment d'un ordre de grandeur les octets scannés, avant même qu'un moteur distribué n'entre en jeu.

Vélocité. Demandez-vous quelle est la latence de décision, pas la latence d'arrivée. Des événements qui arrivent en continu n'exigent pas de calcul en streaming si personne n'exploite le résultat avant le lendemain matin. Les vrais besoins de streaming (scoring antifraude, tarification dynamique, alerting opérationnel) sont ceux où une réponse tardive vaut moins qu'une réponse rapide et approximative.

Variété. C'est le V qui a le mieux résisté. Les bases relationnelles peinent lorsque le schéma diffère d'une source à l'autre et change sans prévenir, et c'est une vraie raison de choisir un lac avec schema-on-read.

On ajoute souvent un quatrième V, la véracité, qui compte davantage que les trois premiers. Un pipeline qui livre cent téraoctets de chiffres subtilement faux est pire qu'un pipeline qui ne livre rien, parce que des gens prennent des décisions sur cette base.

Lac, entrepôt, lakehouse

Un entrepôt de données stocke des données préparées, modélisées et typées, optimisées pour le SQL analytique. Les données sont transformées à l'entrée, le schéma est imposé, et les performances des requêtes sont excellentes parce que l'organisation physique a été pensée pour les questions posées. La contrepartie, c'est la rigidité : une nouvelle source exige un travail de modélisation avant que quiconque puisse l'utiliser, et les données rejetées par le modèle sont tout simplement perdues. La modélisation dimensionnelle des entrepôts est traitée dans le guide de la business intelligence.

Un data lake stocke des fichiers en stockage objet (S3, Azure Blob, Google Cloud Storage) sous la forme où ils sont arrivés, le schéma étant appliqué à la lecture. Il est bon marché, accepte tout et conserve les données brutes pour des questions que personne n'a encore posées. Son mode de défaillance porte un nom : le data swamp, un bucket de fichiers non documentés, sans propriétaire, sans historique de schéma et sans moyen de savoir quelle copie fait foi. Les lacs échouent pour des raisons de gouvernance, pas pour des raisons techniques.

Un lakehouse conserve les fichiers dans des formats ouverts en stockage objet, mais y ajoute une couche de métadonnées qui apporte transactions ACID, évolution de schéma, time travel et élagage efficace des fichiers. Cette couche, c'est un format de table ouvert : Apache Iceberg, Delta Lake ou Apache Hudi. Le résultat se comporte comme une table (vous pouvez faire des UPDATE, DELETE et MERGE et revenir en arrière) tout en restant lisible par n'importe quel moteur qui comprend le format.

Un découpage en couches courant et raisonnable, quel que soit le nom que vous lui donnez :

raw / bronze     immutable landing zone, source format, partitioned by ingest date
curated / silver cleaned, deduplicated, typed, conformed to a common schema
serving / gold   aggregated, modelled tables for dashboards, APIs and data science

Chaque couche est reproductible à partir de la précédente, et c'est ce qui rend possible un retraitement après un bug.

Formats de stockage et organisation physique

Le choix du format pèse davantage sur le coût et la vitesse que le moteur de traitement.

Les formats colonnaires l'emportent en analytique pour trois raisons qui se cumulent. Une requête qui lit trois colonnes sur quatre-vingts ne lit que ces trois-là. Les valeurs d'une même colonne se ressemblent, donc la compression est nettement meilleure qu'en lignes. Enfin, les statistiques par row group permettent au lecteur de sauter des blocs entiers dont la plage min/max ne peut pas satisfaire le prédicat. Ensemble, ces mécanismes transforment un scan complet en une fraction des E/S.

Le partitionnement est un élagage au niveau des répertoires : écrire dt=2026-09-07/region=eu permet à une requête qui filtre sur ces colonnes d'ignorer tout le reste. Deux règles le gardent utile. Partitionnez sur des colonnes présentes dans presque tous les filtres, en général une date. Et gardez une faible cardinalité : partitionner par identifiant client produit des millions de répertoires et un problème de métadonnées bien pire que le scan que vous avez évité.

La taille des fichiers est l'autre moitié du sujet. Visez des fichiers de quelques centaines de mégaoctets. Les écritures en streaming produisent naturellement une multitude de fichiers minuscules : planifiez donc un compactage, que tous les formats de table proposent sous forme d'opération de maintenance. À l'intérieur d'un fichier, trier sur une colonne souvent filtrée rend les statistiques des row groups bien plus sélectives, selon le même raisonnement que le clustering dans un moteur relationnel, abordé dans le guide des index et plans d'exécution.

Les formats de table ouverts apportent ce que de simples répertoires ne peuvent pas offrir : des commits atomiques, pour qu'un lecteur ne voie jamais une mise à jour à moitié écrite ; l'isolation par snapshot et le time travel, pour interroger la table telle qu'elle était la veille ou annuler un chargement raté ; le partitionnement caché, pour que les requêtes n'aient pas à mentionner la colonne de partition ; et l'évolution de schéma par identifiant de colonne plutôt que par position, pour que renommer une colonne ne corrompe pas les anciens fichiers.

Ingestion

Les sources se ramènent à quelques formes récurrentes.

Extractions batch : dumps nocturnes, fichiers de fournisseurs, appels d'API. C'est simple, bien maîtrisé, et c'est la bonne réponse bien plus souvent qu'on ne l'admet. Préférez une extraction incrémentale sur une colonne de watermark plutôt que de tout relire.

La capture des changements de données (CDC) lit le journal de transactions d'une base et émet un flux d'insertions, de mises à jour et de suppressions. C'est la façon la moins intrusive de répliquer une base opérationnelle dans la plateforme : aucune requête sur la source, aucune fenêtre batch, et l'ordre garanti par le journal. C'est aussi là qu'apparaissent la plupart des problèmes de justesse, notamment autour des changements de schéma et des suppressions.

Flux d'événements. Un broker à journal structuré fournit un tampon durable, rejouable et ordonné entre producteurs et consommateurs, et découple leur disponibilité comme leur vitesse. C'est cette capacité de rejeu qui rend le retraitement possible ; voyez l'architecture de Kafka pour le fonctionnement des partitions, des offsets et de la rétention.

Quelle que soit la source, déposez la charge utile brute sans la modifier avant de la transformer. Le stockage ne coûte pas cher ; un bug de transformation irrécupérable, si.

La distinction ETL contre ELT a aussi sa place ici. L'ETL traditionnel transforme avant de charger, si bien que l'entrepôt ne contient jamais que des données modélisées. L'ELT charge les données brutes et les transforme avec la puissance de calcul du moteur cible : c'est moins cher, cela conserve la copie brute et cela transforme les traitements en SQL versionné. L'ELT est le choix par défaut moderne partout où la couche de stockage est bon marché et le moteur élastique.

Traitement

Le traitement batch recalcule sur un jeu de données borné. Apache Spark domine ce terrain, Trino et Presto couvrant le SQL fédéré interactif et les moteurs d'entrepôts cloud le reste. Le batch est plus simple à appréhender, facile à relancer et juste par construction, puisque l'entrée ne bouge pas sous vos pieds.

Le traitement en streaming calcule en continu sur une entrée non bornée, et introduit trois notions dont le batch n'a jamais besoin :

• Temps d'événement contre temps de traitement. Les événements arrivent en retard et dans le désordre. Les résultats fenêtrés doivent reposer sur le moment où quelque chose s'est produit, pas sur celui où on l'a reçu.
• Watermarks. Un watermark est l'affirmation du moteur qu'aucun événement antérieur à un horodatage donné n'est plus attendu ; c'est ce qui permet à une fenêtre de se fermer et d'émettre son résultat.
• État et exactly-once. Les agrégations maintiennent un état qui doit survivre aux pannes, et les sinks doivent être idempotents ou transactionnels pour que les résultats ne soient pas dupliqués lors d'une reprise.

Apache Flink est l'implémentation de référence pour le streaming à faible latence avec état ; Spark Structured Streaming propose le même modèle de programmation que son API batch, avec une exécution en micro-batch ou continue, ce qui est souvent décisif pour les équipes qui utilisent déjà Spark. Kafka Streams convient aux transformations qui vivent dans un service plutôt que dans un cluster.

L'architecture lambda faisait tourner une couche batch pour la justesse à côté d'une couche rapide pour la fraîcheur, et fusionnait les deux au moment de la requête. Elle fonctionne, mais au prix d'une logique métier dupliquée dans deux bases de code, avec deux séries de bugs. L'architecture kappa conserve un seul chemin de streaming et retraite l'historique en rejouant le journal conservé, ce qui est faisable précisément parce que les brokers et les formats de table modernes prennent en charge le rejeu et les écritures idempotentes. Partez sur kappa si vous avez réellement besoin de streaming ; partez sur du batch tout simple sinon.

Gouvernance, qualité et coût

Le travail de plateforme qui détermine si quelqu'un fait confiance aux données n'a rien de glamour, et il est obligatoire.

• Un catalogue (Apache Hive Metastore, catalogues REST Iceberg ou équivalent cloud) recense les tables existantes, leurs schémas et leurs emplacements. Sans lui, on découvre les données en demandant aux collègues.
• Le lignage enregistre quel job a produit quelle table à partir de quelles entrées. Quand un chiffre paraît faux, le lignage fait la différence entre une heure et une semaine d'enquête.
• Les contrats de données font du schéma publié par un producteur un accord explicite, versionné et testé, de sorte qu'un changement en amont casse un build plutôt qu'un tableau de bord.
• Les contrôles qualité s'exécutent dans le pipeline : volumétrie dans les bornes attendues, taux de valeurs nulles, vérifications référentielles, seuils de fraîcheur. Faites échouer le job bruyamment plutôt que de publier discrètement des données fausses.
• Confidentialité et rétention. Des données personnelles dans un lac restent des données personnelles. Sachez où elles se trouvent, chiffrez-les, restreignez-en l'accès et soyez capable de les supprimer, une exigence que de simples fichiers ne peuvent pas satisfaire et que les formats de table permettent de tenir.
• Coût. En stockage objet cloud, la facture dépend des octets scannés et du nombre de requêtes : l'élagage des partitions, le dimensionnement des fichiers et la projection de colonnes sont donc autant des leviers de coût que de performance. Définissez des règles de cycle de vie qui déplacent les partitions froides vers des classes de stockage moins chères.

Quand vous n'avez besoin de rien de tout cela

Acceptez de conclure qu'une plateforme distribuée n'est pas la bonne réponse.

• Une seule instance PostgreSQL gère des centaines de gigaoctets de données analytiques avec du partitionnement et une bonne indexation, comme le décrit le guide des bonnes pratiques SQL.
• Un moteur colonnaire mono-nœud lit directement des fichiers Parquet et surpasse un petit cluster Spark sur des jeux de données allant jusqu'à des centaines de gigaoctets, sans cluster à exploiter.
• Les logs et les données d'observabilité ont leur place dans une plateforme dédiée, pas dans un lac généraliste ; voyez la gestion centralisée des logs.
• Si le besoin est « le métier veut des tableaux de bord », la réponse peut être un entrepôt et un outil de BI, sans aucun lac.

Les meilleures raisons de construire une véritable plateforme de données sont que les données proviennent de nombreux systèmes aux modèles incompatibles, que les consommateurs sont nombreux et variés, ou que les volumes dépassent réellement une machine. En l'absence de ces raisons, la complexité n'apporte rien et coûte une équipe.

Points clés à retenir

• Jugez le volume aux octets scannés par requête, la vélocité à la latence de décision, et ajoutez la véracité à la liste : des données fausses à grande échelle sont pires que pas de données du tout.
• Les entrepôts offrent schéma et vitesse sur des données préparées, les lacs un stockage flexible bon marché, et les lakehouses s'appuient sur des formats de table ouverts pour allier transactions et contrôle de schéma à l'économie du stockage objet.
• Les formats colonnaires, avec élagage des partitions, tailles de fichiers raisonnables et row groups triés, apportent plus de performance que n'importe quel changement de moteur de traitement.
• Déposez les données brutes sans les modifier, organisez les transformations en couches pour que chaque étape soit reproductible, et privilégiez l'ELT avec des transformations versionnées.
• Ne choisissez le streaming que lorsqu'une décision en dépend, et préférez un seul chemin rejouable à la maintenance de deux copies, batch et streaming, de la même logique.
• Catalogue, lignage, contrats de données, contrôles qualité et règles de rétention sont ce qui rend une plateforme digne de confiance ; sans eux, un lac devient un marécage.