Einführung in Datavault4DBT: Eine praxisorientierte Reihe über das dbt-Paket für Data Vault 2.0 – Teil 1: Staging Layer

DataVault4dbt kennenlernen

Letztes Jahr veröffentlichte Scalefree DataVault4dbt, ein Open-Source-Paket für dbt auf Basis von Data Vault 2.0 Es enthält Templates für das Beladen von Data Vault 2.0 Modellierungs -Entitäten nach aktuellen Standards und Best Practices. Mehr über die Inhalte und die Motivation hinter dem Paket erfahren Sie hier.

Wir freuen uns, eine Reihe von aufschlussreichen Beiträgen und Webinaren zu starten, in denen wir die praktische Umsetzung von DataVault4dbt vorstellen. Damit können Sie das volle Potenzial des Pakets für Ihre Data-Warehousing-Projekte ausschöpfen. Heute werfen wir einen Blick auf den Einsatz im Bereitstellungsschicht.

Bevor wir mit DataVault4dbt starten

Wir setzen einige Vorkenntnisse in Bezug auf Data Vault 2.0 und dbt voraus. Außerdem verwenden wir für die folgenden Beispiele die dbt Cloud IDE , verbunden mit Snowflake. Eine aktuelle Liste der unterstützten Plattformen finden Sie im GitHub-Repository des Pakets.

Denken Sie außerdem daran, 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 Spalte für den Ladezeitstempel, die den Zeitpunkt des Eintreffens in der Quell-Datenbank angibt
• Eine Spalte für die Datensatzquelle, die den Ursprung der Daten beschreibt, etwa den Dateispeicherort innerhalb eines Data Lakes

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 funktioniert genauso wie die Installation jedes anderen Pakets in Ihrem Projekt. Sie müssen nur zwei einfache Schritte befolgen:

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

2. Führen Sie dbt deps aus

Verwendung des Makros zum Staging unserer Quelldaten

Laut der Dokumentation zur Staging Layer on DataVault4dbt konzentriert sich diese Schicht hauptsächlich auf das Hashing. Sie bietet außerdem Funktionen wie das Erstellen abgeleiteter Spalten, das Durchführen von Prejoins und das Hinzufügen von NULL-Werten für fehlende Spalten. Anstatt tief in die technischen Details jeder einzelnen Makrokomponente einzutauchen, die in der Dokumentation ausführlich behandelt werden, lass uns direkt in die Anwendung eintauchen!

A. Grundlegende Informationen zur Quelle

Identifizierung des Quellmodells (source_model):

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

Einstellung des Ladezeitstempels (ldts) & Datensatzquelle (rsrc):

• Beide können entweder auf eine Spalte aus der Quelltabelle oder einen detaillierteren SQL-Ausdruck verweisen.
• Außerdem können Sie für die Datensatzquelle eine statische Zeichenfolge verwenden, die mit '!' beginnt, z. B. '!my_source'.

Beispiel

• source_model: erweist auf eine bereits im dbt-Projekt erstellte Tabelle mit dem Namen ‘orders_example’.
• ldts: Verweist auf eine Zeitstempelspalte aus unserem Quellmodell.
• rsrc: Verweist auf eine Spalte, die eine Zeichenkette enthält, die den Namen unserer Datensatzquelle beschreibt.

B. Hashing

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

• Der Schlüssel entspricht dem Namen der Hash-Spalte.
• Bei Hashkeys ist der Wert eine Liste von Business Keys..
• Bei Hashdiffs ist der Wert in der Regel eine Liste von beschreibenden Attributen.

Beispiel

• hk_order_h: Hashkey, erzeugt aus zwei Spalten (O_ORDERKEY und O_CUSTKEY)
• hd_order_s: Hashdiff, erzeugt aus mehreren beschreibenden Attributen

C. Abgeleitete Spalten (Derived columns)

Abgeleitete Spalten oder sogenannte "Derived Columns" in DataVault4dbt-Staging-Modellen ermöglichen es Nutzern, bestimmte Transformationen direkt auf die Daten anzuwenden. Sie wirken wie On-the-fly-Anpassungen und erlauben sofortige Änderungen innerhalb der Spalte selbst. Liegt ein Wert nicht im gewünschten Format vor, können Sie mit DataVault4dbt direkt in der Spalte eine neue Version auf Basis einer definierten Regel ableiten.

Beim Setzen des Parameters derived_columns enthält jede abgeleitete Spalte folgende Angaben:

• value: Der Ausdruck der Transformation.
• datatype: Der Datentyp der Spalte.
• src_cols_required: Für die Transformation benötigte Quellspalten.

Je nachdem, wie Sie die abgeleitete Spalte und die Ausgangsspalten benennen, können Sie zwei Ergebnisse erzielen:

1. Wenn der Name der abgeleiteten Spalte mit dem Namen der Quellspalte übereinstimmt, werden die Daten der ursprünglichen Spalte durch die umgewandelten Daten ersetzt. Dies bedeutet, dass Sie die ursprünglichen Daten werden überschreiben.
2. Wenn der Name der abgeleiteten Spalte jedoch nicht mit dem Namen der Ausgangsspalte übereinstimmt, wird eine neue Spalte erzeugt und die Originaldaten bleiben erhalten.

Beispiel

• price_euro: Erstellung einer neuen Spalte mit denselben Werten wie in der Spalte O_TOTALPRICE.
• country_isocode: Erstellung einer neuen Spalte mit einem statischen String 'GER'.

D. Prejoining

Warum Prejoining?

In bestimmten Szenarien enthalten Ihre Quelldaten möglicherweise keinen „Business Key“, also keinen menschenlesbaren Bezeichner wie eine E-Mail-Adresse oder einen Benutzernamen. Stattdessen liegt eventuell nur ein „Technischer Schlüssel“ vor – ein intern generierter Identifier oder Code. Wenn Sie bei der Verarbeitung den menschenlesbaren Business Key benötigen, aber nur den Technischen Schlüssel haben, verwenden Sie Prejoining: Sie verbinden Ihre Daten mit einer anderen Tabelle, die den Technische Schlüssel den entsprechenden Business Keys zuordnet.

Wie definiert man Prejoins in DataVault4dbt?

Das DataVault4dbt-Paket bietet eine strukturierte Möglichkeit, solche Prejoins (über dasprejoined_columns- Attribut) mithilfe von Dictionaries zu definieren.

Für jede Spalte, die Sie per Prejoining hinzufügen, müssen Sie folgende Angaben machen:

• src_name: Die Quelle der vorverknüpften Daten, wie in einer .yml-Datei definiert
• src_table: Die Tabelle, mit der das Prejoining erfolgt, ebenfalls gemäß der .yml-Definition
• bk: Der Name der Business Key-Spalte in der prejoint Tabelle oder die Werte, die Sie übernehmen möchten
• this_column_name: In Ihren Originaldaten ist dies die Spalte, die mit der prejoint Tabelle übereinstimmt. Dies ist oft ein technischer Schlüssel.
• ref_column_name: In der Prejoin-Tabelle die Spalte, auf die this_column_name zeigt; ihre Werte sollten übereinstimmen

Beachten Sie, dass sowohl ‘this_column_name’ als auch ‘ref_column_name’ entweder eine einzelne Spalte oder eine Liste von Spalten sein können, auf deren Basis die JOIN-Bedingungen gebildet werden.

Beispiel

• c_name: Wir haben die Spalte "C_NAME" aus der Kundentabelle geholt und auf orders.o_custkey = customer.c_custkey gejoint.

E. Multiaktive Konfiguration

Auch die multi_active_config wird verwendet, wenn Ihre Quelldaten mehrere aktive Datensätze für denselben Business Key enthalten. Im Wesentlichen müssen Sie angeben, welche Spalten die Multi-Active-Keys darstellen und welches die primäre Hashkey-Spalte ist.

Falls Ihre Quelldaten keine natürliche Multi-Active-Key-Spalte enthalten, sollten Sie eine solche in einer vorgelagerten Schicht erzeugen, beispielsweise mit Funktionen wie row_number. Den Namen dieser neu erstellten Spalte fügen Sie anschließend dem multi_active_key-Parameter hinzu. Wichtig ist, dass die Kombination aus Multi-Active-Keys, Haupt-Hashkey und ldts-Spalte im finalen Satellite eindeutig ist. Wenn Sie diese Einstellung nicht verwenden, wird angenommen, dass in der Staging Layer nur einzelne aktive Datensätze vorhanden sind.

Beispiel

Durch Setzen dieses Parameters erhalten wir konsistente Hashdiffs für identische Business Keys – was in den nachfolgenden Schichten von Vorteil ist. Warum das so wichtig ist, können Sie in diesem Beitrag.

F. Fehlende Spalten

Mit DataVault4dbt hilft der Parameter missing_columns , Szenarien zu handhaben, in denen sich das Quellschema ändert und bestimmte Spalten nicht mehr vorhanden sind. Über diesen Parameter können Sie Platzhalterspalten mit NULL-Werten erstellen, um fehlende Spalten zu ersetzen. Dadurch bleiben sowohl die Hashdiff-Berechnungen als auch die Verarbeitung der Satellite-Payloads funktionsfähig. Im Prinzip geben Sie dafür ein Dictionary an, bei dem die Spaltennamen die Schlüssel und die jeweiligen SQL-Datentypen die Werte sind.

Beispiel

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

Fazit

Scalefree's DataVault4dbt bietet eine einfach zu nutzende und dennoch leistungsstarke Lösung für das Datenbankmodellieren. In unserem Beispiel haben wir das Staging Layer Makro durchlaufen, das Best Practices mit der Flexibilität kombiniert, um unterschiedlichste Anforderungen an Quelldaten zu erfüllen. Von Hashing bis hin zu spontanen Spaltenanpassungen – dieses Open-Source-Paket für Data Vault 2.0 und dbt vereinfacht komplexe Prozesse erheblich.

Während wir das Potenzial von DataVault4dbt weiter erkunden, laden wir Sie herzlich ein, an unseren monatlichen Expertensessions teilzunehmen, um noch tiefer einzusteigen. Reservieren Sie jetzt Ihren Platz hier und bleiben Sie über die neuesten Updates und Unterstützung im GitHub-Repository des Pakets informiert.

- Von Hernan Revale (Scalefree)