Modèles de données métier Lakehouse pour le voyage et la logistique

Modèles de données métier Databricks Lakehouse

Son emplacement

Un modèle de données métier Lakehouse est la couche Silver. Bronze gère l'ingestion brute (Lakeflow, Auto Loader). Silver est le modèle analytique conformé et normalisé que lisent tous les analystes, les outils de BI et les charges de travail de ML. La couche Gold est dérivée des **insight** (tables de KPI, tables de caractéristiques, agrégats) **computées** sur la couche Silver.

Ce qui est fourni avec chaque modèle

Chaque modèle est publié en tant qu'ensemble complet.

`model.json` est le modèle logique qui capture chaque définition de domaine, de sous-domaine, de produit, d'attribut, de clé étrangère, de tag de classification et de vue de métrique. C'est l'unité de référence. Enregistrez-le dans Git, comparez les différentes versions et partagez-le entre les environnements.

Un déploiement Unity Catalog de schémas, de tables Delta, de contraintes de clé primaire, de contraintes de clé étrangère (à titre d'information) et de balises de classification. Les noms exacts du catalogue et du schéma 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 sur les tables physiques, prêtes pour les tableaux de bord d'AI/BI et AI/BI Genie.

Un graphe de connaissances RDFS (ontology/) exprime le même modèle qu'un 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 visualiseur compatible DBML.

SQL DDL (schemas/) 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.

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 est l'ensemble de l'entreprise. Elle contient trois divisions : Opérations (ce que l'entreprise fait physiquement), Activité (qui elle sert et comment elle génère des revenus) et Corporate (le back-office de support). Chaque division contient un ou plusieurs domaines (contextes délimités d'un seul mot, en minuscules et au singulier). Chaque domaine contient au moins deux sous-domaines (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 balises de classification assignés au préalable.

Les divisions Opérations et Activité combinées représentent toujours au moins 80 % des domaines ; la division Corporate est plafonnée à 20 %. Ce ratio garantit que chaque modèle reste centré sur ce qui fait réellement tourner l'entreprise plutôt que sur son back-office administratif.

Chaque modèle est également un graphe orienté acyclique 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 rompus avant la publication ; chaque domaine se connecte à au moins un autre par le biais de clés étrangères, de sorte que les analytiques inter-domaines sont toujours possibles.

Deux périmètres : MVM et ECM

MVM (Modèle Viable Minimum) représente de 30 à 50 % du nombre de tables ECM et couvre uniquement les fonctions métier essentielles. Il est dimensionné pour les engagements des 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, et est dimensionné pour les déploiements de type Fortune 100. La profondeur des attributs est identique pour les deux portées. Le MVM n'est pas un squelette, sa surface est simplement plus réduite.

Comparons les MVM et ECM plus en détail.

Disponibilités pour les Secteurs d'activité du voyage et de la logistique

Pour commencer, nous disposons actuellement de 4 modèles disponibles en tant que MVM ou ECM. Ces modèles sont :

Voyages et hôtellerie ~ un exemple

En consultant le dépôt, vous trouverez une comparaison des types de modèles MVM et ECM pour vous aider à choisir la portée du 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 de la portée du modèle sélectionné. Cela inclut 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 qui cible le secteur d'activité et le périmètre du modèle 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, une portée (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, 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, Merge ou diviser des produits, ajouter un domaine manquant, modifier les conventions de nommage) peuvent le faire à l'aide de l'Agent de modélisation, qui fait évoluer le modèle par le biais de directives en langage naturel.

Ressources connexes

Pour plus d'informations, consultez la première partie de la publication de notre blog sur la modélisation des données ~ Démarrez rapidement votre modélisation de données avec les modèles de données sectoriels Databricks

Obtenez les modèles de données sectoriels Databricks Lakehouse sur GitHub ~ Modèles de données sectoriels Lakehouse sur GitHub