Revenir au contenu principal

Modèles de données métier lakehouse pour l'énergie et les ressources

Pour chaque secteur, une bibliothèque de modèles de données métier Silver utilisables en production, à déployer dans Unity Catalog comme fondation analytique du lakehouse Databricks : une collection complète, gouvernée et cohérente dès le premier jour.

Lakehouse medallion layers with the Silver business data model

Modèles de données métier pour le lakehouse Databricks

Localisation

Les modèles de données métier Lakehouse constituent la couche Silver. La couche Bronze gère l'ingestion brute (Lakeflow, Auto Loader). La couche Silver correspond au modèle analytique conformé et normalisé dans lequel puisent chaque analyste, chaque outil de BI et chaque workload ML. La couche Gold est dérivée des insights (tables de KPI, tables de caractéristiques, agrégats) calculés à partir de la couche Silver.

Modèles de données métier pour le lakehouse Databricks – Localisation

Contenu de chaque modèle

Chaque modèle est publié sous la forme d'un paquet complet.

« model.json » est le modèle logique qui capture l'ensemble des domaines, sous-domaines, produits, attributs, clés étrangères, étiquettes de classification et définitions de vue de métrique. C'est l'unité de référence. Vous pouvez l'enregistrer dans Git, comparer les différentes versions et le partager entre plusieurs environnements.

Le déploiement Unity Catalog réunit des schémas, des tables Delta, des contraintes de clé primaire, des contraintes de clé étrangère (informationnelles) et des tags de classification. Les noms exacts du catalogue et du schéma dépendent du style de catalogage choisi au moment de l'installation.

Les vues de métriques sont les définitions de KPI réutilisables qui se superposent aux tables physiques et sont exploitables par les tableaux de bord AI/BI et AI/BI Genie.

Un graphe de connaissances RDFS (ontology/) représente le modèle sous la forme d'un graphe sémantique pour l'intégration d'outils sémantiques et l'ancrage d'agents IA.

Un diagramme DBML (diagram/) permet d'explorer visuellement le modèle dans dbdiagram.io ou tout autre visualiseur compatible avec DBML.

Le DDL SQL (schemas/) est fourni pour l'ensemble du déploiement, organisé par schéma.

La documentation Excel et Markdown a été générée en même temps que le modèle.

Des données d'échantillon synthétiques facultatives sont également fournies. Les lignes basées sur des pools respectent l'ensemble des clés étrangères, des contraintes regex et des tags de classification.

Hiérarchie

Hiérarchie organisationnelle

Chaque modèle suit la même hiérarchie. L'organisation désigne l'ensemble de l'entreprise. Elle contient trois divisions : Operations (ce que l'entreprise fait physiquement), Business (qui elle sert et comment elle génère des revenus) et Corporate (le back-office de soutien). Chaque division contient un ou plusieurs domaines (contextes délimités uniques, désignés par un seul mot en minuscules). Chaque domaine contient deux ou plusieurs sous-domaines (groupements sémantiques de deux mots). Chaque sous-domaine contient des produits (les tables Delta). Chaque produit contient des attributs (colonnes), et des types de données et des tags de classification lui sont affectés dès le départ.

Les divisions Operations et Business représentent ensemble au moins 80 % des domaines ; la division Corporate est plafonnée à 20 %. Cette répartition veille à ce que chaque modèle soit centré sur le véritable cœur d'activité de l'entreprise, plutôt que sur son administration.

Chaque modèle est également un graphe orienté acyclique de par sa construction. Les clés étrangères pointent toujours de l'enfant vers le parent (order.customer_id, mais jamais customer.latest_order_id) ; les cycles sont interrompus avant publication ; chaque domaine se connecte à au moins un autre via des clés étrangères, pour que l'analytique inter-domaines soit toujours possible.

Deux périmètres : MVM et ECM

Deux périmètres : MVM et ECM

MVM (modèle viable minimum) représente de 30 à 50 % du nombre de tables ECM et ne couvre que les fonctions métier essentielles. Il est dimensionné pour les déploiements en PME, les projets pilotes et les environnements de développement/test.

ECM (modèle à couverture étendue) assure une couverture complète pour l'entreprise et prend en charge les domaines Corporate ; ses dimensions sont adaptées aux déploiements de type Fortune 100. La profondeur des attributs est identique dans les deux périmètres. Le MVM n'est pas un squelette de l'ECM ; il présente simplement une surface réduite.

Comparons plus en détail le MVM et l'ECM.

Tableau comparatif

Pour le secteur Énergie et ressources

Pour commencer, nous proposons actuellement 4 modèles dans les deux versions, MVM et ECM. Ces modèles sont les suivants :

Exploration minière : un exemple

Le dépôt du secteur minier vous permet de comparer les types MVM et ECM pour bien choisir le périmètre correspondant à vos besoins.

Comparaison des métriques des modèles

Inclut un examen détaillé des Domaines et Produits disponibles.

Communauté

Vous pouvez obtenir des informations sur ce que couvre le périmètre sélectionné. Vous trouverez des instructions, des exemples, de la documentation et des notes de version.

Structure du dossier de sortie

Si vous êtes prêt à déployer le modèle dans votre environnement, consultez le fichier readme du dépôt principal pour connaître les étapes à suivre. De manière générale, il vous suffit d'exécuter le notebook d'installation en ciblant le secteur et le périmètre qui vous intéressent.

Démarrer

La bibliothèque se trouve dans le dépôt Industry Solutions : https://github.com/databricks-industry-solutions/lakehouse-industry-data-models/tree/main. Choisissez un modèle, un périmètre (MVM ou ECM), un style de catalogage, un catalogue de déploiement, et exécutez le notebook d'installation. Une installation MVM typique s'effectue en quelques dizaines de minutes, par rapport à Databricks Serverless, qui prend moins de deux heures. Les deux produisent une couche Silver entièrement déployée dans Unity Catalog avec des vues de métriques prêtes pour les tableaux de bord d'AI/BI et AI/BI Genie.

Chaque modèle est un point de départ. Les clients qui ont besoin d'adapter un modèle à leur organisation (en renommant des domaines, en fusionnant ou en scindant des produits, en ajoutant un domaine manquant ou en modifiant les conventions de nommage) peuvent le faire à l'aide de l'agent de modélisation, qui produit des itérations du modèle sur la base de directives en langage naturel.

Ressources connexes

Pour plus d'informations, consultez la première partie de notre article de blog sur la modélisation des données : Accélérez la modélisation de vos données avec les modèles de données sectoriels de Databricks