Hernan Revale

datavault4dbt im Detail

In unserem ersten Beitrag dieser Serie haben wir uns mit der Erstellung unseres Staging-Layers mithilfe von datavault4dbt befasst, einem Open-Source-Paket, das für Data Vault 2.0 innerhalb von dbt entwickelt wurde. In diesem Teil beginnen wir mit dem Aufbau unserer ersten Standard-Entitäten für Data Vault 2.0 im Raw Vault, darunter Hubs, Links und Satelliten. Wie schon im vorherigen Beitrag empfehlen wir Ihnen, sich im Wiki des GitHub-Repositorys des Projekts über die neuesten Änderungen und Anpassungen des datavault4dbt-Pakets zu informieren.

Bevor wir beginnen

Bevor wir beginnen, stellen Sie sicher, dass Sie das datavault4dbt-Paket korrekt in Ihrer packages.yml-Datei installiert und dbt deps ausgeführt haben.

Für dieses Tutorial verwenden wir die TPCH-Beispieldaten von Snowflake. Zudem gehen wir davon aus, dass Sie Ihr Staging-Modell bereits erstellt haben, einschließlich der Berechnung von Hash-Keys und Hash-Diffs. Hier ist ein Ausschnitt aus der Konfiguration unseres Staging-Modells, den wir später bei der Erstellung der Raw-Vault-Entitäten benötigen werden:

stg_orders

A. Standard-Hub mit datavault4dbt

Hubs werden auf der Grundlage einer eindeutigen Liste von Business-Keys erstellt, was ihre Konfiguration vergleichsweise einfach macht. In diesem Beispiel erstellen wir den Hub für Bestellungen (orders):

order_h

• hashkey: Der Name des Hash-Keys im Staging-Modell
• business_keys: Name des Business-Keys, der als Input für den zuvor genannten Hash-Key verwendet wird
• source_models: Name unseres Staging-Modells

B. Standard-Link mit datavault4dbt

Link-Modelle stellen Verbindungen zwischen Business-Keys her. In unserem Fall erstellen wir eine Verbindung zwischen dem zuvor erstellten Order-Hub und dem Customer-Hub:

order_customer_1

• link_hashkey: Hash-Key des Links, generiert unter Verwendung der Foreign-Keys aus den Hubs im Staging-Layer
• foreign_haskeys: Eine Liste von Foreign-Hash-Keys, die in unseren Link aufgenommen werden sollen
• source_models: Name unseres Staging-Modells

C. Standard-Satellite Version 0 mit datavault4dbt

Gemäß den Data-Vault-2.0-Standards werden Version-0-Satelliten als inkrementelle Tabellen erstellt. In unserem Beispiel wird der Satellit mit dem zuvor erstellten Order-Hub verbunden:

order_0s

• parent_hashkey: Name des Hash-Keys der übergeordneten Entität, in unserem Fall des Order-Hubs
• src_hashdiff: Bereits im Staging-Modell berechneter Hash-Diff
• src_payload: Ursprüngliche Spalten, die bei der Hash-Diff-Berechnung verwendet wurden
• source_model: Name unseres Staging-Modells

D. Standard-Satellite Version 1 mit datavault4dbt

Darüber hinaus ist der Version-1-Satellit eine virtuell generierte Entität, die auf unserem Version-0-Satelliten aufbaut. Neben dem Materialisierungstyp besteht der Hauptunterschied zum V0-Satelliten in der Einführung einer neuen Spalte zur Berechnung des Load-End-Date. Das Load-End-Date wird für uns nachgelagert bei der Arbeit mit PIT-Tabellen im Business Vault nützlich sein.

order_s

• sat_v0: Name des zugehörigen Version-0-Satelliten
• hashkey: Name des Hash-Keys der übergeordneten Entität, in unserem Fall des Order-Hubs
• hashdiff: Bereits im Staging-Modell berechneter Hash-Diff
• ledts_alias: Name der zu generierenden Load-End-Date-Spalte
• dd_is_current_flag: Wenn „true“, wird eine neue Spalte generiert, die die zuletzt geladenen Zeilen basierend auf dem Load-End-Date markiert

Fazit

Mit der Erstellung von Standard-Entitäten im Raw Vault haben wir ein solides Fundament für unsere Data-Vault-2.0-Architektur gelegt. Durch die Nutzung von datavault4dbt innerhalb von dbt haben wir die Entwicklung von Hubs, Links und Satelliten vereinfacht. Diese grundlegenden Bausteine bilden das Fundament einer robusten und skalierbaren Data-Warehousing-Lösung. Im weiteren Verlauf dieser Serie behandeln wir fortgeschrittene Konzepte und tauchen tief in die Feinheiten der Data-Vault-Modellierung ein, um das volle Potenzial unserer Daten zu erschließen.

DataVault4dbt kennenlernen

Letztes Jahr hat Scalefree DataVault4dbt veröffentlicht, ein Open-Source-dbt-Paket für Data Vault 2.0, das Ladetemplates für die Erstellung und Modellierung von Data Vault 2.0-Entitäten nach aktuellen Standards und Best Practices enthält. Wenn Sie mehr über den allgemeinen Inhalt des Pakets und die Motivation dahinter lesen möchten, erfahren Sie hier mehr darüber.

Wir freuen uns, eine Reihe aufschlussreicher Beiträge und Webinare zu starten, die praktische Implementierungen von DataVault4dbt vorstellen. Dies versetzt Sie in die Lage, das volle Potenzial des Pakets in Ihren Data-Warehousing-Projekten auszuschöpfen. Heute beleuchten wir die Anwendung im Staging-Layer.

Bevor wir mit DataVault4dbt starten

Wir setzen grundlegende Kenntnisse in Data Vault 2.0 und dbt voraus. Zudem verwenden wir für die folgenden Beispiele die dbt-Cloud-IDE, die mit Snowflake verbunden ist. Eine aktuelle Liste der unterstützten Plattformen finden Sie im GitHub-Repository des Pakets.

Bitte beachten Sie auch, dass Sie für eine optimale Nutzung der Makros einige Voraussetzungen erfüllen müssen:

• „Flat & Wide“-Quelldaten, die in Ihrer Zieldatenbank zugänglich sind
• Eine Load-Date-Spalte, die den Zeitpunkt des Eintreffens im Quelldatenspeicher angibt
• Eine Record-Source-Spalte, die die Herkunft der Quelldaten detailliert beschreibt, wie z. B. den Speicherort der Datei in einem Data Lake

In unserem Fall haben wir die Daten aus dem in dbt verfügbaren Beispielprojekt „jaffle_shop“ verwendet und angepasst.

Installation des DataVault4dbt-Pakets in dbt

Die Installation von DataVault4dbt erfolgt wie bei jedem anderen Paket in Ihrem dbt-Projekt. Sie müssen lediglich zwei einfache Schritte befolgen:

1. Fügen Sie es Ihrer packages.yml-Datei hinzu

2. Führen Sie „dbt deps“ aus

Nutzung des Makros für das Staging der Quelldaten

Laut der Dokumentation für den Staging-Layer von DataVault4dbt konzentriert sich diese Schicht in erster Linie auf das Hashing. Sie bietet auch Funktionalitäten wie das Erstellen abgeleiteter Spalten (Derived Columns), das Durchführen von Prejoins und das Hinzufügen von NULL-Werten für fehlende Spalten. Anstatt tief in die technischen Aspekte jeder Makrokomponente einzutauchen, die in der Dokumentation ausführlich behandelt werden, steigen wir direkt in die Anwendung ein!

A. Grundlegende Quellinformationen

Identifizierung des Quellmodells (source_model):

• Wenn Sie auf eine Quelle verweisen, verwenden Sie das Dictionary-Format: ’source_name‘: ’source_table‘.
• Für Modelle innerhalb unseres dbt-Projekts verwenden Sie einfach den Modellnamen: ’source_table‘.

Festlegen von Load-Date-Timestamp (ldts) & Record-Source (rsrc):

• Beide können auf eine Spalte aus der Quelltabelle oder einen detaillierteren SQL-Ausdruck verweisen.
• Zusätzlich können Sie für die Record-Source eine statische Zeichenfolge verwenden, die mit „!“ beginnt, wie z. B. „!my_source“.

Beispiel

• source_model: Ruft eine bereits in dbt erstellte Tabelle namens „orders_example“ auf.
• ldts: Ruft eine Timestamp-Spalte aus unserem Quellmodell auf.
• rsrc: Ruft eine Spalte auf, die eine Zeichenfolge enthält, die sich auf unseren Record-Source-Namen bezieht.

B. Hashing

In DataVault4dbt beschreibt der Parameter hashed_columns, wie Hashkeys und Hashdiffs generiert werden. Für jede Hash-Spalte gilt:

• Der Key repräsentiert den Namen der Hash-Spalte.
• Für Hashkeys ist der Wert eine Liste von Business-Keys.
• Für Hashdiffs ist der Wert in der Regel eine Liste beschreibender Attribute.

Beispiel

• hk_order_h: Hashkey, der unter Verwendung von zwei Spalteneingaben (O_ORDERKEY und O_CUSTKEY) generiert wurde
• hd_order_s: Hashdiff, der unter Verwendung mehrerer beschreibender Attribute generiert wurde

C. Derived Columns

Derived Columns in DataVault4dbt-Stage-Modellen ermöglichen es Ihnen, spezifische Transformationen direkt auf Daten anzuwenden. Sie fungieren als On-the-fly-Anpassungen, die sofortige Änderungen an den Daten innerhalb der Spalte selbst ermöglichen. Wenn Daten nicht im gewünschten Format vorliegen, können Sie mit DataVault4dbt mithilfe einer definierten Regel eine neue Version direkt in der Spalte ableiten.

Bei der Einstellung des Parameters derived_columns enthält jede abgeleitete Spalte (Derived Column):

• value: Der Transformationsausdruck.
• datatype: Der Datentyp der Spalte
• src_cols_required: Quellspalten, die für die Transformation benötigt werden.

Je nachdem, wie Sie die Derived Column und die Quellspalten benennen, können Sie zwei Ergebnisse erzielen:

1. Wenn der Name der Derived Column mit dem Namen der Quellspalte übereinstimmt, werden die ursprünglichen Spaltendaten durch die transformierten Daten ersetzt. Dies bedeutet im Wesentlichen, dass Sie die Originaldaten überschreiben.
2. Wenn sich der Name der Derived Column hingegen vom Namen der Quellspalte unterscheidet, führt die Transformation zu einer völlig neuen Spalte, wobei die Daten der ursprünglichen Spalte erhalten bleiben.

Beispiel

• price_euro: Erstellung einer neuen Spalte mit denselben Werten wie die Spalte O_TOTALPRICE.
• country_isocode: Erstellung einer neuen Spalte mit einer statischen Zeichenfolge „GER“.

D. Prejoining

Warum Prejoin?

In bestimmten Szenarien enthalten Ihre Quelldaten möglicherweise nicht den Business-Key, bei dem es sich häufig um eine für Menschen lesbare Kennung wie eine E-Mail-Adresse oder einen Benutzernamen handelt. Stattdessen enthalten sie möglicherweise einen Technical-Key, bei dem es sich um eine intern generierte Kennung oder einen Code handeln kann. Wenn Sie den für Menschen lesbaren Business-Key in Ihrer Verarbeitung verwenden müssen, aber nur den Technical-Key haben, nutzen Sie Prejoining, um Ihre Daten mit einer anderen Tabelle zu kombinieren, die Technical-Keys auf Business-Keys abbildet.

Wie definiert man Prejoins in DataVault4dbt?

Das DataVault4dbt-Paket bietet eine strukturierte Möglichkeit, diese Prejoins (prejoined_columns) mithilfe von Dictionaries zu definieren.

Für jede Spalte, die Sie durch Prejoining hinzufügen, müssen Sie einige Parameter angeben:

• src_name: Dies ist die Quelle der Prejoin-Daten, wie in einer .yml-Datei definiert.
• src_table: Dies gibt an, mit welcher Tabelle Sie das Prejoining durchführen, wie in der .yml-Datei benannt.
• bk: Dies ist der Name der Business-Key-Spalte in der Prejoin-Tabelle oder die Spaltenwerte, die Sie in Ihre Tabelle übertragen.
• this_column_name: In Ihren Originaldaten ist dies die Spalte, die mit der Prejoin-Tabelle übereinstimmt. Dies ist oft ein Technical-Key.
• ref_column_name: In der Prejoin-Tabelle ist dies die Spalte, auf die this_column_name verweist. Sie sollte mit den Werten in this_column_name übereinstimmen.

Beachten Sie, dass sowohl „this_column_name“ als auch „ref_column_name“ entweder eine einzelne Spalte oder eine Liste von Spalten darstellen können, die als Basis für die Erstellung der JOIN-Bedingungen dienen.

Beispiel

• c_name: Wir haben die Spalte „C_NAME“ aus der Customer-Quelltabelle importiert, verknüpft über orders.o_custkey = customer.c_custkey.

E. Multi-Active-Konfiguration (multi_active_config)

Der Parameter multi_active_config wird verwendet, wenn Quelldaten verarbeitet werden, die mehrere aktive Datensätze für denselben Business-Key enthalten. Im Wesentlichen müssen Sie angeben, welche Spalten die Multi-Active-Keys und welche die primäre Hashkey-Spalte sind.

Wenn Ihre Quelldaten keine natürliche Multi-Active-Key-Spalte aufweisen, sollten Sie eine solche mithilfe von Funktionen wie row_number in einer vorherigen Schicht erstellen. Fügen Sie dann den Namen dieser neu erstellten Spalte dem Parameter multi_active_key hinzu. Es ist von entscheidender Bedeutung, dass die Kombination aus Multi-Active-Keys, dem Haupt-Hashkey und der ldts-Spalte im finalen Satellite-Output eindeutig ist. Wenn Sie diese Einstellung nicht verwenden, wird davon ausgegangen, dass die Stage nur einzelne aktive Datensätze enthält.

Beispiel

Durch das Festlegen dieses Parameters erhalten wir konsistente Hashdiffs für identische Business-Keys, was sich in nachfolgenden Schichten als vorteilhaft erweist. Wenn Sie wissen möchten, warum, können Sie diesen Beitrag lesen.

F. Missing Columns

In DataVault4dbt hilft der Parameter missing_columns bei der Bewältigung von Szenarien, in denen sich das Quellschema ändert und einige Spalten nicht mehr existieren. Mithilfe dieses Parameters können Sie Platzhalterspalten erstellen, die mit NULL-Werten gefüllt sind, um die fehlenden Spalten zu ersetzen. Dadurch wird sichergestellt, dass Hashdiff-Berechnungen und Satellite-Payloads weiterhin funktionieren. Im Wesentlichen stellen Sie ein Dictionary bereit, bei dem die Spaltennamen die Keys und ihre jeweiligen SQL-Datentypen die Werte sind.

Beispiel

• discount_code: Erstellung einer neuen discount_code-Spalte mit NULL-Werten.

Fazit

Das DataVault4dbt-Paket von Scalefree bietet eine benutzerfreundliche und zugleich leistungsstarke Lösung für die Datenbankmodellierung. In unserem Fall haben wir das Staging-Layer-Makro kennengelernt, das Best Practices mit der Flexibilität verbindet, auf unterschiedliche Quelldatenanforderungen einzugehen. Vom Hashing bis hin zu On-the-fly-Spaltenänderungen rationalisiert dieses Open-Source-dbt-Paket für Data Vault 2.0 komplexe Prozesse.

Während wir das Potenzial des Pakets weiter erforschen, laden wir Sie herzlich ein, an unserer monatlichen Experten-Session teilzunehmen, um tiefer in die Materie einzutauchen. Reservieren Sie hier Ihren Platz und halten Sie sich im GitHub-Repository des Pakets über die neuesten Updates und den Support auf dem Laufenden.