Types d'entrepôts de données : un guide complet des architectures et des cas d'usage

Un entrepôt de données est un référentiel centralisé qui collecte, organise et stocke les données structurées de l'ensemble d'une organisation afin que les analystes et les data scientists puissent exécuter des requêtes complexes, générer des rapports et prendre en charge les charges de travail de business intelligence (BI). Contrairement aux bases de données opérationnelles conçues pour le traitement des transactions, un entrepôt de données est conçu pour les charges de travail analytiques : joindre des données provenant de plusieurs sources, préserver les données historiques sur plusieurs années et fournir le socle gouverné nécessaire à la prise de décision stratégique.

Il est essentiel de comprendre les différents types d'entrepôts de données avant de s'engager dans une plateforme ou une migration. Chaque type reflète un compromis architectural distinct entre l'échelle, la latence, le coût et le périmètre du sujet. Ce guide présente tous les principaux types d'entrepôts de données, des entrepôts de données d'entreprise (EDW) traditionnels aux architectures lakehouse modernes, et fournit des conseils clairs pour choisir la solution la plus adaptée à vos besoins.

Les trois principaux types d'entrepôts de données

Le secteur distingue trois types fondamentaux d'entrepôts de données qui constituent le socle de l'architecture des données moderne : l'Enterprise Data Warehouse (EDW), le Data Mart et l'Operational Data Store (ODS). Au-delà de ces derniers, les organisations déploient également des entrepôts de données cloud, des entrepôts de données virtuels, des entrepôts de données hybrides et des plateformes lakehouse, en fonction des exigences de charge de travail, du volume de données et de la complexité de la gouvernance.

Chaque type diffère par sa manière de stocker les données, son propriétaire, la latence qu'il prend en charge et les requêtes analytiques qu'il traite le mieux. Le bon choix dépend de vos sources de données, de la structure de votre équipe, de vos exigences en matière de qualité des données et des cas d'usage analytiques que vous devez prendre en charge.

Enterprise Data Warehouse (EDW)

Un enterprise data warehouse (EDW) est le type d'entrepôt de données le plus complet, conçu pour servir de source unique et autoritaire de vérité pour l'ensemble d'une organisation. Un EDW intègre les données de toutes les principales unités opérationnelles (ventes, finance, opérations, ressources humaines, systèmes de gestion de la relation client (CRM) et systèmes de gestion des stocks) dans un entrepôt de données centralisé unique, régi par des normes de qualité des données et des contrôles d'accès cohérents.

Architecture et périmètre

La caractéristique principale d'un entrepôt de données d'entreprise est son périmètre transversal à toute l'organisation. Les données provenant de multiples sources passent par des processus d'extraction, de transformation et de chargement (ETL) avant d'arriver dans l'entrepôt, où les règles métier, le nettoyage des données et la validation garantissent la cohérence entre les équipes. Le résultat est un référentiel gouverné où chaque analyste interroge la même version des données de l'entreprise, quel que soit son service.

Les EDW mettent généralement en œuvre une architecture à trois niveaux. Le niveau inférieur gère les sources de données et les processus ETL qui ingèrent et transforment les données brutes des systèmes opérationnels. Le niveau intermédiaire héberge un serveur OLAP qui rend les données accessibles pour une analyse multidimensionnelle. Le niveau supérieur fournit des outils front-end (tableaux de bord et applications de BI) grâce auxquels les utilisateurs métier analysent les données. Cette conception en couches sépare la complexité de l'ingestion des performances analytiques, permettant d'optimiser chaque niveau indépendamment.

Quand choisir un EDW

Un EDW est le socle idéal lorsque votre organisation a besoin d'analyses à l'échelle de l'entreprise, de rapports de conformité réglementaire ou d'une source unique de vérité pour l'ensemble des unités opérationnelles qui fonctionnent actuellement en silos de données. Les organisations ayant des exigences complexes en matière de gouvernance des données (comme les entreprises de services financiers gérant les rapports réglementaires, les établissements de santé gérant les données des patients ou les grands fabricants intégrant les données de la chaîne d'approvisionnement et de production) bénéficient le plus de la gouvernance centralisée offerte par un EDW.

Le principal défi des entrepôts de données traditionnels est l'évolutivité. À mesure que le volume de données augmente, les formats de table propriétaires et les configurations matérielles fixes rendent la mise à l'échelle des déploiements EDW sur site coûteuse. De nombreuses organisations confrontées à cette contrainte migrent vers des architectures cloud ou lakehouse qui conservent le modèle de gouvernance d'un EDW tout en éliminant les limites d'infrastructure.

Data Marts

Un data mart est un sous-ensemble d'un entrepôt de données spécifique à un sujet, limité à un seul service, une fonction métier ou un domaine analytique. Là où un EDW sert l'ensemble de l'organisation, un data mart s'adresse à un public ciblé : l'équipe marketing, le service financier ou une activité commerciale régionale. Les data marts stockent les données dans des formats optimisés pour les requêtes et rapports spécifiques exécutés par une équipe particulière, en utilisant généralement des modèles de schéma en étoile ou en flocon dénormalisés qui minimisent la complexité des jointures.

Data marts dépendants et indépendants

Les data marts se divisent en deux modèles architecturaux. Un data mart dépendant extrait les données d'un EDW existant, héritant ainsi des normes de gouvernance et de qualité des données du référentiel central. C'est l'approche recommandée lorsqu'un EDW existe déjà, car elle évite les définitions de métriques contradictoires entre les services.

Un data mart indépendant ingère les données directement depuis les systèmes sources sans passer par un EDW. Les data marts indépendants sont plus rapides à créer mais présentent un risque : chaque magasin peut appliquer des règles métier différentes, ce qui entraîne des rapports incohérents entre les unités opérationnelles, soit précisément le type de silos de données que l'architecture d'entrepôt de données est censée éliminer.

Quand créer un data mart

Créez un data mart lorsqu'une équipe spécifique a des besoins analytiques qui ne justifient pas d'attendre la mise en œuvre complète d'un EDW, lorsque les performances des requêtes sur un sous-ensemble de données nécessitent une optimisation indépendante, ou lorsque la propriété des données par le service est une exigence de gouvernance. Les data marts fonctionnent particulièrement bien pour l'analyse des données de vente, l'attribution marketing et les rapports financiers, des cas d'usage où le domaine de données est bien défini et le public ciblé.

Operational Data Store (ODS)

Un Operational Data Store (ODS) est un type d'entrepôt de données conçu pour les rapports en temps quasi réel et la prise de décision opérationnelle, positionné entre les bases de données transactionnelles et l'EDW analytique. Alors qu'un EDW stocke des données historiques accumulées sur plusieurs années, un ODS contient des données opérationnelles actuelles et récentes (généralement actualisées à des intervalles allant de quelques minutes à quelques heures) optimisées pour des requêtes qui reflètent l'état actuel de l'entreprise plutôt que des tendances à long terme.

Le rôle de l'ODS dans l'architecture des données

Les systèmes opérationnels tels que les plateformes CRM, les systèmes de gestion des stocks et les plateformes de traitement des commandes génèrent des données transactionnelles en continu, mais ne sont pas conçus pour les requêtes analytiques. L'exécution de rapports complexes sur une base de données transactionnelle de production ralentit les opérations qu'elle prend en charge. L'ODS résout ce problème en répliquant les données opérationnelles dans un environnement distinct où les analystes peuvent les interroger sans impact sur les systèmes sources.

Un ODS intègre les données de multiples sources opérationnelles, applique une légère transformation pour standardiser les formats et met les données opérationnelles intégrées à disposition pour les rapports. Il ne remplace pas l'EDW : l'analyse des tendances historiques et les requêtes de planification stratégique relèvent toujours de l'entrepôt. L'ODS traite les questions opérationnelles urgentes : niveaux de stock actifs, performances de vente du jour même, tickets d'assistance client actifs.

Entrepôt de données virtuel

Un entrepôt de données virtuel (parfois appelé entrepôt de données fédéré) ne consolide pas physiquement les données dans un emplacement de stockage unique. Au lieu de cela, il crée une couche d'abstraction logique qui interroge les données sur place à travers plusieurs systèmes sources, présentant ces systèmes disparates comme un environnement analytique unifié.

Les entrepôts virtuels s'appuient sur la technologie de fédération de requêtes pour envoyer les requêtes vers les systèmes sources et agréger les résultats au niveau de la couche de présentation. Cette approche élimine les coûts d'infrastructure de stockage et d'ETL liés à la consolidation physique et permet d'accélérer le délai de valorisation lors de l'analyse de données qui existent déjà dans des bases de données opérationnelles, sans avoir à les déplacer. La principale limite réside dans les performances des requêtes : les requêtes complexes qui nécessitent de joindre de grands ensembles de données sur plusieurs systèmes introduisent une latence importante, car chaque requête doit récupérer des données à partir de systèmes qui ne sont pas conçus pour les charges de travail analytiques.

Les entrepôts de données virtuels conviennent particulièrement bien aux analyses exploratoires, aux rapports à petite échelle ou aux situations où des contraintes réglementaires empêchent le déplacement des données. Ils constituent rarement l'architecture idéale pour les requêtes analytiques à volume élevé ou les charges de travail d'IA qui nécessitent un traitement de données à grande échelle.

Entrepôts de données cloud

Les entrepôts de données cloud sont hébergés sur des plateformes cloud (AWS, Microsoft Azure, Google Cloud, etc.) et fournissent des fonctionnalités d'entrepôt de données sous forme de services entièrement gérés. Les organisations qui exploitent des entrepôts de données cloud n'ont pas à provisionner ni à entretenir de matériel physique ; le fournisseur cloud gère l'infrastructure tandis que l'organisation se concentre sur l'ingestion, la modélisation et l'analyse des données.

Avantages du déploiement dans le cloud

Le plus grand avantage des entrepôts de données cloud est leur évolutivité élastique. Les entrepôts de données sur site traditionnels obligent les organisations à dimensionner le matériel pour la charge de pointe, ce qui entraîne un surprovisionnement pendant les opérations normales. Les entrepôts cloud adaptent automatiquement les ressources de calcul et de stockage en fonction de la demande selon un modèle de paiement à l'usage, de sorte que les organisations ne paient que ce qu'elles consomment. Le déploiement dans le cloud accélère également le délai de valorisation : alors que les déploiements sur site peuvent prendre des mois, de l'approvisionnement à la mise en production, un entrepôt de données cloud peut être provisionné et charger des données en quelques heures.

Frais de sortie et préparation à la migration

Les data warehouses basés sur le cloud imposent des compromis que les organisations doivent évaluer. Les frais de sortie de données — les coûts liés au transfert de données hors du réseau d'un fournisseur cloud — peuvent devenir importants à grande échelle. Les organisations qui travaillent avec plusieurs fournisseurs cloud font face à une complexité accrue pour gérer l'intégration des données, les politiques de sécurité et les cadres de gouvernance sur différentes plateformes.

Avant de migrer vers un data warehouse cloud, évaluez le volume de données qui sortira de la plateforme, étudiez les formats de données ouverts qui limitent la dépendance vis-à-vis d'un fournisseur unique, et vérifiez que les fonctionnalités de gouvernance et de sécurité de la plateforme cible répondent à vos exigences de conformité.

Data warehouses hybrides et modernes

Un data warehouse hybride associe des capacités de stockage de données sur site et dans le cloud, permettant aux organisations de conserver les données sensibles ou réglementées dans leurs propres centres de données tout en profitant de l'évolutivité du cloud pour les traitements analytiques dont la demande varie.

Caractéristiques d'un data warehouse moderne

Un data warehouse moderne va beaucoup plus loin que le modèle traditionnel. Il prend en charge non seulement les données structurées dans des schémas prédéfinis, mais aussi les données semi-structurées et non structurées. Il sépare le calcul du stockage, ce qui permet de faire évoluer chacun d'eux indépendamment et de réduire le coût du traitement des données à grande échelle. Il s'intègre aux pipelines de données en streaming pour réduire la latence, prend en charge les formats de données ouverts pour éviter la dépendance vis-à-vis d'un fournisseur, et propose des passerelles natives pour les charges de travail de machine learning et d'AI, en plus de la BI et des rapports traditionnels.

Les data warehouses modernes intègrent également des fonctionnalités robustes de lignage des données, qui permettent de suivre les données depuis leurs systèmes sources à travers chaque étape de transformation jusqu'à leur point de consommation final. Ce lignage est essentiel pour la gouvernance et l'assurance qualité des données — lorsqu'un analyste remet en question un chiffre dans un rapport, la documentation du lignage permet à l'équipe des données de retracer précisément comment ce chiffre a été calculé.

Architecture Data Lake et Lakehouse

Un data lake stocke les données brutes dans leur format d'origine sans schéma prédéfini, acceptant des données structurées, semi-structured et non structurées de n'importe quelle source. Contrairement à un data warehouse, qui nécessite que les données passent par des processus ETL et se conforment à un schéma défini avant de pouvoir être stockées et interrogées, un data lake applique le schéma à la lecture — le schéma est appliqué au moment de la requête, et non lors de l'intégration. Cette flexibilité rend les data lakes particulièrement adaptés au stockage de grands volumes de données brutes pour le machine learning et l'exploration en science des données.

Le compromis réside dans la fiabilité. Sans le contrôle de la qualité des données fourni par les processus ETL, les data lakes peuvent accumuler des données incohérentes, dupliquées ou mal documentées, auxquelles les analystes ne peuvent pas faire confiance pour des rapports de BI gouvernés.

Le Lakehouse comme solution unifiée

Un data lakehouse associe la flexibilité et l'efficacité économique d'un data lake aux capacités de gestion des données d'un data warehouse. Un lakehouse stocke les données dans des formats ouverts sur un stockage objet cloud, puis ajoute une couche de métadonnées transactionnelles et de gouvernance qui applique les transactions ACID, l'évolution des schémas, les contraintes de qualité des données et le voyage dans le temps — la possibilité d'interroger les données telles qu'elles existaient à n'importe quel moment de l'histoire.

Le résultat est une plateforme unique où les ingénieurs de données exécutent des pipelines ETL, les analystes de données lancent des requêtes SQL sur des tables gouvernées, et les data scientists accèdent à des données brutes et préparées pour l'entraînement des modèles — le tout sans déplacer de données entre les systèmes. L'architecture médaillon, courante dans les déploiements de lakehouse, organise les données en couches bronze (brutes), silver (validées et intégrées) et gold (enrichies et prêtes à la consommation), améliorant progressivement la qualité des données à chaque étape. La couche gold correspond directement aux data marts et aux couches de service EDW déjà exploités par les data warehouses traditionnels, ce qui rend la transition familière sur le plan de l'architecture.

Architecture et stockage du data warehouse

Quel que soit le modèle de déploiement, l'architecture d'un data warehouse repose sur le même principe fondamental : les données doivent être séparées des applications qui les génèrent, nettoyées et intégrées via un processus gouverné, et stockées dans des formats optimisés pour les requêtes analytiques plutôt que pour les écritures transactionnelles.

Stockage et conception de schémas

Les data warehouses modernes séparent le calcul du stockage, ce qui permet à chaque dimension d'évoluer indépendamment. Les systèmes de stockage conservent les données dans des formats colonnaires qui minimisent le volume de données analysées lors des requêtes analytiques — une requête ne ciblant que trois colonnes sur cinquante ne lira que l'équivalent de ces trois colonnes, plutôt que de parcourir chaque ligne dans sa totalité.

La conception du schéma influence considérablement les performances des requêtes. Le schéma en étoile organise les données autour d'une table de faits centrale — contenant des événements mesurables comme des transactions de vente ou des sessions web — entourée de tables de dimensions décrivant les entités concernées (clients, produits, périodes). Les jointures dans un schéma en étoile sont simples et rapides. Le schéma en flocon de neige normalise davantage les tables de dimensions, ce qui réduit la redondance de stockage au prix d'une complexité de jointure supplémentaire. Un schéma en galaxie partage des tables de dimensions entre plusieurs tables de faits, prenant en charge des requêtes analytiques qui couvrent différents processus métier.

Les schémas en étoile sont le choix le plus courant pour les data marts et la couche gold d'un lakehouse car ils privilégient les performances de lecture. Le bon schéma dépend du volume de données, des modèles de mise à jour et de la complexité des requêtes analytiques que le schéma doit prendre en charge.

Types de données dans un data warehouse

Historiquement, les data warehouses stockent des données structurées — des lignes et des colonnes avec des types de données et des schémas prédéfinis, provenant de bases de données relationnelles, de plateformes CRM, de systèmes financiers et de systèmes de gestion des stocks. Les données structurées sont faciles à interroger avec du SQL standard et s'intègrent parfaitement dans les pipelines ETL.

Données structurées, semi-structurées et non structurées

Les données semi-structurées ne se conforment pas à un schéma relationnel rigide mais contiennent des marqueurs organisationnels qui les rendent analysables — les documents JSON, les fichiers XML, les enregistrements de journaux et les données de parcours d'achat entrent tous dans cette catégorie. De nombreuses plateformes de data warehouse modernes prennent en charge des types de données semi-structurées natifs, permettant aux requêtes SQL de naviguer dans des structures imbriquées sans avoir à aplatir les données au préalable.

Les données non structurées — images, vidéos, documents textuels libres, enregistrements audio — ne peuvent pas être interrogées directement avec SQL, mais elles sont de plus en plus importantes à mesure que les organisations développent des capacités d'AI et de machine learning. Les architectures de lakehouse estompent cette frontière, permettant de stocker et de gérer les données non structurées aux côtés des données structurées au sein de la même plateforme.

Le choix entre le schéma à l'écriture (qui impose une structure lors de l'intégration, comme le font les data warehouses traditionnels) et le schéma à la lecture (qui diffère la structuration jusqu'au moment de la requête, comme le font les data lakes) reflète un compromis fondamental entre la cohérence de la qualité des données et la flexibilité de l'intégration. La plupart des plateformes de données matures utilisent le schéma à l'écriture pour les tables analytiques gouvernées et le schéma à la lecture pour les zones de données exploratoires et brutes.

Sources de données externes et intégration

Les data warehouses s'alimentent rarement à partir d'une seule source. Les déploiements d'entreprise types intègrent des données provenant de bases de données opérationnelles, de systèmes CRM, de plateformes ERP, d'outils d'automatisation du marketing, de registres financiers, de fournisseurs de données tiers et d'API externes. Gérer la diversité de ces sources de données externes — chacune ayant son propre schéma, sa fréquence de mise à jour et ses caractéristiques de qualité de données — est l'un des défis majeurs de l'architecture des data warehouses.

Avant que les données externes n'entrent dans le data warehouse, elles doivent être validées par rapport aux schémas et aux règles de qualité attendus. La validation permet de détecter rapidement les problèmes courants : champs obligatoires manquants, valeurs hors des limites prévues et violations d'intégrité référentielle. Détecter ces problèmes lors de l'intégration est bien moins coûteux que de les découvrir une fois que les données se sont propagées dans les rapports et les tableaux de bord. L'enrichissement des données — qui consiste à compléter les données intégrées avec le contexte de tables de référence ou de jeux de données externes — transforme les données sources brutes en jeux de données prêts à l'emploi pour les analystes.

ETL vs ELT et surveillance des pipelines

Le processus d'intégration des données détermine la manière dont les données passent des systèmes sources vers le data warehouse et comment elles sont transformées. L'ETL (Extract, Transform, Load) est l'approche traditionnelle : les données sont extraites des sources, transformées dans un environnement de traitement distinct, puis chargées sous leur forme structurée finale. L'ELT (Extract, Load, Transform) inverse cet ordre — les données brutes sont d'abord chargées, puis transformées au sein du data warehouse en utilisant sa propre puissance de calcul. Les data warehouses cloud modernes privilégient souvent l'ELT car l'étape de transformation peut tirer parti des capacités de traitement parallèle du data warehouse à un coût global inférieur. Pour en savoir plus sur les implications architecturales, le comparatif ELT vs ETL présente les principaux compromis.

La surveillance des pipelines de données garantit que les tâches d'intégration se terminent à temps, que les volumes de données correspondent aux attentes et que les contrôles de qualité sont validés avant que les données ne soient passées en production. Les pipelines qui échouent silencieusement — qui se terminent sans erreur mais produisent des résultats incorrects — figurent parmi les modes de défaillance les plus dangereux dans l'exploitation d'un data warehouse.

Sécurité et gouvernance des données

La gouvernance et la sécurité des données sont des exigences fondamentales pour tout data warehouse, en particulier pour les organisations qui gèrent des données sensibles soumises à des réglementations de conformité. Un data warehouse qui ne peut pas prouver qui a accédé à quelles données, quand et dans quel but ne peut pas satisfaire les auditeurs ni conserver la confiance des clients dont il détient les données.

Contrôle d'accès, chiffrement et journaux d'audit

Une sécurité des données efficace commence par le contrôle d'accès basé sur les rôles (RBAC), qui attribue des autorisations d'accès aux données à des rôles plutôt qu'à des individus, rendant la gestion des accès évolutive pour les grandes organisations. Les contrôles d'accès doivent s'appliquer à plusieurs niveaux : le niveau du catalogue, le niveau de la table, le niveau de la colonne (essentiel pour masquer les informations personnelles identifiables) et le niveau de la ligne (en fonction de l'affiliation organisationnelle ou de la propriété des données).

Les données doivent être chiffrées au repos et en transit. Le chiffrement au repos protège contre l'accès non autorisé aux supports de stockage ; le chiffrement en transit protège contre l'interception sur les réseaux. La journalisation d'audit enregistre chaque événement d'accès et de modification — qui a interrogé une table, quand et quelles données ont été renvoyées — facilitant ainsi les enquêtes de sécurité et la démonstration de la conformité réglementaire. Le suivi du lignage des données, qui retrace les données depuis leur source à travers chaque transformation jusqu'à leur point de consommation, soutient à la fois la gouvernance et l'assurance qualité des données.

Cas d'usage de l'analyse de données par type d'entrepôt

Différents types d'entrepôts de données correspondent à différentes charges de travail analytiques, et comprendre cette correspondance aide les organisations à éviter de déployer une architecture optimisée pour un seul type de charge de travail en espérant qu'elle soit performante pour tous les cas d'usage.

Faire correspondre l'architecture à la charge de travail

Les entrepôts de données d'entreprise prennent en charge l'analyse stratégique — analyse des tendances d'une année sur l'autre, rapports transversaux, tableaux de bord de direction et rapports de conformité nécessitant la jointure de données entre plusieurs domaines d'activité. Les data marts prennent en charge l'analyse départementale — performance des ventes, attribution marketing, rapports de clôture financière et segmentation de la clientèle — où le périmètre restreint des données accélère le libre-service. Les magasins de données opérationnelles prennent en charge l'analyse opérationnelle — surveillance des conditions commerciales actuelles et réponse aux événements en temps réel dans les secteurs de la vente au détail, de la logistique et des services financiers.

Les architectures cloud et lakehouse prennent en charge l'analyse avancée et l'AI — entraînement de modèles de machine learning à grande échelle, pipelines de traitement du langage naturel et systèmes de recommandation. Ces charges de travail nécessitent non seulement des données structurées gouvernées, mais aussi les données brutes et semi-structurées que seule une architecture de stockage plus flexible peut accueillir.

BI, rapports et analyse avancée

Les outils de BI se connectent aux entrepôts de données pour créer des tableaux de bord et des rapports accessibles aux utilisateurs métier qui n'écrivent pas de SQL. L'intégration du machine learning exige que les data scientists accèdent à la fois à des données propres et gouvernées pour l'ingénierie des caractéristiques et à des données historiques brutes pour l'entraînement des modèles. Les architectures lakehouse prennent en charge ces deux cas d'usage au sein d'une plateforme unique, éliminant ainsi la surcharge d'ingénierie des données liée à la maintenance de copies de données distinctes pour les charges de travail de BI et de ML.

Choisir et migrer vers une solution d'entrepôt de données

Sélectionner la bonne solution d'entrepôt de données implique d'évaluer les options gérées par le fournisseur par rapport aux options auto-hébergées, de comprendre les structures de coûts et de valider qu'une plateforme peut prendre en charge vos charges de travail analytiques spécifiques à l'échelle. Les services gérés par le fournisseur prennent en charge la gestion de l'infrastructure, la mise à l'échelle, l'application des correctifs et la haute disponibilité, au détriment d'une partie du contrôle opérationnel. Les options auto-hébergées offrent aux organisations plus de flexibilité pour répondre à des exigences strictes de résidence des données ou à des politiques de sécurité complexes, mais nécessitent que les équipes gèrent les clusters, coordonnent les mises à niveau et s'occupent de la planification de la capacité.

Évaluer les facteurs liés aux fournisseurs et aux coûts

Les coûts des entrepôts de données se divisent en trois catégories : les coûts de stockage, les coûts de calcul et les coûts de mouvement des données. Les entrepôts de données cloud modernes facturent le stockage et le calcul séparément, permettant à chacun d'évoluer indépendamment. Avant de vous engager sur une plateforme pour des charges de travail de production critiques, réalisez une preuve de concept avec vos données et modèles de requêtes réels — les benchmarks synthétiques reflètent rarement les performances réelles avec les volumes de données que vous traitez.

Migration progressive et optimisation des coûts

La migration d'un entrepôt de données hérité vers une plateforme moderne bénéficie d'une approche progressive organisée par domaine d'activité. Commencez par un domaine qui présente des exigences de données bien définies et un responsable métier motivé. Validez la migration par rapport aux références de production avant de passer au domaine suivant.

La séparation du calcul et du stockage est l'un des leviers d'optimisation des coûts les plus importants dans les entrepôts de données modernes. Dans les architectures traditionnelles, le calcul et le stockage évoluent ensemble. Les architectures cloud modernes découplent ces dimensions, permettant aux organisations d'ajouter du stockage sans provisionner de ressources de calcul supplémentaires, et d'augmenter la puissance de calcul pour les périodes de pointe de requêtes sans augmenter de manière permanente les coûts de stockage. L'autoscaling évite à la fois le sous-provisionnement pendant les périodes de pointe et le sur-provisionnement pendant les périodes d'inactivité.

Comparaison des types d'entrepôts de données

Foire aux questions

Quels sont les principaux types d'entrepôts de données ?

Les trois principaux types d'entrepôts de données sont l'Enterprise Data Warehouse (EDW), le Data Mart et l'Operational Data Store (ODS). Au-delà de ces types fondamentaux, les organisations déploient également des entrepôts de données basés sur le cloud, des entrepôts de données virtuels, des entrepôts de données hybrides combinant stockage sur site et dans le cloud, ainsi que des architectures lakehouse qui unifient la gouvernance de l'entrepôt avec la flexibilité du lac de données. Chaque type répond à des cas d'usage distincts basés sur la portée des données, les exigences de latence et les charges de travail analytiques.

Quelle est la différence entre un entrepôt de données et un lac de données ?

Un entrepôt de données stocke des données structurées dans des schémas prédéfinis et applique la qualité des données via des processus ETL avant le chargement des données. Un lac de données stocke les données brutes dans leur format d'origine — structurées, semi-structurées ou non structurées — sans nécessiter de schéma prédéfini lors de l'ingestion. Les entrepôts de données sont optimisés pour les requêtes SQL analytiques complexes et les rapports de BI ; les lacs de données sont optimisés pour la flexibilité et les charges de travail de science des données et de machine learning à grande échelle. Un lakehouse combine les deux : il stocke les données dans des formats ouverts avec la flexibilité d'un lac de données, puis ajoute une couche de gouvernance et de transaction avec la fiabilité d'un entrepôt de données.

Quand une organisation doit-elle utiliser un data mart plutôt qu'un EDW ?

Un data mart est le bon choix lorsqu'un département spécifique a besoin de capacités analytiques plus rapidement que ne le permet une implémentation complète d'un EDW, lorsque les performances des requêtes sur un domaine de données restreint nécessitent une optimisation indépendante, ou lorsque la propriété des données par le département est une exigence de gouvernance. Les data marts sont plus efficaces en tant que magasins dépendants construits au-dessus d'un EDW existant, s'alimentant à partir du référentiel central plutôt que d'ingérer directement depuis les systèmes sources. Construire des data marts indépendants sans EDW central risque de créer des définitions de métriques incohérentes et des silos de données entre les équipes.

Qu'est-ce qu'un Operational Data Store et en quoi diffère-t-il d'un entrepôt de données ?

Un Operational Data Store (ODS) contient des données opérationnelles actuelles et quasi-actuelles, rafraîchies à des intervalles allant de quelques minutes à plusieurs heures, conçu pour les rapports opérationnels et la prise de décision. Un entrepôt de données accumule des données historiques sur plusieurs années et est optimisé pour l'analyse des tendances, les rapports stratégiques et les requêtes multidimensionnelles complexes. L'ODS comble l'écart de latence entre les systèmes transactionnels opérationnels et l'entrepôt, qui peut n'être rafraîchi que quotidiennement. Les deux systèmes sont souvent déployés ensemble : l'ODS offre une visibilité opérationnelle le jour même, tandis que l'entrepôt prend en charge l'analyse stratégique à long terme.

En quoi les entrepôts de données cloud diffèrent-ils des entrepôts de données sur site ?

Les entrepôts de données cloud sont hébergés sur des plateformes cloud et offrent une évolutivité élastique, une tarification à l'usage et une réduction des coûts de gestion des infrastructures par rapport aux déploiements sur site. Les entrepôts de données traditionnels sur site doivent être dimensionnés pour la capacité de pointe, ce qui entraîne souvent un sur-provisionnement important pendant les opérations normales. Les entrepôts cloud évoluent automatiquement et peuvent être provisionnés en quelques heures. Les compromis incluent les coûts de sortie des données pour les volumes élevés, la dépendance vis-à-vis de la disponibilité d'un fournisseur cloud et la complexité de la gouvernance pour les organisations opérant sur plusieurs plateformes cloud.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original