Techniques de modélisation de data warehouse et mise en œuvre sur la plateforme de lakehouse Databricks

Le lakehouse est un nouveau paradigme de plateforme de données qui combine les meilleures fonctionnalités des data lakes et des data warehouses. Elle est conçue comme une plateforme de données d'entreprise à grande échelle pouvant héberger de nombreux cas d'usage et produits de données. Il peut servir de repository de données d'entreprise unique et unifié pour l'ensemble de vos :

• domaines de données,
• cas d'utilisation du streaming en temps réel,
• magasins de données,
• entrepôts de données hétérogènes,
• des Magasins de fonctionnalités Data Science et des sandboxes Data Science, et
• Sandboxes analytiques départementaux en libre-service.

Étant donné la diversité des cas d'utilisation — différents principes d'organisation des données et techniques de modélisation peuvent s'appliquer à différents projets sur un lakehouse. Techniquement, la Databricks Lakehouse Platform peut prendre en charge de nombreux styles de modélisation des données. Dans cet article, nous cherchons à expliquer la mise en œuvre des principes d'organisation des données Bronze/Silver/Gold du lakehouse et comment les différentes techniques de modélisation des données s'intègrent dans chaque couche.

Qu'est-ce qu'un data vault ?

Un Data Vault est un patron de conception de modélisation de données plus récent utilisé pour construire des entrepôts de données pour l'analytique à l'échelle de l'entreprise, par rapport aux méthodes de Kimball et d'Inmon.

Les Data Vaults organisent les données en trois types différents : les hubs, les links et les satellites. Les hubs représentent les entités métier principales, les Links représentent les relations entre les hubs et les satellites stockent les attributs relatifs aux hubs ou aux Links.

Le Data Vault se concentre sur le développement agile de data warehouse où la scalabilité, l'intégration de données/ETL et la vitesse de développement sont importantes. La plupart des clients disposent d'une zone de destination (landing zone), d'une zone Vault et d'une zone data mart qui correspondent aux paradigmes organisationnels de Databricks des couches Bronze, Silver et Gold. Le style de modélisation Data Vault des tables hub, link et satellite s'intègre généralement bien dans la couche Silver du Lakehouse Databricks.

En savoir plus sur la modélisation Data Vault sur Data Vault Alliance.

Qu'est-ce que la modélisation dimensionnelle ?

La modélisation dimensionnelle est une approche ascendante de conception d'entrepôts de données visant à les optimiser pour l'analytique. Les modèles dimensionnels sont utilisés pour dénormaliser les données métier en dimensions (telles que le temps et le produit) et en faits (tels que les transactions en montants et en quantités). Les différents domaines thématiques sont connectés via des dimensions conformes pour naviguer entre les différentes tables de faits.

La forme la plus courante de modélisation dimensionnelle est le schéma en étoile. Un schéma en étoile est un modèle de données multidimensionnel utilisé pour organiser les données afin qu'elles soient faciles à comprendre et à analyser, et sur lesquelles il est très facile et intuitif d'exécuter des rapports. Les schémas en étoile de type Kimball ou les modèles dimensionnels sont quasiment le Gold standard pour la couche de présentation dans les data warehouse et les datamarts, et même pour les couches sémantiques et de reporting. Par leur conception, les schémas en étoile sont optimisés pour interroger de grands ensembles de données.

Les styles de modélisation de données de type Data Vault normalisé (optimisé pour l'écriture) et de modèles dimensionnels dénormalisés (optimisés pour la lecture) ont tous deux leur place dans le Lakehouse Databricks. Les hubs et les satellites du Data Vault dans la couche Silver sont utilisés pour charger les dimensions dans le schéma en étoile, et les tables de link du Data Vault deviennent les tables directrices clés pour charger les tables de faits dans le modèle dimensionnel. En savoir plus sur la modélisation dimensionnelle auprès du groupe Kimball.

Principes d'organisation des données dans chaque couche du Lakehouse

Un lakehouse moderne est une plateforme de données d'entreprise complète. Elle est hautement évolutive et performante pour toutes sortes de cas d'utilisation différents tels que l'ETL, la BI, la data science et le streaming qui peuvent nécessiter différentes approches de modélisation des données. Voyons comment un lakehouse typique est organisé :

Couche Bronze — la Landing Zone

La couche Bronze accueille toutes les données en provenance des systèmes externes. Les structures des tables de cette couche correspondent aux structures des tables du système source "en l'état", à l'exception des colonnes de métadonnées facultatives qui peuvent être ajoutées pour capturer la date/l'heure de chargement, l'ID de processus, etc. Cette couche est axée sur la capture des données de modification et remplit plusieurs fonctions : archive historique de la source (stockage à froid), data lineage, possibilité d'audit et retraitement sans relecture des données du système source si nécessaire.

Dans la plupart des cas, il est recommandé de conserver les données dans la couche Bronze au format Delta, afin que les lectures ultérieures de la couche Bronze pour l'ETL soient performantes — et afin de permettre les mises à jour dans la couche Bronze pour écrire les changements CDC. Parfois, lorsque les données arrivent aux formats JSON ou XML, nous constatons que les clients les enregistrent dans leur format source d'origine, puis les préparent en les convertissant au format Delta. Ainsi, parfois, nous voyons des clients matérialiser la couche Bronze logique en une zone physique de destination et de transit.

Le stockage de données brutes dans le format de données source d'origine dans une zone de destination aide également à la cohérence lorsque vous ingérez des données via des outils d'ingestion qui ne prennent pas en charge Delta en tant que récepteur natif ou lorsque les systèmes sources transfèrent directement les données vers des magasins d'objets. Ce modèle s'aligne également bien avec le framework d'ingestion Autoloader, dans lequel les sources déposent les données dans la zone de destination pour les fichiers bruts, puis Databricks AutoLoader convertit les données vers la couche de transit au format Delta.

Couche Silver — le Repository central d'entreprise

Dans la couche Silver du lakehouse, les données de la couche Bronze sont identifiées, fusionnées, mises en conformité et nettoyées (selon le principe du « strict nécessaire ») de façon à délivrer une « vue entreprise » de l'ensemble des entités commerciales, concepts et transactions essentiels. Ceci s'apparente à un magasin de données opérationnelles d'entreprise (ODS), un Repository central ou des domaines de données d'un maillage de données (Data Mesh) (par ex. clients, boutiques, transactions sans doublons et tables de référence croisée). Cette vue d'entreprise regroupe les données provenant de différentes sources et permet l'analytique en libre-service pour le reporting ad hoc, l'analytique avancée et le ML. Elle sert de source aux analystes de département, aux data engineers et aux data scientists qui peuvent s'appuyer dessus pour créer des analyses et résoudre des problèmes métier, dans le cadre de projets d'entreprise et de département au niveau de la couche Gold.

Dans le paradigme de la Data Engineering Lakehouse, la méthodologie ELT (Extract-Load-Transform) est généralement suivie, contrairement à la méthode traditionnelle ETL (Extract-Transform-Load). L'approche ELT signifie que seules des transformations et des règles de nettoyage de données minimales ou « juste assez » sont appliquées lors du chargement de la couche Silver. Toutes les règles de "niveau entreprise" sont appliquées dans la couche Silver, par opposition aux règles de transformation spécifiques au projet, qui sont appliquées dans la couche Gold. La vitesse et l'agilité pour ingérer et livrer les données dans le Lakehouse sont ici prioritaires.

Du point de vue de la modélisation des données, la couche Silver a davantage de modèles de données de type 3NF. Des architectures de données et des modèles de données performants en écriture de type Data Vault peuvent être utilisés dans cette couche. Si vous utilisez une méthodologie Data Vault, le Data Vault de données brutes et le Business Vault s'intégreront tous deux dans la couche Silver logique du lac — et les vues de présentation Point-In-Time (PIT) ou les vues matérialisées seront présentées dans la couche Gold.

Couche Or — la couche de présentation

Dans la couche Gold, vous pouvez créer plusieurs data marts et data warehouses selon la méthodologie de modélisation dimensionnelle ou Kimball. Comme nous l'avons vu précédemment, la couche Gold est destinée au reporting et utilise des modèles de données plus dénormalisés et optimisés pour la lecture avec moins de jointures par rapport à la couche Silver. Il arrive parfois que des tables de la couche Gold soient entièrement dénormalisées, généralement si les data scientists veulent alimenter leurs algorithmes pour créer des fonctionnalités.

Les règles ETL et de qualité des données "spécifiques au projet" sont appliquées lors de la transformation des données de la couche Silver à la couche Gold. Les couches de présentation finales, telles que les data warehouse, les magasins de données ou les produits de données comme l'analytique client, l'analytique des produits/de la qualité, l'analytique des stocks, la segmentation de la clientèle, les recommandations de produits, l'analytique du Marketing/des Ventes, etc. sont livrées dans cette couche. Les modèles de données basés sur un schéma en étoile de style Kimball ou les data marts de style Inmon s'intègrent dans cette couche Gold du Lakehouse. Les laboratoires de Data Science et les sandboxes départementaux pour l'analytique en libre-service appartiennent également à la couche Gold.

Le paradigme d'organisation des données Lakehouse

En résumé, les données sont organisées à mesure qu'elles traversent les différentes couches d'un Lakehouse.

• La couche Bronze utilise les modèles de données des systèmes sources. Si les données sont réceptionnées dans des formats bruts, elles sont converties au format Delta Lake au sein de cette couche.
• La couche Silver, pour la première fois, rassemble les données de différentes sources et les met en conformité pour créer une vue d'entreprise des données — en utilisant généralement des modèles de données plus normalisés et optimisés pour l'écriture, qui sont de type 3e forme normale ou Data Vault.
• La couche Gold est la couche de présentation avec des modèles de données plus dénormalisés ou aplatis que la couche Silver, utilisant généralement des modèles dimensionnels de type Kimball ou des schémas en étoile. La couche Gold héberge également des bacs à sable départementaux et de data science pour permettre l'analytique en libre-service et la data science dans toute l'entreprise. La fourniture de ces sandboxes et de leurs propres clusters de compute séparés empêche les équipes métier de créer leurs propres copies de données en dehors du Lakehouse.

Cette approche d'organisation des données en Lakehouse vise à briser les silos de données, à rassembler les équipes et à leur permettre d'effectuer des opérations ETL, du streaming, de la BI et de l'IA sur une seule plateforme avec une gouvernance appropriée. Les équipes de données centrales devraient être les catalyseurs de l'innovation au sein de l'organisation, en accélérant l'intégration de nouveaux utilisateurs en libre-service, ainsi que le développement de nombreux projets de données en parallèle — plutôt que de laisser le processus de modélisation des données devenir le goulot d'étranglement. Le Databricks Unity Catalog fournit des fonctionnalités de recherche et de découverte, de gouvernance et de lignage sur le Lakehouse afin de garantir une bonne cadence de gouvernance des données.

Créez vos Data Vaults et data warehouses en schéma en étoile avec Databricks SQL dès aujourd'hui.

Pour en savoir plus :

• Implémenter un schéma en étoile dans Databricks en cinq étapes simples avec Delta Lake
• Bonnes pratiques pour implémenter un modèle Data Vault dans Databricks Lakehouse
• Bonnes pratiques et mise en œuvre de la modélisation dimensionnelle sur un lakehouse moderne
• Les colonnes d'identité pour générer des clés de substitution sont désormais disponibles dans un Lakehouse !
• Charger un modèle dimensionnel EDW en temps réel avec le Lakehouse Databricks

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