Datenmodellierung im Lakehouse neu gedacht: Einführung von Vibe Data Modeling

Die Herausforderungen bei der Datenmodellierung

In jedem Analytics-Stack entscheidet sich auf dem Silver-Layer Erfolg oder Misserfolg. BI und Dashboards lesen aus Gold; Gold wird aus Silver aufgebaut. Das Silver-Layer-Modell ist das Fundament, auf dem alle Analysten, Data Scientists und BI-Tools aufbauen. Wenn Silver unordentlich, ohne Governance oder voller Duplikate ist, wird alles darüber schwieriger, langsamer und teurer.

Der Weg dorthin war schon immer das Problem. Die meisten Unternehmen verbringen entweder sechs Monate bis drei Jahre damit, ein Silver-Modell von Grund auf manuell aufzubauen, oder sie kaufen ein generisches Branchen-Template (ACORD für Versicherungen, FHIR für das Gesundheitswesen, ARTS für den Einzelhandel, TM Forum SID für die Telekommunikation) und verbringen dann neun bis zwölf Monate damit, es zuzuschneiden, umzubenennen und neu zu verknüpfen. Ein Template ist nur der Durchschnitt einer ganzen Branche: Typischerweise sind nur 20 bis 40 Prozent relevant, und es wurde für kein spezifisches Unternehmen entwickelt. Keiner der beiden Wege hält mit dem Tempo Schritt, in dem moderne Datenprodukte bereitgestellt werden müssen.

Heute kündigen wir Vibe Data Modeling an

Vibe Data Modeling ist ein Multi-Modell-LLM-Agent, der eine einfache englische Beschreibung Ihres Unternehmens in ein vollständiges, mit Governance versehenes und einsatzbereites Silver-Layer-Datenmodell verwandelt. Es wird als einzelnes Notebook bereitgestellt: vier Widgets, ein Durchlauf, ein vollständig bereitgestelltes Modell in Unity Catalog. Wenn Ihnen das Ergebnis nicht gefällt, „viben“ Sie es in einfachem Englisch, bis es passt.

• Stunden statt Monate: ein bereitgestelltes Minimum Viable Model in weniger als zwei Stunden, ein Expanded Coverage Model an einem einzigen Nachmittag.
• Zu 100 % relevant für Sie: Es verwendet Ihre Terminologie, Divisionen und Domänen, nicht den Branchendurchschnitt.
• Konstruktionsbedingt vertrauenswürdig: 251 durchsetzbare Regeln, zwei Architekten-Reviews und ein agentischer Loop, der das Modell vor der Bereitstellung überprüft.
• Native Unity Catalog-Bereitstellung: Schemas, Tabellen, Fremdschlüssel, Klassifizierungs-Tags, Metrik-Views, eine RDFS-Ontologie, ein DBML-Diagramm und Beispieldaten – gemeinsam generiert und versioniert.

User-Vibes sind die oberste Instanz

Ein Prinzip bestimmt den gesamten Agenten: Was Sie sagen, gilt. Eine explizite Anweisung in einem Widget, in model_vibes oder in Ihrer Unternehmensbeschreibung hat Vorrang vor jeder Heuristik, jeder Bewertungsformel, jedem Gate und jeder LLM-Meinung in der Pipeline. Wenn Sie „genau 10 Domänen“ vorgeben, darf kein Tier-Klassifizierer eine elfte hinzufügen.

Wie aus einem Vibe ein Datenmodell wird

Hinter den vier Widgets führt der Agent eine Pipeline in vier Phasen aus: Er versteht Ihre Eingabe, entwirft das Modell Top-down, verknüpft es mit Beziehungen und Metriken und stellt es dann bereit. Jede Phase wird validiert, bevor die nächste beginnt, sodass nur eine fehlerfreie Phase fortgesetzt wird. Dahinter steht ein Multi-Modell-Ensemble: Ein großes Thinker-Modell übernimmt das logische Denken und die Reviews, ein großes Worker-Modell generiert die große Menge an Produkten und Attributen, kleinere Modelle kümmern sich um Domänen, Tagging und Beispieldaten, und ein Judge-Modell bewertet konkurrierende Vorschläge anhand einer Rubrik. Die Besetzung heilt sich selbst, indem sie ein fehlerhaftes Modell herabstuft und es wiederherstellt, sobald es wieder einwandfrei funktioniert.

Wie das Modell organisiert ist

Jedes Modell folgt derselben Struktur von oben nach unten: Organisation, Divisionen, Domänen, Subdomänen, Produkte, Attribute. An der Spitze stehen die drei Divisionen, die fast jedes Unternehmen teilt: Operations (was sie tun), Business (wen sie bedienen) und Corporate (wie sie arbeiten). Operations und Business bilden den Kern; Corporate ist der unterstützende Teil. Eine Domäne ist ein Bounded Context, der eine bestimmte Gruppe von Konzepten besitzt; ein Produkt ist ein reales Geschäftskonzept, das ein Domänenexperte wiedererkennen würde (eine Rechnung, eine Bestellung), niemals technische Infrastruktur oder Analytics; und jedes Attribut muss sich seinen Platz verdienen.

Eine Single Source of Truth und ein sauberer Graph

Zwei strukturelle Garantien halten das Modell konsistent, und beide werden erzwungen. Single Source of Truth bedeutet, dass ein Konzept genau ein besitzendes Produkt hat; ein Kunde wird einmal in customer.customer definiert, und alle anderen verweisen per Fremdschlüssel darauf. Und die Beziehungen bilden einen gerichteten azyklischen Graphen (DAG): Fremdschlüssel zeigen vom Child zum Parent, niemals in einem Kreislauf, kein Produkt bleibt isoliert, und redundante Spalten werden normalisiert, sobald ein Schlüssel platziert wird.

Die Regeln, die es vertrauenswürdig machen

Der Agent setzt 251 Regeln in 20 Gruppen durch. Die strukturellen Regeln sind deterministische Gates, die das tatsächliche Modellverzeichnis auslesen, sodass sie nicht von einer Entscheidung abgebracht werden können. Sie werden während der Erstellung des Modells und erneut am Install-Gate für das bereitgestellte Modell ausgeführt. Der vom Durchlauf gemeldete Qualitätsscore wird aus dem Modell selbst berechnet, nicht aus der Selbsteinschätzung des LLM.

Der agentische Loop: Generieren, Validieren, anders versuchen

Ein einzelner LLM-Durchlauf gilt nie als endgültig. Der Loop generiert einen konkreten Versuch, validiert ihn anhand der deterministischen Gates und der statischen Analyse und ändert bei einem Fehler die Strategie, anstatt den Versuch zu wiederholen. Nicht erfüllte Anforderungen und strukturelle Rückstände (denormalisierte Schlüssel, domänenübergreifende Duplikate, nicht verknüpfte oder zyklische Fremdschlüssel) werden an einen isolierten Reparaturschritt (Sandbox) weitergeleitet und erneut validiert. Ein monotoner Schutzmechanismus (Monotonic Guard) macht jeden Durchlauf rückgängig, der das Modell verschlechtert, sodass es sich nur verbessern oder gleich bleiben kann.

Wie ein Vibe verifiziert wird

Wenn Sie iterieren, wird Ihre Anfrage in strukturierte Verifizierungsanforderungen (VREQs) zerlegt, von denen jede eine diskrete, überprüfbare Anweisung ist. Jede wird von einem isolierten Mutator angewendet und unabhängig verifiziert, wenn möglich deterministisch: Das Gate liest das reale Modell und den physischen Unity Catalog aus, anstatt ein LLM zu fragen, ob die Änderung stattgefunden hat. Der Durchlauf meldet einen Adherence-Score (Einhaltungsscore), und alles Unverifizierte wird erneut in die Warteschlange gestellt, anstatt stillschweigend verworfen zu werden.

Zwei Architekten-Gates

Regeln erfassen, was mechanisch falsch ist; die Architekten-Gates erfassen, was strukturell unklug ist. Der Domain Architect überprüft jede Domäne isoliert; der Global Architect überprüft das gesamte Modell auf domänenübergreifende Duplikate, Verletzungen der Single Source of Truth und strukturelle Integrität. Ergebnisse werden automatisch angewendet, als umgesetzt, zurückgegangen oder blockiert nachverfolgt, und das Review wird in bis zu acht Durchläufen wiederholt, bis alles fehlerfrei ist.

Was Sie mit einem einzigen Durchlauf erhalten

• Ein logisches Modell (model.json) mit allen Domänen, Produkten, Attributen, Fremdschlüsseln und Klassifizierungs-Tags.
• Eine physische Bereitstellung in Unity Catalog: Schemas, Tabellen, Fremdschlüssel (informativ) und Klassifizierungs-Tags.
• Unity Catalog-Metrik-Views: wiederverwendbare KPI-Definitionen auf den Produkten, bereit für AI/BI-Dashboards und Genie.
• Eine RDFS-Ontologie für semantische Tools und KI-Agenten sowie eine DBML-Datei für dbdiagram.io.
• Synthetische Beispieldaten, die für dasselbe Modell generiert wurden, sowie ein vollständiges Pipeline-Protokoll und eine next_vibes-Datei mit vorgeschlagenen Verfeinerungen.

model.json: Eine Single Source of Truth

Alles, was der Agent erstellt, leitet sich von einem einzigen Artefakt ab: model.json. Die physische Bereitstellung, die Ontologie, das DBML-Diagramm, die Metrik-Views, die Beispieldaten, die Dokumentation und die next_vibes-Vorschläge werden alle daraus generiert. Nichts wird doppelt erstellt, sodass das logische Modell und alle nachgelagerten Artefakte niemals voneinander abweichen können.

Was im Unity Catalog landet

Wenn Sie einen Bereitstellungskatalog festlegen, werden Domänen zu Schemas, Produkte zu Delta-Tabellen und Attribute zu Spalten. Fremdschlüssel werden als informative Constraints angewendet. Klassifizierungs-Tags (PII, Glossar, Herkunft) werden beim Erstellen zugewiesen, und Metrik-Views werden darübergelegt.

Zwei Umfänge: MVM und ECM

Die meisten Teams benötigen am ersten Tag noch nicht jede Domäne. Daher erstellt der Agent zwei Umfänge aus derselben Engine. Das Minimum Viable Model (MVM) ist der schlanke Kern, der zuerst erstellt wird. Das Expanded Coverage Model (ECM) bietet eine vollständige Abdeckung des gesamten Unternehmens. Sie können beides erstellen, ein ECM auf ein MVM reduzieren oder ein MVM zu einem ECM erweitern. Die Reduzierung wird durch ein LLM gesteuert, sodass die Kernprodukte geschützt bleiben.

Vibe es, bis es passt

Bei der Verfeinerung macht die Vibe-Datenmodellierung ihrem Namen alle Ehre. v1 ist das Basismodell und entwickelt sich immer weiter nach vorne, niemals zur Seite: Keine Version wird überschrieben, und jede Iteration ist überprüfbar und umkehrbar. Änderungen erfolgen in drei Absichtsmodi: chirurgisch (genau das beheben), ganzheitlich (überall anwenden) und generativ (etwas Neues erstellen) – alles unter denselben Regeln und Prüfungen.

Ein Agent, sechs Operationen

Dasselbe Notebook kann mehr als nur ein erstes Modell erstellen. Das Operations-Widget wählt eine von sechs Operationen aus, die alle dieselben Regeln, Architect Gates und dieselbe Agenten-Schleife nutzen.

So viben Sie eine Version (VOV)

Um eine bestehende Version zu viben, wählen Sie die Operation „vibe modeling of version“, verweisen Sie auf die Version, auf der aufgebaut werden soll, und schreiben Sie Ihre Änderungen in einfachem Englisch (oder fügen Sie die Vorschläge aus next_vibes.txt ein). Der Agent parst diese in VREQs, führt die Pipeline auf dieser Version erneut aus und schreibt eine neue nummerierte Version. Die Ausgangsversion bleibt unberührt.

Ein logisches Modell, viele physische Layouts

Das logische Modell ist ein einziges Artefakt. Das physische Layout ist eine separate Entscheidung, die über ein einziges Widget gesteuert wird. Dasselbe Modell kann als ein einzelner Katalog, als ein Katalog pro Abteilung oder als ein Katalog pro Domäne dargestellt werden. Wenn sich Ihre Governance-Anforderungen ändern, stellen Sie es einfach nach einer anderen Konvention neu bereit – das logische Modell bleibt unverändert.

Branchen-Templates reichen nicht aus

Das Argument für ein generisches Template war schon immer der Vorsprung beim Start. Die Realität, die man oft auf die harte Tour lernt, ist jedoch, dass dieser Vorsprung neun bis zwölf Monate an Anpassungen und Umbenennungen kostet. Ein Template ist das Durchschnittsmodell für eine Branche – konstruktionsbedingt entspricht es also nie dem tatsächlichen Geschäft von jemandem. Vibe-Datenmodellierung erstellt ein Modell in Ihrer Terminologie, mit Ihren Abteilungen und Domänen, generiert in wenigen Stunden und validiert nach denselben Regeln wie jedes andere Modell auch.

Mit dem Agenten erstellte Beispielmodelle

Derselbe branchenunabhängige Agent hat vollständige Expanded Coverage Models für sehr unterschiedliche Sektoren erstellt, die sich jeweils auf die anerkannten Standards der jeweiligen Branche beziehen. Die unten aufgeführten Zahlen sind die veröffentlichten Referenzmodelle im Open-Source-Repository.

Ab heute verfügbar

Die Referenzimplementierung ist ein einzelnes Databricks-Notebook unter agent/dbx_vibe_modelling_agent.ipynb. Füllen Sie die vier Kern-Widgets aus und führen Sie es aus. Alles andere wird standardmäßig an Ihre Branche angepasst.

Ein konkreter Ausgangspunkt: Hier ist der Prompt, den wir zur Erstellung eines Fertigungsmodells verwendet haben, und der erste Vibe in einfachem Englisch, den wir zur Verfeinerung gesendet haben.

• Referenz-Repository (github.com/databricks-industry-solutions/lakehouse-industry-data-models): das Agenten-Notebook, der Orchestrator, eine Testumgebung, über 40 Open-Source-Referenzmodelle und Leitfäden zu Design, Integration, Quality Gates und dem Regelkatalog.
• Das Vibe Data Modeling-Whitepaper: die vollständige technische Abhandlung jeder Pipeline-Stufe, der komplette Regelkatalog, die Architect-Review-Methodik und die Ensemble-Architektur.

Wenn Ihr Team seit Monaten an einem Silver-Layer-Projekt arbeitet, ohne es zu veröffentlichen, ist dies der kürzeste Weg, den wir gefunden haben, um es tatsächlich in die Produktion zu bringen. Beschreiben Sie Ihr Unternehmen in einfachem Englisch, erhalten Sie ein Modell, iterieren Sie, bis es passt, und bringen Sie es in die Produktion.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag