Modèles de données métier Lakehouse pour le secteur manufacturier et industriel
Modèles de données de la couche Silver prêts pour la production (un par secteur), se déployant dans Unity Catalog comme socle analytique d'un lakehouse Databricks : complets, gouvernés et cohérents dès le premier jour.

Modèles de données métier Databricks Lakehouse
Son positionnement
Un modèle de données métier Lakehouse correspond à la couche Silver. La couche Bronze gère l'ingestion brute (Lakeflow, Auto Loader). La couche Silver est le modèle analytique conforme et normalisé à partir duquel chaque analyste, outil de BI et charge de travail de ML effectue ses lectures. La couche Gold est dérivée des insights (tables de KPI, tables de caractéristiques, agrégats) calculés au-dessus de la couche Silver.

Ce qui est inclus avec chaque modèle
Chaque modèle est publié sous forme de bundle complet.
`model.json` est le modèle logique qui capture chaque domaine, sous-domaine, produit, attribut, clé étrangère, tag de classification et définition de vue de métrique. C'est l'unité de référence. Enregistrez-le dans git, comparez les versions (diff) et partagez-le entre différents environnements.
Un déploiement Unity Catalog de schémas, de tables Delta, de contraintes de clé primaire, de contraintes de clé étrangère (informatives) et de tags de classification. Les noms exacts des catalogues et des schémas dépendent du style de catalogage choisi lors de l'installation.
Les vues de métriques sont des définitions de KPI réutilisables installées au-dessus des tables physiques, prêtes pour les tableaux de bord AI/BI et AI/BI Genie.
Un graphe de connaissances RDFS (ontology/) exprime le même modèle sous forme de graphe sémantique pour l'intégration d'outils sémantiques et l'ancrage d'agents d'IA.
Un diagramme DBML (diagram/) pour l'exploration visuelle dans dbdiagram.io ou tout autre visualiseur compatible DBML.
Le SQL DDL (schemas/) pour l'ensemble du déploiement, organisé par schéma.
La documentation Excel et Markdown est générée en même temps que le modèle.
Données d'échantillon synthétiques facultatives. Les lignes basées sur des pools respectent toutes les clés étrangères, les contraintes regex et les tags de classification.
Hiérarchie

Chaque modèle suit la même hiérarchie. L'organisation représente l'ensemble de l'entreprise. Elle contient trois divisions : Opérations (ce que fait physiquement l'entreprise), Activité (qui elle sert et comment elle génère des revenus) et Corporate (les fonctions de support). Chaque division contient un ou plusieurs domaines (contextes délimités en un seul mot, en minuscules et au singulier). Chaque domaine contient deux sous-domaines ou plus (groupements sémantiques de deux mots). Chaque sous-domaine contient des produits (les tables Delta). Chaque produit contient des attributs (les colonnes), avec des types de données et des tags de classification attribués dès le départ.
Les divisions Opérations et Activité combinées représentent toujours au moins 80 % des domaines ; la division Corporate est limitée à 20 %. Ce ratio permet de maintenir chaque modèle centré sur ce qui fait réellement tourner l'entreprise plutôt que sur ses fonctions administratives.
Chaque modèle est également un graphe orienté acyclique (DAG) par construction. Les clés étrangères pointent toujours de l'enfant vers le parent (order.customer_id, jamais customer.latest_order_id) ; les cycles sont éliminés avant la publication ; chaque domaine se connecte à au moins un autre via des clés étrangères, de sorte que les analyses inter-domaines sont toujours possibles.
Deux portées : MVM et ECM

MVM (Minimum Viable Model) représente 30 à 50 % du nombre de tables de l'ECM et ne couvre que les fonctions métier essentielles, dimensionné pour les projets de PME, les pilotes et les environnements de développement/test.
ECM (Expanded Coverage Model) couvre l'ensemble de l'entreprise, y compris les domaines Corporate de support, dimensionné pour les déploiements Fortune 100. La profondeur des attributs est identique pour les deux portées. Le MVM n'est pas un squelette, mais simplement une surface plus restreinte.
Comparons le MVM et l'ECM plus en détail.

Ce qui est disponible pour les secteurs de la fabrication et de l'industrie
Pour commencer, nous proposons actuellement 6 modèles disponibles en version MVM ou ECM. Ces modèles sont :
| Secteur | Domaines ECM | Produits ECM | Domaines MVM | Produits MVM |
|---|---|---|---|---|
| Fabrication | 20 | 413 | 12 | 129 |
| Fabrication de produits chimiques | 19 | 405 | 14 | 202 |
| Semi-conducteurs | 19 | 385 | 14 | 211 |
| Automobile | 19 | 548 | 14 | 209 |
| Construction | 18 | 365 | 15 | 189 |
| Agriculture | 18 | 408 | 14 | 177 |
Automobile ~ un exemple
En consultant le dépôt, vous pouvez voir une comparaison des types de modèles MVM et ECM afin de prendre une décision éclairée sur le périmètre de modèle qui vous intéresse.

Cela inclut un examen détaillé des domaines et des produits disponibles.

Vous pouvez obtenir des détails sur ce qui fait partie du périmètre de modèle sélectionné. Cela comprend des instructions, des exemples, de la documentation et des notes de version.

Si vous êtes prêt à déployer le modèle dans votre environnement, consultez le fichier readme dans le dépôt principal pour suivre les étapes. Globalement, il vous suffit d'exécuter le notebook d'installation orienté vers le secteur et le périmètre de modèle qui vous intéressent.
Prise en main
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, puis exécutez le notebook d'installation. Une installation MVM classique se termine en quelques dizaines de minutes, contre moins de deux heures pour Databricks Serverless. 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 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 (renommer des domaines, fusionner ou diviser des produits, ajouter un domaine manquant, modifier les conventions de nommage) peuvent le faire à l'aide de Modeling Agent, qui fait évoluer le modèle via des directives en langage naturel.
Ressources associées
Pour plus d'informations, consultez la première partie de notre article de blog sur la modélisation des données ~ Dynamisez votre modélisation des données avec Databricks Industry Data Models
