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.
