Data Vault 2.0 mit dbt
Im ersten Teil dieser Blogserie haben wir Ihnen das dbt vorgestellt. Jetzt schauen wir uns an, wie Sie dbt implementieren können Data Vault 2.0 mit dbt und welche Vorteile dies mit sich bringt. Wenn Sie den ersten Teil noch nicht kennen, können Sie ihn lesen hier:
dbt bietet die Möglichkeit, Modelle zu erstellen und aus diesen Modellen dynamisch SQL zu generieren und auszuführen. So können Sie Ihre Datentransformationen in Modellen mit SQL und wiederverwendbaren Makros auf Basis von Jinja2 schreiben, um Ihre Datenpipelines sauber und effizient auszuführen. Der wichtigste Teil für den Anwendungsfall Data Vault ist jedoch die Möglichkeit, diese Makros zu definieren und zu verwenden.
Doch zunächst sollten wir klären, wie Modelle im dbt funktionieren.
Dbt übernimmt die Kompilierung und Ausführung von Modellen, die mit SQL und der Makrosprache Jinja geschrieben wurden. Jedes Modell besteht aus genau einer SQL SELECT-Anweisung. Der Jinja-Code wird während der Kompilierung in SQL übersetzt.
In diesem Artikel:
Diese Abbildung zeigt ein einfaches Modell in dbt. Ein großer Vorteil von Jinja ist die Möglichkeit, SQL programmatisch zu generieren, zum Beispiel mit Schleifen und Bedingungen. Außerdem versteht dbt durch die ref()-Funktionen die Beziehungen zwischen den Modellen und erstellt einen Abhängigkeitsgraph. Dadurch wird sichergestellt, dass die Modelle in der richtigen Reihenfolge erstellt werden und dass die Datenherkunft dokumentiert ist. Ein Abstammungsdiagramm kann wie folgt aussehen:
Die Materialisierung von Modellen kann auf verschiedenen Konfigurationsebenen definiert werden. Dies ermöglicht ein schnelles Prototyping mit Ansichten und den Wechsel zu materialisierten Tabellen, wenn dies aus Leistungsgründen erforderlich ist.
Data Vault 2.0 und Makros
But how can we implement Data Vault 2.0 with dbt? The most important part for using Data Vault 2.0 is the ability to define and use macros. Macros can be called in models and then generate into that macro additional SQL or even the entire SQL code.
Sie könnten z. B. ein Makro erstellen, um einen Hub zu generieren, der das Quell-/Staging-Modell als Eingabeparameter sowie die Spezifikation der Spalten für den/die Geschäftsschlüssel, das Ladedatum und die Datensatzquelle erhält. Der Sql-Code für den Hub wird dann dynamisch daraus generiert. Dies hat den Vorteil, dass sich eine Änderung des Makros direkt auf jeden einzelnen Hub auswirkt, was die Wartungsfreundlichkeit erheblich verbessert.
An dieser Stelle profitieren Sie auch von der aktiven Open-Source-Gemeinschaft rund um dbt. Es gibt viele Open-Source-Pakete, mit denen dbt erweitert werden kann.
There are also already some packages that are perfect for using Data Vault 2.0 with dbt.
We at Scalefree are currently developing an open-source dbt package that provides macros to translate a Modell Data Vault “on paper”, to actual tables and views like Hubs, Links, Satellites and more. Abonnieren Sie unseren Newsletter, um benachrichtigt zu werden, sobald er verfügbar ist.
Das Einzige, was Sie in Ihrem Modell brauchen, zum Beispiel für einen Hub, ist ein einziger Makroaufruf:
{%- hub(src_pk, src_nk, src_ldts, src_ource, source_model) -%}
Mit den Parametern des Makroaufrufs definieren Sie die Quelltabelle, in der die Spalten zu finden sind (source_model), und die Spaltennamen für den Hash-Schlüssel (src_pk), den/die Business-Schlüssel (src_nk), das Ladedatum (src_ldts) und die Datensatzquelle (src_source). Wenn das Modell und das/die im Modell definierte(n) Makro(s) ausgeführt werden, wird das SQL kompiliert und auf dem Datenbanksystem verarbeitet.
Die benötigten Metadaten können zum Beispiel in Variablen mit jinja direkt im Modell definiert werden:
Sie können auch sehen, dass dbt verschiedene Optionen für die Materialisierung bietet. Die inkrementelle Materialisierung beispielsweise lädt eine Entität als Tabelle auf inkrementeller Basis.
Wenn das Modell ausgeführt wird, generiert dbt die gesamte Sql aus dem Makro und entscheidet, wie die Datensätze geladen werden. Wenn die Hub-Tabelle noch nicht existiert, wird sie erstellt und alle Datensätze werden geladen, wenn sie bereits existiert, wird die Tabelle inkrementell geladen.
Wer schon einmal versucht hat, eine Data Vault mit "Vanilla"-SQL zu implementieren, wird feststellen, dass dies eine echte Neuerung ist. Das Team kann sich nun voll und ganz auf das Data Vault-Design selbst konzentrieren. Sobald die Metadaten identifiziert sind, kann dbt zusammen mit Ihren Makros die gesamte Logik übernehmen.
Offen verfügbare Pakete können grundlegende Data Vault 2.0-Prinzipien zu dbt hinzufügen und ermöglichen so den schnellen Einstieg in die Data Vault-Implementierung. Die allgemeine Offenheit von dbt ermöglicht es Ihnen, alle Makros beispielsweise an Ihren unternehmens- oder projektspezifischen Data Vault-Geschmack anzupassen, um Ihre technischen und geschäftlichen Anforderungen zu erfüllen.
However it is important to mention, that existing dbt packages that allow to use Data Vault 2.0 with dbt does not completely fulfill Data Vault 2.0 standards and deviates from them in details. Currently, we at Scalefree are working on an open-source dbt package that provides all important Data Vault 2.0 entities, as well as the latest standards and best practices and will be released soon. But these details are worth another blog post!
Schlussfolgerung
Integrating Data Vault 2.0 with dbt streamlines the data warehousing process by leveraging dbt’s capabilities to define models and macros, enabling efficient and dynamic SQL generation. This approach allows teams to focus on Data Vault design, with dbt handling the underlying logic. While existing dbt packages offer foundational Data Vault 2.0 principles, they may not fully adhere to all standards. Recognizing this, Scalefree is developing an open-source dbt package that aligns with the latest Data Vault 2.0 standards and best practices, aiming to provide a comprehensive solution for practitioners.
-von Ole Bause (Scalefree)