Architectures de stockage : entrepôt, lac, lakehouse
Cette leçon compare le motif architectural derrière votre stockage — indépendamment de tout fournisseur — selon la description, les compromis et le contexte où chacun trouve sa place.
- Distinguer une base de données opérationnelle (OLTP) des motifs de stockage analytique
- Comparer entrepôt, lac et lakehouse selon la gestion du schéma, le coût et les garanties de cohérence
- Expliquer où se situent les data marts et le data mesh par rapport à un entrepôt ou un lakehouse
- Faire correspondre les couches medallion HIC au motif d’entrepôt de données
Où se situe chaque motif
Les systèmes sources alimentent la base de données opérationnelle qui fait tourner l’application. Des copies analytiques de ces données rejoignent ensuite l’un des trois magasins analytiques, selon le degré de structure appliqué et le moment où on l’applique.
Base de données opérationnelle (OLTP)
Le système transactionnel de référence en production — par exemple, la base de données sur laquelle DHIS2 lui-même s’exécute.
| Avantages | Inconvénients |
|---|---|
| Optimisée pour des lectures/écritures rapides et fiables d’enregistrements individuels | Pas conçue pour les agrégations lourdes ni les balayages massifs |
| Cohérence forte (transactions ACID) | Y exécuter l’analytique directement risque de ralentir l’application en production |
| Existe déjà — rien de nouveau à mettre en place |
Entrepôt de données
Un magasin structuré, où le schéma vient d’abord, construit spécifiquement pour l’analytique — les données sont nettoyées et modélisées avant d’y atterrir. Exemples : Snowflake, BigQuery, Redshift, Postgres.
| Avantages | Inconvénients |
|---|---|
| Requêtes rapides et fiables — données pré-modélisées (schémas en étoile, dimensions/faits) | Rigide — le schéma doit être défini avant le chargement (« schéma à l’écriture ») |
| Cohérence forte, gouvernance et contrôle d’accès | Peine avec les données non structurées (images, texte libre, logs) |
| Support mature des outils de BI | Peut devenir coûteux à grande échelle selon le modèle de tarification |
Lac de données
Un vaste magasin à bas coût qui conserve les données brutes dans leur format natif — structurées, semi-structurées ou non structurées. Exemples : Amazon S3, Azure Data Lake, Google Cloud Storage.
| Avantages | Inconvénients |
|---|---|
| Stockage bon marché, monte en charge jusqu’à des volumes massifs | Facile de finir avec un « marécage de données » — désorganisé, non documenté, difficile à fiabiliser |
| « Schéma à la lecture » — charger d’abord, structurer ensuite, tout conserver | Pas de transactions natives ni de garanties de cohérence forte |
| Accepte tout type de fichier : JSON, images, logs, vidéo, exports de l’API DHIS2 | Les analystes ne peuvent généralement pas l’interroger directement sans outillage supplémentaire |
Lakehouse
Combine le stockage bon marché du lac avec les transactions, l’application du schéma et le SQL rapide de l’entrepôt — une seule plateforme pour les deux. Exemples : Databricks, Snowflake (via Iceberg), MotherDuck + DuckLake.
| Avantages | Inconvénients |
|---|---|
| Une seule copie des données sert à la fois la BI et les charges ML/IA — pas de lac + entrepôt séparés à garder synchronisés | Plus de pièces mobiles — format de table, catalogue, moteur de calcul — à comprendre |
| Les formats de table ouverts (Delta Lake, Apache Iceberg) évitent l’enfermement fournisseur | Peut être complexe à gérer pour les équipes qui n’ont besoin que de SQL interactif, pas de ML |
| Prend en charge les transactions ACID au-dessus d’un stockage objet bon marché |
Data mart
Un petit sous-ensemble ciblé d’un entrepôt, construit pour une équipe ou un domaine
métier — par exemple, vos dossiers gold/aggregate et gold/tracker de la démo DHIS2.
| Avantages | Inconvénients |
|---|---|
| Rapide, simple, taillé pour un public précis (p. ex. un « mart du programme paludisme ») | Peut dupliquer la logique entre s’il n’est pas construit soigneusement sur des modèles partagés |
| Plus facile à parcourir pour les utilisateurs non techniques qu’un entrepôt complet | Pas une solution complète en soi — se situe en aval d’un entrepôt ou d’un lakehouse |
Data mesh
Un motif organisationnel (pas une technologie) où chaque équipe de domaine possède et publie ses propres données comme un produit.
| Avantages | Inconvénients |
|---|---|
| Monte bien en charge dans les grandes organisations aux nombreuses équipes/programmes indépendants | Exige une gouvernance et des standards solides pour éviter la fragmentation |
| Les équipes de domaine, au plus près des données, sont responsables de leur qualité | Surdimensionné pour les petites équipes — demande une maturité organisationnelle, pas seulement de l’outillage |
En un coup d’œil
| Architecture | Code / mise en place | Convivialité | Idéal pour |
|---|---|---|---|
| Base opérationnelle (OLTP) | Moyen — généralement déjà gérée par l’IT/les DBA | Élevée pour les requêtes simples, faible pour l’analytique | Faire tourner l’application elle-même, pas le reporting |
| Entrepôt de données | Moyen — centré SQL, compatible dbt | Élevée pour les analystes une fois les données modélisées | Le reporting de routine et la BI sur des données structurées et bien comprises — exactement ce qu’est votre couche Gold |
| Lac de données | Élevé — demande de l’ingénierie pour rester organisé | Faible pour les utilisateurs finaux, plus élevée pour les ingénieurs | Déposer à bas coût les exports bruts (p. ex. les extractions JSON de l’API DHIS2) avant leur modélisation — un lieu naturel pour votre couche Bronze si vous utilisez du stockage objet |
| Lakehouse | Élevé — plus de concepts : catalogues, formats de table, moteurs | Moyenne — puissant mais plus long à apprendre | Les équipes qui ont besoin à la fois de tableaux de bord BI et de ML/IA sur les mêmes données DHIS2 + autres sources, sans dupliquer les pipelines |
| Data mart | Faible — simplement plus de modèles dbt/SQL par-dessus | Très élevée pour le public visé | Remettre à une équipe programme précise (p. ex. vaccination, CPN) exactement les tables de la couche Gold dont elle a besoin, rien de plus |
| Data mesh | Élevé — complexité organisationnelle + technique | Faible à moyenne — dépend entièrement de la maturité de l’équipe | Les grands déploiements DHIS2 multi-pays ou multi-programmes où chaque programme gère ses propres pipelines |
Croiser la convivialité avec l’effort de code et de mise en place rend le compromis visible :
Le lien avec ce cours. L’entrepôt HIC suit le motif entrepôt de données avec des couches Medallion — Bronze reproduit ce qu’offre un lac de données (brut, schéma à la lecture), tandis que Silver et Gold appliquent la structure et la modélisation qui en font un entrepôt. Voir le Lab 3 : Modélisation dbt Medallion.