Watch the Video
Data-Vault-Mixed-Models verstehen: Integration von Non-Data-Vault-Entitäten in den Business Vault
Die Data-Vault-Architektur ist eine weit verbreitete Methodik im Data Warehousing, die ein hochgradig anpassungsfähiges Modell für die Verwaltung komplexer Datenumgebungen bietet. Sie organisiert Daten primär in drei Kernkomponenten: Hubs, Links und Satellites. Diese Elemente unterstützen Business Keys, Beziehungen und deskriptive Daten, um eine umfassende Datenstruktur innerhalb des Raw-Data-Vault-Layers zu schaffen. Wie bei vielen Methoden treten in der Praxis jedoch häufig Datenelemente auf, die außerhalb der strikten Grenzen dieser Struktur liegen, was Fragen zur Flexibilität aufwirft.
Dieser Artikel befasst sich mit dem Konzept eines „Mixed Models“ in Data Vault, bei dem Non-Data-Vault-Entitäten neben Raw-Data-Vault-Komponenten koexistieren, und zeigt auf, wie diese in eine Business-Vault-Struktur integriert werden können. Während der reine Data-Vault-Ansatz den Schwerpunkt auf Auditierbarkeit sowie Data Lineage legt und eine nahtlose Automatisierung ermöglicht, können Mixed Models bei umsichtigem Management durchaus eine pragmatische Lösung sein. Ist es also zulässig, Non-Data-Vault-Entitäten mit dem Raw Data Vault innerhalb eines Business Vaults zu kombinieren? Betrachten wir dieses Thema im Detail.
In this article:
Was ist ein Data-Vault-Mixed-Model?
Ein „Mixed Model“ in Data Vault bezeichnet ein Szenario, in dem traditionelle Data-Vault-Strukturen (Hubs, Links und Satellites) parallel zu anderen Non-Data-Vault-Tabellen oder -Entitäten verwendet werden. Im Wesentlichen liegt der Großteil der Daten zwar im strukturierten Raw Data Vault, es existieren jedoch innerhalb derselben Datenbank weitere Datenkomponenten, die nicht der Data-Vault-Architektur entsprechen. Dies wirft Fragen bezüglich der Integration dieser unterschiedlichen Datentypen in den Business Vault auf.
Der Business Vault ist als verfeinerte, operative Version des Raw Data Vaults konzipiert. Er reichert die Rohdaten mit Business-Logik und Transformationen an, um handlungsrelevante Erkenntnisse zu generieren. In Szenarien, in denen ein Mixed Model erforderlich ist, besteht das Ziel häufig darin, bestehende Non-Data-Vault-Tabellen zu nutzen, um geschäftliche Erkenntnisse zu gewinnen und gleichzeitig Eingriffe in das ursprüngliche Datenmodell zu minimieren.
Können Sie Non-Data-Vault-Entitäten mit Rohdaten in den Business Vault integrieren?
Gemäß den Data-Vault-Prinzipien besteht der ideale Ansatz darin, alle Daten als Hubs, Links und Satellites zu strukturieren, um Konsistenz, Auditierbarkeit und Lineage zu gewährleisten. Ein Mixed-Model-Ansatz kann jedoch mitunter notwendig sein. Beispielsweise verfügen Sie möglicherweise über eine Datenbank, die im Raw Data Vault gespeicherte Daten mit Tabellen oder Entitäten kombiniert, die keinen Data-Vault-Strukturen folgen. Ist dies also erlaubt?
Die kurze Antwort lautet: Ja, Sie können Non-Data-Vault-Entitäten technisch in den Business Vault integrieren, dies ist jedoch mit Vorbehalten verbunden. Im Folgenden betrachten wir die wesentlichen Auswirkungen im Detail:
- Nur als Übergangslösung gedacht:
Das Mischen von Non-Data-Vault-Daten mit Raw-Data-Vault-Entitäten wird im Allgemeinen als temporäre Lösung betrachtet. Es kann dabei helfen, Daten rasch einzubinden, die noch nicht in das Data-Vault-Modell passen, und ermöglicht so eine zügige Integration. Im Laufe der Zeit kann dieser Ansatz jedoch zu einer erhöhten Abfragekomplexität führen und die Konsistenz mindern, die Data Vault bietet. - Auswirkungen auf Automatisierung und Wartbarkeit:
Die Einführung nicht standardisierter Tabellen erschwert die Automatisierung innerhalb des Business Vaults. Das Data-Vault-Design setzt auf Automatisierungstools wie dbt, WhereScape und Vaultspeed. Diese Tools ermöglichen einen optimierten Workflow in Data-Vault-Implementierungen, indem sie automatisierte Lineage, Auditing und Datentransformationen unterstützen. Werden Non-Data-Vault-Entitäten eingeführt, beeinträchtigt dies die Automatisierungsfunktionen und erfordert benutzerdefinierte Skripte oder Abfragen, die von den standardmäßigen Data-Vault-Mustern abweichen. - Gefährdung von Auditierbarkeit und Lineage:
Eines der stärksten Wertversprechen von Data Vault ist der Fokus auf Data Lineage und Auditierbarkeit. In einem Mixed Model können diese Aspekte leiden. Ohne die Einhaltung der Struktur aus Hubs, Links und Satellites wird es schwierig, die Datenhistorie nachzuvollziehen, Versionskontrollen durchzuführen und alle Änderungen lückenlos zu erfassen. Für Unternehmen, die aus regulatorischen Gründen oder aufgrund hoher Qualitätsansprüche auf diese Funktionen angewiesen sind, kann eine beeinträchtigte Lineage ein gravierender Nachteil sein. - User Mart als Alternative:
Ein alternativer Ansatz besteht darin, einen „User Mart“ für Ad-hoc- oder analytische Abfragen aufzubauen, der Daten aus dem Raw Data Vault mit Non-Data-Vault-Tabellen kombiniert. Dieser User Mart ermöglicht es den Anwendern, sowohl den Raw Data Vault als auch externe Entitäten abzufragen, ohne die zentrale Business-Vault-Struktur zu beeinträchtigen. Dieser Weg eignet sich besonders dann, wenn Benutzer spezifische Reporting- oder Analyseanforderungen haben, die keine vollständige Data-Vault-Transformation erfordern. - Pragmatischer Ansatz:
Virtuelle Hubs und Links: Eine praktische Zwischenlösung in Data-Vault-Projekten besteht darin, „virtuelle“ Hubs, Links und Satellites für nicht standardisierte Tabellen zu erstellen, die als Platzhalter innerhalb der Raw-Data-Vault-Struktur dienen. Dieser Ansatz ermöglicht eine schnelle Integration und bewahrt gleichzeitig ein gewisses Maß an Standardisierung. Liegt beispielsweise eine Referenztabelle mit Ländernamen und Ländercodes vor, könnten Sie einen virtuellen Hub für das Land erstellen und deskriptive Details als virtuellen Satellite abbilden. Dadurch wird zwar keine vollständige Lineage erreicht, es entsteht jedoch eine funktionale Brücke, bis eine reguläre Data-Vault-Struktur implementiert werden kann. - Referenztabellen und unkritische Daten:
In Szenarien, in denen Daten wie Referenztabellen (z. B. Ländercodes, Postleitzahlen) keine lückenlose Lineage oder Versionsverfolgung erfordern, kann eine breite, flache Referenztabelle verwendet werden. Wenn ein Referenz-Hub und ein Referenz-Satellite nicht zwingend erforderlich sind, reicht es häufig aus, die Daten mit einem Primärschlüssel und deskriptiven Spalten einfach zu halten. Dieser Ansatz eignet sich gut für unkritische Daten, bei denen der Aufwand für die strikte Einhaltung aller Data-Vault-Vorgaben unverhältnismäßig wäre.
Strategien für langfristigen Erfolg mit einem Mixed Model
Wenn Sie sich für ein Mixed Model entscheiden, ist es entscheidend, den zukünftigen Übergang zu einem vollständig Data-Vault-konformen Design von vornherein einzuplanen. Hier sind einige Empfehlungen:
- Refactoring von Non-Data-Vault-Entitäten priorisieren:
Erstellen Sie eine klare Roadmap, um Non-Data-Vault-Tabellen sukzessive in Hubs, Links und Satellites zu überführen. Dieser phasenweise Ansatz ermöglicht es Ihnen, innerhalb bestehender Rahmenbedingungen produktiv zu bleiben und parallel einen robusteren, standardkonformen Business Vault aufzubauen. - Technische Schulden minimieren:
Erfassen Sie alle Non-Data-Vault-Elemente in Ihrem Datenökosystem und behandeln Sie diese als „technische Schulden“, die langfristig verwaltet und abgebaut werden müssen. So behalten Sie stets den Überblick über Bereiche, in denen Auditierbarkeit oder Automatisierung eingeschränkt sein könnten. - Metadatengesteuerte Automatisierung nutzen:
Setzen Sie so weit wie möglich metadatengesteuerte Automatisierungstools ein, um zukünftige Integrationen und Migrationen zu vereinfachen. Diese Tools ermöglichen eine automatisierte Datenverarbeitung entlang der gesamten Data-Vault-Pipeline und erleichtern es, neue Datenquellen anzubinden und in konforme Data-Vault-Strukturen zu überführen. - Strenge Governance für benutzergenerierte Daten etablieren:
In Fällen, in denen Fachbereiche eigene Datenmodelle im User Mart oder im Business Vault einführen, sollten Sie Governance-Richtlinien definieren, um die Datennutzung zu standardisieren und ein Mindestmaß an Ausrichtung an den Data-Vault-Mustern zu wahren. Diese Vorgaben minimieren Risiken für die Datenqualität und stellen sicher, dass Non-Data-Vault-Daten beherrschbar bleiben.
Praxisbeispiel: Ein Mixed Model im Einsatz
Stellen Sie sich einen Finanzdienstleister vor, der einen Raw Data Vault mit Transaktionsdaten betreibt, aber auch über ein separates Schema für Kundenreferenztabellen verfügt, etwa für soziodemografische Kundendaten und Standortdetails. Anstatt diese Tabellen direkt in den Business Vault zu integrieren, könnte das Unternehmen virtuelle Hubs und Links erstellen, die Kunden-IDs und Standorte mit Transaktionen verknüpfen. Dies ermöglicht es, weiterhin innerhalb des Raw-Data-Vault-Frameworks zu arbeiten und gleichzeitig die schrittweise Überführung der Referenztabellen in reguläre Data-Vault-Standards vorzubereiten.
Ein weiteres Beispiel ist ein großes Einzelhandelsunternehmen, in dem benutzergenerierte Datenmodelle im User Mart häufig zur Unterstützung von Marketinganalysen verwendet werden. Hier könnte das Unternehmen ein temporäres Mixed Model implementieren, das schnelle Analysen liefert, während parallel eine phasenweise Migration in vollwertige Data-Vault-Strukturen vorangetrieben wird.
Fazit: Flexibilität und Data-Vault-Integrität in Einklang bringen
Obwohl ein Mixed Model innerhalb der Data-Vault-Architektur nicht die reine Lehre darstellt, kann es als temporäre, pragmatische Lösung dienen, wenn Non-Data-Vault-Entitäten kurzfristig integriert werden müssen. Virtuelle Hubs und Links, User Marts und klare Governance-Richtlinien helfen dabei, die durch nicht standardisierte Tabellen entstehende Komplexität zu beherrschen. Dennoch sollten Unternehmen der sukzessiven Migration aller Daten in das Data-Vault-Modell Priorität einräumen, um die langfristigen Vorteile von Data Vault – wie vollständige Auditierbarkeit, Data Lineage und Automatisierbarkeit – nachhaltig zu sichern.
Letztlich gilt: Die Stärke von Data Vault liegt in seiner Flexibilität, Auditierbarkeit und Skalierbarkeit. Der Einsatz von Non-Data-Vault-Tabellen als Übergangslösung ist machbar – für eine zukunftssichere und verlässliche Informationsarchitektur bleibt ein vollständig Data-Vault-konformes Modell jedoch die beste Wahl.
