Définition courte
Qu’est-ce qu’un Data Warehouse ?
En business intelligence, un Data Warehouse est une « base de données » qui rassemble des données provenant de nombreuses sources différentes au sein d’une organisation. Il est généralement utilisé à des fins de dashboarding et d’analyse. Les dashboards créés à partir de requêtes complexes sur un data warehouse sont utilisés (le plus souvent) pour prendre des décisions stratégiques orientés business. Le data warehouse est le cœur de la business Intelligence.
On distingue 4 caractéristiques propres au data warehouse :
Orienté sujet : les données y sont organisées par thème (marketing, vente, etc). On parle ainsi de Data Mart.
Intégré : Les données doivent être mises en forme et unifiées afin d’avoir un état cohérent
Non volatile : On ne met pas à jour les données dans un data warehouse (Read-Only)
Historisé : Les données doivent être horodatées, ce qui permet de visualiser les évolutions dans le temps.
Si vous voulez aller plus loin sur le sujet, c’est un peu plus bas que ça se passe 👇 🤓
10 ressources data marketing à forte valeur ajoutée
1. Formation sur Google Analytics 4
2. Formation sur Google Tag Manager
3. Formation sur les paramètres UTM
4. Formation sur le plan de taggage
5. Formation sur Looker Studio
7. Formation sur Google Tag Manager Server-Side
8. Formation sur l’attribution marketing
Pour aller plus loin
Quelles sont les données qui composent un Data Warehouse ?
Les données d’un Data Warehouse sont des données pouvant être stockées dans des tables de données structurées, comme des tables SQL par exemple.
Un Data Warehouse peut vite prendre une taille considérable. Prenez par exemple les données d’un site visité plusieurs milliers de fois par jour, et considérez une table constituée de tous les événements associés à ce site : à chaque fois qu’un bouton est cliqué, qu’une page est vue ou qu’une vidéo est lancée, une ligne supplémentaire est créée dans cette table. On peut vite atteindre plusieurs dizaines voire centaines de milliers de nouvelles lignes ajoutées tous les jours. Et comme les données d’un Data Warehouse sont gardées en mémoire, chaque année les données générées via les événements du site généreront plusieurs dizaines de millions de lignes. Et ce n’est qu’une table parmi des centaines que peuvent constituer un Data Warehouse !
Il est donc nécessaire de structurer son Data Warehouse de sorte à minimiser l’espace de stockage utilisé, car celui-ci peut vous coûter cher. Pour cela, des normes existent, comme la norme 3NF, qui permet d’éviter un maximum les redondances entre tables. Par exemple, on ne va certainement pas mettre le nom et le prénom du client dans des champs d’une table répertoriant les ventes. Il est bien plus pertinent dans une logique de Data Warehouse de mettre dans la table de vente un champ id_client, et d’utiliser une table “clients” qui contiendra le nom et le prénom des clients. Ainsi, si un client achète plusieurs objets, il n’y a plus de redondance des données relatives au client.
Afin de permettre une meilleure maintenabilité des liens entre les tables de données du Data Warehouse, le design de l’architecture de ces liens obéit généralement à une des grandes catégories de format : étoile, constellation ou encore flocon.
Le modèle en étoile, le plus simple, consiste en plusieurs tables de dimensions, comme une table répertoriant les clients, les employés, les données géographiques d’un magasin ou encore les articles d’un magasin, qui se joignent dans une table de métriques, qui répertorie les ventes de tel article vendus par tel employé et acheté par tel client dans tel magasin. Ici, la table de ventes ne contient que des appels à d’autres tables et des métriques relatives à la transaction.
Le modèle en constellation est similaire au domaine en étoile, sauf qu’il contient plusieurs tables de métriques. Si on souhaite à la fois les données de ventes mais aussi les stocks sur nos données, il est possible d’utiliser un modèle en étoiles, mais cela provoquerait une redondance : on devrait dupliquer la table des articles par exemple. Le modèle en constellation consiste à utiliser la même table de correspondances d’articles pour en déduire les stocks et pour en déduire les ventes. On y perd en simplicité d’organisation, mais les gains en espace de stockage peuvent être substantiels.
Enfin, le modèle en flocons permet de s’affranchir d’encore plus de redondances. Si une table de dimensions contient la liste des magasins, avec leur ville, leur région et leur pays, d’après le modèle en étoile et le modèle en constellation, on devrait utiliser cette table “magasins” telle quelle. Dans le modèle en flocon, on lève encore plus les possibilités de redondance, en créant deux tables : une qui effectue la correspondance entre la ville et sa région, et une qui effectue la correspondance entre une région et son pays. Ainsi, si deux magasins se trouvent dans la même région, il n’y a pas besoin d’écrire une nouvelle ligne pour indiquer que la région se trouve dans tel pays. Cette méthode en flocon a donc l’avantage majeur d’optimiser l’espace disponible. Cependant, elle est plus complexe à mettre en place, et peut rendre les requêtes plus longues à créer et exécuter du fait des nombreuses jointures qui peuvent être nécessaires.
Quelle est la différence entre un Data Warehouse, un Data Lake, et un Data Mart ?
La différence principale entre Data Warehouse et Data Marts réside principalement dans l’échelle de données, et l’utilisation qu’on en fait.
Un Data Warehouse contient plusieurs Data Marts, il est donc de taille plus importante qu’un Data Mart. Un Data Mart est une partie du Data Warehouse orienté selon un métier spécifique. Cette logique de compartimentation a plusieurs avantages :
- Elle permet de savoir où sont les données qu’on recherche sans avoir à connaître précisément l’agencement de toutes les tables du Data Warehouse, mais seulement celles relatives à un métier spécifique.
- D’un point de vue sécurité, il est possible de ne donner l’accès qu’à un ou plusieurs Data Marts, en lecture ou en écriture.
L’usage principal des Data Marts est la création de rapports orientés selon un métier spécifique (commercial, financier, opérationnel,…) et une échelle spécifique, allant de la direction générale d’un groupe au manager devant relever ses KPIs hebdomadaires.
De plus, un Data Warehouse doit être optimisé en espace. Les requêtes peuvent donc utiliser plusieurs jointures nécessitant un long temps d’exécution pour être traitées. Le Data Mart étant beaucoup plus léger qu’un Data Warehouse, et l’objectif étant l’exécution de
L’usage principal des Data Marts est la création de rapports orientés selon un métier spécifique (commercial, financier, opérationnel,…) et une échelle spécifique, allant de la direction générale d’un groupe au manager devant relever ses KPIs hebdomadaires. De plus, un Data Warehouse doit être optimisé en espace. Les requêtes peuvent donc utiliser plusieurs jointures nécessitant un long temps d’exécution pour être traitées.
Le Data Mart étant beaucoup plus léger qu’un Data Warehouse, et l’objectif étant l’exécution de nombreuses requêtes en un temps acceptable pour un humain (généralement quelques secondes à quelques minutes pour les requêtes les plus chronophages), on peut créer quelques redondances dans les tables si elles permettent la réalisation plus rapide de requêtes.
Un Data Lake, quant à lui, contient les données brutes, qui seront traitées par la suite pour créer un Data Warehouse structuré. Un Data Lake contient des bases de données, mais peut aussi contenir des éléments peu voire non structurés tels que des tableurs excel, des PDFs, des emails, des messages reçus par un compte professionnel, etc.
Il est possible de transformer un Data Lake en Data Warehouse en traitant les données de façon à les structurer, ou exploiter directement le Data Lake pour des analyses particulières.
Je souhaite créer un Data Warehouse, quelle technologie devrais-je utiliser ?
De nombreuses technologies peuvent être utilisées pour créer un Data Warehouse. La plus basique est de créer sa propre base de données SQL, comme par exemple en utilisant PostreSQL ou encore MariaDB. Ce sont des outils pouvant permettre d’accueillir un Data Warehouse de taille raisonnable, ou plus importante si votre société dispose de ses propres serveurs et d’espaces de stockage importants.
Rappelez-vous : un Data Warehouse peut facilement atteindre le térabyte de données selon le niveau de détail que l’on souhaite, même pour une petite entreprise ! Il faut donc pouvoir requêter de façon massive et stocker d’importants volumes de données.
D’autres solutions, généralement payantes mais permettant de s’affranchir de ces limites, est de porter son Data Warehouse sur des serveurs dans le cloud. De plus, les risques de perte des données liées à des défauts physiques de votre matériel (comme des disques durs corrompus) sont réduits.
Les outils les plus connus pour réaliser les Data Warehouses sont Microsoft Azure et Google Big Query. C’est d’ailleurs ce dernier outil que l’agence data Boryl a choisi d’utiliser pour ses clients.
Définitions similaires
OLTP, OLAP, Données non structurées, Données structurées, Docker, Gouvernance des données, DFS, MySQL, PostgreSQL, Data cleaning, Analyse ad hoc, Data lake, Power BI, Analyse descriptive, Analyse multidimensionnelle, SIAD, ARR, Taux de rétention, Taux d’attrition, Data mining, Pie chart, Histogramme, Dashboard, Graphique, Tableau software, Box plot, Bar chart, Area chart, Data visualisation, KPI, Analyse de cohorte, MRR, API, Data warehouse, Data engineering, CLV, ETL, dbt (Data Build Tool), Data catalog, Marketing Automation, Segmentation RFM
