dbt Mesh
Erfahren Sie, wie dbt Mesh Data Vault-Projekte in dbt Cloud optimiert, indem es eine effizientere Data Mesh-Architektur ermöglicht. Je größer ein Data-Warehouse-Projekt wird, desto mehr Personen verlassen sich auf die bereitgestellten Daten und arbeiten mit ihnen. Diese Arbeit kann im Anwenden von Geschäftsregeln, dem Modellieren von Fakten und Dimensionen oder anderen typischen Aufgaben innerhalb einer Datenumgebung bestehen. In einer großen Organisation verteilt sich diese Nutzerschaft oft über verschiedene Abteilungen, und die verarbeiteten Daten gehören möglicherweise zu unterschiedlichen Fachbereichen (Business Domains). An einem bestimmten Punkt steht die gesamte Organisation vor der Herausforderung, Data-Sharing- und Governance-Richtlinien umzusetzen, die beispielsweise verhindern, dass Benutzer aus der Vertriebsabteilung auf Daten der Finanzabteilung zugreifen. Ein Data Mesh bietet hierfür eine passende Lösung, die Organisationen bei der Bewältigung dieser Herausforderungen unterstützt. Wenn Sie mehr über Data Mesh erfahren möchten, lesen Sie hier unseren neuesten Blogartikel über Data Vault und Data Mesh hier.
Wir bieten außerdem ein Webinar genau zu diesem Thema an. Verpassen Sie es nicht und sehen Sie sich die Aufzeichnung kostenlos an!
Data Mesh-Unterstützung in dbt Cloud
Viele Organisationen tun sich schwer damit, einen Data Mesh-Ansatz in ihre Data Vault-Landschaft einzuführen. In diesem Webinar tauchen wir tief in dbt Mesh ein und zeigen Ihnen, wie Sie es in einem Data Vault-Projekt gewinnbringend einsetzen können.
Was ist dbt Mesh?
dbt Mesh ist eine Funktion, mit der dbt Cloud noch effizienter mit einem Data Mesh-Ansatz funktioniert. Die bereits bekannte {{ ref() }}-Funktion ist nicht mehr nur auf Modelle innerhalb eines einzelnen dbt-Projekts beschränkt, sondern kann nun auch auf Modelle anderer dbt-Projekte verweisen.
Warum sollten Sie auf andere dbt-Projekte verweisen?
Stellen Sie sich eine große Organisation vor, die dbt Cloud für ihre Data Vault-Implementierung nutzt. Das Projekt umfasst beispielsweise 400 definierte Quellen, 2.000 implementierte Modelle und wird von 30 Entwicklern aktiv genutzt. Von diesen 30 Entwicklern arbeiten vielleicht 5 Personen gezielt an den Schichten des Business Data Vault und der Information Marts für finanzbezogene Objekte. Weitere 5 Entwickler arbeiten an denselben Schichten, jedoch für vertriebsbezogene Objekte.
Ab einem gewissen Punkt möchten Sie verhindern, dass Personen aus dem Finanzbereich Modifikationen an den vertriebsbezogenen dbt-Modellen vornehmen, weshalb eine Data Mesh-Architektur implementiert werden soll. Dies ermöglicht es der Organisation, Richtlinien bezüglich Data Sharing, Data Ownership und weiterer Governance-Maßnahmen festzulegen.
Mit dbt Mesh erhalten sowohl das Sales- als auch das Finance-Team ein jeweils eigenes dbt-Projekt. Da beide auf demselben Raw Data Vault aufbauen sollen, wird ein zusätzliches Basis-dbt-Projekt exklusiv für Staging- und Raw Data Vault-Objekte erstellt. Beide domänenspezifischen dbt-Projekte (Sales und Finance) können nun auf Raw Vault-Objekte innerhalb des Basis-dbt-Projekts verweisen, ohne die Daten physisch duplizieren zu müssen.
Wie können Sie dbt Mesh in einem Data Vault-basierten Data Mesh nutzen?
Data Contracts definieren
dbt-Modelle oder Gruppen von Modellen können nun so konfiguriert werden, dass sie Data Contracts enthalten. In den bereits bekannten .yml-Dateien lässt sich festlegen, dass Modelle öffentlich verfügbar sind (innerhalb einer Organisation), ihnen Data Owner zugewiesen werden und Tabellenschemata gesperrt werden.
Ein Basis-dbt-Projekt erstellen
In einer Data Mesh-Architektur besteht der gängigste Weg zur Implementierung von Data Vault 2.0 darin, einen gemeinsam genutzten Raw Vault als Grundlage zu nutzen, während Business Vault und Information Marts nach Fachbereichen (Business Domains) aufgeteilt sind. In dbt Mesh spiegelt sich dies in einem Basis-dbt-Projekt wider, das alle Staging- und Raw Data Vault-Objekte enthält. Nur die Raw Data Vault-Objekte werden so konfiguriert, dass andere dbt-Projekte auf sie zugreifen können, da Staging-Modelle nicht außerhalb von Raw Data Vault-Modellen verwendet werden sollten.
dbt-Projekte auf Domänenebene hinzufügen
Aufbauend auf dem Basis-dbt-Projekt des Raw Vaults kann jedes Domänenteam nun in einem eigenen dbt-Projekt arbeiten. Die Teams greifen über die erweiterte {{ ref() }}-Funktion auf den Raw Data Vault zu und müssen sich nicht um die Wartung dieser Raw Vault-Objekte kümmern. Zudem können sie definieren, welche ihrer Artefakte für andere Domänen nützlich sein könnten, und diese über eigene Data Contracts bereitstellen.
Verantwortlichkeiten verteilen
Typischerweise erstellt ein Fachanwender keine Hubs, Links und Satellites und es liegt auch nicht in seiner Verantwortung, für einen verlässlichen Raw Data Vault als Grundlage für Transformationen zu sorgen. Daher ist es wichtig, die Verantwortlichkeiten innerhalb jedes dbt-Projekts klar zu definieren. Insbesondere Objekte, die außerhalb eines Projekts geteilt werden, sollten immer über Data Contracts und definierte Owner verfügen. Dies stellt sicher, dass sich die Nutzer dieser gemeinsam genutzten Objekte darauf verlassen können.
Fazit
Alles in allem bietet dbt Mesh eine hervorragende Möglichkeit, einen echten Data Mesh-Ansatz gewinnbringend umzusetzen. Dies ist besonders relevant, wenn verschiedene Fachbereiche einer Organisation in dbt zusammenarbeiten, um verlässliche Ergebnisse zu liefern. In den meisten Szenarien ist es sinnvoll, bereits frühzeitig mit der Nutzung von dbt Mesh zu beginnen, selbst wenn Ihr Projekt noch nicht übermäßig groß ist. Klare Verantwortlichkeiten und Data Contracts helfen stets dabei, das Vertrauen in Ihre Daten zu stärken und die Transparenz zu wahren.
