Hernan Revale

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.