Accueil › Glossaire › Data Warehouse

Data Warehouse

Un data warehouse (entrepôt de données) est un système de stockage centralisé, optimisé pour les requêtes analytiques SQL, qui consolide les données structurées provenant de multiples sources pour alimenter le reporting, le BI (Business Intelligence) et les analyses à grande échelle.

Le data warehouse est le moteur qui transforme des données brutes en décisions métier. Chaque rapport que votre direction consulte, chaque dashboard Looker ou Tableau, chaque métrique KPI est alimenté par un warehouse. Contrairement à un data lake qui stocke tout en vrac, un warehouse structure les données avant ou pendant le chargement pour garantir des requêtes rapides et des résultats fiables. En 2026, les trois géants du marché sont Snowflake, Google BigQuery et Amazon Redshift.

Principes fondamentaux

OLAP vs OLTP

Les bases de données transactionnelles (OLTP : PostgreSQL, MySQL) sont optimisées pour des lectures et écritures fréquentes sur des lignes individuelles (insérer une commande, mettre à jour un profil). Un data warehouse (OLAP) est optimisé pour les requêtes analytiques qui scannent des millions de lignes et calculent des agrégats (« quel est le chiffre d’affaires par région sur les 12 derniers mois ? »). Les deux systèmes ont des architectures fondamentalement différentes et ne sont pas interchangeables.

Stockage colonné

Les warehouses modernes stockent les données en colonnes plutôt qu’en lignes. Une requête SELECT SUM(revenue) FROM sales WHERE year = 2026 ne lit que les colonnes revenue et year, pas les dizaines d’autres colonnes de la table. Le stockage colonné réduit le volume de données scannées de 90%+ pour les requêtes analytiques typiques, ce qui accélère les requêtes et réduit les coûts (dans les modèles pay-per-query comme BigQuery).

MPP (Massively Parallel Processing)

Les warehouses cloud distribuent les requêtes sur des dizaines ou centaines de nœuds de calcul qui traitent les données en parallèle. Une requête qui scannerait un téraoctet sur une seule machine en 10 minutes peut être résolue en quelques secondes sur un cluster MPP. C’est ce qui permet aux warehouses de traiter des pétaoctets de données avec des temps de réponse interactifs.

Séparation stockage/compute

L’innovation architecturale clé des warehouses cloud modernes. Le stockage (données persistantes) et le compute (puissance de calcul pour les requêtes) sont indépendants et scalent séparément. Vous pouvez stocker 100 To de données et n’allumer que quelques nœuds de calcul pour les requêtes, ou scaler massivement le compute pour un batch de fin de mois sans toucher au stockage. BigQuery et Snowflake ont adopté cette séparation dès leur conception. Redshift l’a ajoutée plus tard avec les nœuds RA3 et le mode Serverless.

Les trois géants : comparatif détaillé

Snowflake : le multi-cloud universel

Snowflake est le seul data warehouse véritablement multi-cloud : il fonctionne sur AWS, Azure et GCP avec une expérience identique. Son architecture repose sur trois couches distinctes : stockage (cloud objet), compute (Virtual Warehouses indépendants) et services cloud (métadonnées, sécurité, optimisation).

Le concept de Virtual Warehouses est la force de Snowflake : chaque équipe (marketing, data science, finance) dispose de son propre cluster de compute, isolé des autres. Un gros job de data science ne ralentit jamais les requêtes BI du marketing. Les Virtual Warehouses se démarrent en secondes et s’arrêtent automatiquement quand ils ne sont pas utilisés (facturation à la seconde).

Snowflake excelle aussi dans le partage de données (Data Sharing/Marketplace) : vous pouvez partager des tables avec des partenaires externes sans copier les données. Le support natif du semi-structuré (JSON, Avro, Parquet) est excellent, et Snowpark (SDK Python/Java/Scala) permet d’exécuter du code directement dans Snowflake pour le ML et le feature engineering.

Le pricing est basé sur les crédits de compute (facturation à la seconde) + le stockage. Le compute peut devenir coûteux pour les workloads lourds si les Virtual Warehouses ne sont pas correctement dimensionnés.

Google BigQuery : le serverless total

BigQuery est la définition du serverless : aucun serveur à provisionner, aucun cluster à dimensionner, aucune maintenance. Vous envoyez une requête SQL, Google gère tout. Le moteur Dremel distribue la requête sur des milliers de slots de calcul en arrière-plan.

Le modèle de pricing par défaut est le pay-per-query : vous payez uniquement pour les données scannées par chaque requête (environ 5 $/To scanné). C’est idéal pour les workloads sporadiques, mais peut devenir cher pour les requêtes fréquentes sur de gros volumes. BigQuery propose aussi un modèle flat-rate (capacité réservée) pour les usages intensifs.

L’intégration avec l’écosystème Google est le point fort : Looker (BI), Vertex AI (ML), Google Analytics, Google Ads, Firebase. Si votre stack est sur GCP, BigQuery est le choix naturel. Le support du streaming (insertion en temps réel) et les fonctions ML intégrées (BigQuery ML) ajoutent de la polyvalence.

La limitation : BigQuery est exclusivement GCP. Si vous envisagez un changement de cloud dans le futur, le lock-in est réel.

Amazon Redshift : le pilier AWS

Redshift est le warehouse historique d’AWS, lancé en 2013. Son architecture a évolué significativement : les nœuds RA3 séparent stockage et compute (données stockées sur S3 en arrière-plan), et Redshift Serverless élimine le besoin de gérer des clusters.

Redshift s’intègre profondément avec l’écosystème AWS : S3 (stockage), Glue (ETL), Lake Formation (gouvernance), Kinesis (streaming), SageMaker (ML), IAM (sécurité). Pour les organisations profondément ancrées dans AWS, Redshift est le choix le plus naturel et le plus intégré.

Le compromis : Redshift est historiquement plus « hands-on » que Snowflake ou BigQuery. Le tuning des distribution keys, sort keys, le vacuum et l’analyze sont des tâches DBA que les autres plateformes automatisent. Redshift Serverless simplifie une partie de cette complexité, mais l’expérience développeur reste un cran en dessous de Snowflake.

Tableau comparatif

Alimenter un data warehouse : le stack ELT moderne

Un warehouse ne crée pas de données. Il les reçoit via des data pipelines. Le stack ELT moderne se compose de trois couches :

Ingestion (E + L) : Fivetran ou Airbyte extraient les données des sources (SaaS, bases de données, APIs) et les chargent brutes dans le warehouse. C’est le « Extract, Load » de l’ELT.

Transformation (T) : dbt transforme les données brutes en modèles SQL versionnés, testés et documentés, directement dans le warehouse. Les transformations exploitent la puissance de calcul du warehouse plutôt qu’un serveur externe.

Orchestration : un orchestrateur (Dagster, Airflow, Prefect) coordonne l’exécution : déclencher l’ingestion, puis la transformation, puis les tests de qualité, et alerter en cas d’échec.

Ce stack est devenu le standard de l’industrie. La fusion Fivetran + dbt Labs (annoncée fin 2025) consolide les deux premiers composants sous une même entité, signalant la maturité de cette architecture.

-- Exemple : requête analytique typique dans un data warehouse
-- Chiffre d'affaires mensuel par catégorie de produit

SELECT
    DATE_TRUNC('month', o.ordered_at) AS month,
    p.category,
    COUNT(DISTINCT o.order_id) AS total_orders,
    SUM(o.order_amount) AS revenue,
    AVG(o.order_amount) AS avg_order_value,
    COUNT(DISTINCT o.customer_id) AS unique_customers
FROM analytics.fct_orders o
JOIN analytics.dim_products p ON o.product_id = p.product_id
WHERE o.ordered_at >= '2025-01-01'
GROUP BY 1, 2
ORDER BY 1 DESC, 4 DESC;

Ce type de requête, qui scanne des millions de lignes et calcule des agrégats multi-dimensions, est exactement ce pour quoi un data warehouse est optimisé. Sur un data lake brut sans format de table, la même requête serait 10 à 100 fois plus lente.

Modélisation des données

Un data warehouse bien conçu organise ses données selon un modèle dimensionnel qui facilite les requêtes analytiques :

Star Schema

Le modèle le plus courant : une table de faits centrale (transactions, événements) entourée de tables de dimensions (clients, produits, dates, géographie). Les requêtes joignent les faits aux dimensions pour calculer des métriques segmentées. C’est le fondement du BI et du reporting.

Architecture Medallion (Bronze/Silver/Gold)

Popularisée par Databricks et adoptée par la plupart des équipes utilisant dbt, cette architecture organise les données en couches de qualité croissante :

Bronze (Raw/Staging) : données brutes telles qu’extraites des sources. Nettoyage minimal, renommage de colonnes, casting de types.

Silver (Intermediate) : données nettoyées, dédupliquées, jointes entre sources. Logique métier réutilisable.

Gold (Marts) : tables finales optimisées pour la consommation. Un mart par domaine métier (finance, marketing, produit). C’est ce que les analystes et les outils BI consomment.

Avec dbt, chaque couche est un ensemble de modèles SQL versionnés dans Git avec des tests automatisés. Le lineage (graphe de dépendances) montre exactement comment chaque table Gold est construite depuis les données Bronze.

Data Warehouse et machine learning

Les warehouses modernes intègrent de plus en plus les workloads ML directement dans le warehouse :

BigQuery ML permet d’entraîner des modèles (régression, classification, clustering, time series) directement en SQL, sans exporter les données. C’est le chemin le plus rapide du prototype ML pour les analystes qui maîtrisent le SQL mais pas Python.

Snowpark (Snowflake) permet d’exécuter du Python, Java ou Scala directement dans Snowflake pour le feature engineering, l’entraînement de modèles et le scoring, sans sortir les données du warehouse.

Redshift ML s’intègre avec SageMaker : vous créez et invoquez des modèles ML depuis des requêtes SQL Redshift, avec l’entraînement délégué à SageMaker en arrière-plan.

Pour les cas plus complexes, le warehouse alimente un feature store (via des feature pipelines) qui sert les features pour l’entraînement et l’inférence en production. L’experiment tracking (MLflow, W&B) enregistre quelle version des données warehouse a produit quel modèle.

Bonnes pratiques

Maîtrisez les coûts

Le compute warehouse est le premier poste de dépense. Dimensionnez vos clusters (Snowflake) ou slots (BigQuery) en fonction de vos workloads réels, pas de vos estimations optimistes. Utilisez l’auto-suspend (Snowflake), les réservations flat-rate (BigQuery) et les Reserved Instances (Redshift) pour les workloads prévisibles. Monitorez le coût par requête et identifiez les requêtes gourmandes qui consomment une part disproportionnée du budget.

Partitionnez et clusterisez

Le partitionnement (par date, par région) permet au warehouse de ne scanner que les partitions pertinentes pour chaque requête. Le clustering (tri physique par colonnes fréquemment filtrées) accélère les scans. Sans partitionnement, chaque requête scanne l’intégralité de la table, ce qui est lent et coûteux.

Implémentez le RBAC dès le départ

Le contrôle d’accès basé sur les rôles (RBAC) définit qui peut lire quelles tables, quelles colonnes. Les données sensibles (PII, données financières) doivent être masquées ou restreintes. Les trois plateformes supportent le RBAC, le masquage dynamique (Dynamic Data Masking) et les politiques de sécurité au niveau des lignes (Row-Level Security). Configurez cela dès la création du warehouse, pas après un incident de conformité.

Monitorez les performances

Utilisez les outils natifs (Query History dans Snowflake, INFORMATION_SCHEMA.JOBS dans BigQuery, STL_QUERY dans Redshift) pour identifier les requêtes lentes, les full table scans et les goulots d’étranglement. Définissez des SLO : « les rapports quotidiens sont disponibles avant 8h », « aucune requête BI ne dépasse 30 secondes ».

Testez la qualité des données

Les données dans le warehouse alimentent les décisions métier et les modèles ML. Un chiffre d’affaires incorrect dans un rapport ou une feature corrompue dans un modèle a des conséquences réelles. Utilisez dbt tests pour valider chaque modèle (unicité, non-nullité, intégrité référentielle) et des outils de data observability (Monte Carlo, Elementary, Soda) pour détecter les anomalies en continu.

Data Warehouse vs Data Lakehouse

En 2026, la frontière entre warehouse et lakehouse se brouille. Snowflake supporte nativement Apache Iceberg (tables ouvertes sur le stockage client). BigQuery propose BigLake (accès unifié lake + warehouse). Databricks SQL offre des performances warehouse sur un lakehouse Delta Lake.

La question « warehouse ou lakehouse ? » dépend de vos workloads :

Principalement SQL/BI avec des données structurées : un data warehouse classique (Snowflake, BigQuery) est plus simple, plus performant et plus facile à opérer.

Mix SQL + ML + streaming + données non structurées : un lakehouse (Databricks, ou Snowflake/BigQuery avec support Iceberg) offre plus de flexibilité sur une seule plateforme.

Beaucoup d’organisations opèrent les deux : un warehouse pour le BI et le reporting, un lake/lakehouse pour le ML et le stockage brut. C’est un choix pragmatique, même si cela implique de la duplication de données entre les deux systèmes.

Verdict

Le data warehouse reste le pilier de l’analytique d’entreprise en 2026. Les trois plateformes cloud (Snowflake, BigQuery, Redshift) ont convergé en fonctionnalités : séparation stockage/compute, support serverless, semi-structuré, ML intégré et support Iceberg. Le choix se fait principalement sur l’écosystème cloud (AWS → Redshift, GCP → BigQuery, multi-cloud → Snowflake), l’expérience développeur souhaitée (BigQuery = zéro maintenance, Snowflake = meilleur équilibre, Redshift = plus de contrôle) et le modèle de pricing (pay-per-query vs crédits vs nœuds).

Pour un nouveau projet, Snowflake est le choix par défaut le plus sûr : multi-cloud, excellente DX, isolation de workloads, et le plus large écosystème de partenaires (dbt, Fivetran, Airbyte, Looker, Tableau). Si vous êtes exclusivement GCP, BigQuery est imbattable en simplicité. Si vous êtes exclusivement AWS avec une stack Glue/SageMaker, Redshift est le plus intégré.

Quel que soit le choix, investissez dans dbt pour les transformations (c’est le standard universel, supporté par les trois plateformes), un outil d’ingestion (Fivetran ou Airbyte), et un orchestrateur (Dagster ou Airflow). Le warehouse sans un stack ELT moderne autour est un réservoir vide.