Was ist überhaupt Lineage?
In modernen Data Analytics Lösungen bezieht sich der Begriff "Lineage" auf die Verfolgung und Darstellung der Herkunft und des Verlaufs von Daten. Sie beantwortet die Frage: "Woher stammen diese Daten und wie haben sie sich im Laufe der Zeit verändert?"
Die Daten-Lineage verfolgt den Weg der Daten von ihrer Quelle bis zu ihrer Verwendung oder Transformation innerhalb des Data Warehouse oder der Data Platform. Dies schließt typischerweise ein:
- Datenquellen: Die Quellen, an denen Daten ursprünglich entstehen oder eingegeben werden wie ERP, CRM, Excel Files etc.
- Transformationen: Jeder Schritt der Datenverarbeitung oder -umwandlung, der auf die Daten angewendet wird. Das können Filter, Aggregationen, Berechnungen und andere Operationen sein.
- Zwischenstufen: Jeder Speicherort oder Schicht, durch die die Daten während des Verarbeitungsprozesses z.B. in einer Medaillen Architektur gehen.
- Endziele: Die verschiedenen Bereiche, in denen die verarbeiteten Daten gespeichert oder präsentiert werden, wie Datenbanktabellen, Berichte oder Dashboards.
Die Daten-Lineage ist wichtig, um Transparenz und Vertrauen in die Daten zu schaffen. Sie ermöglicht Benutzern, den Ursprung und den Weg der Daten nachzuvollziehen, was bei der Fehlersuche, der Compliance und der Qualitätssicherung entscheidend ist.
Der dbt DAG
Der DAG (Directed Acyclic Graph), ist für mich das wichtigste Feature in dbt. DAGs visualisieren die Datenpipelines, Datenherkunft und die Beziehungen zwischen Tabellen, Views oder Reports und Dashboards anzeigen.
Der DAG gibt einen schnellen Überblick, welche Elemente im Modell einander vor- und nachgelagert sind. Upstream-Modelle müssen vor der Ausführung des gewählten Modells vorhanden sein. Nachgelagerte Modelle basieren auf diesen und sind entsprechend von Upstream-Modellen abhängig. Dadurch erhalten wir sofort eine Lineage Visualisierung wie die verschiedenen Modelle voneinander abhängig sind.
dbt macht diese Beziehung in der DAG deutlich, indem alle Upstream-Modelle links von einem Modell und alle Downstream-Modelle rechts davon platziert werden. Richtungspfeile betonen den Datenfluss zwischen Modellen zusätzlich.
Immer wenn eine Dokumentation für das Modell erstellt wird, generiert dbt das begleitende dbt-Herkunftsdiagramm.
Woher nimmt dbt die Informationen für den DAG?
DBT nutzt für die Verbindung der einzelnen Modelle die sogenannte "ref" Funktion. Diese wird bei der Ausführung des DBT Models dann durch den tatsächlichen Namen in der jeweiligen Umgebung ersetzt.
Die Zuordnung zu Modellen, Quellen, Tests erfolgt über die Konfiguration in den jeweiligen YAML Dateien die benötigt werden um das Model ausführen zu können.
Die notwendigen Informationen für das DAG sind also ein "Abfallprodukt" aus dem Entwicklungsprozess. Nice oder?
Kann ich mein BI Tool in den DAG integrieren?
Jeder Power BI Entwickler kennt diese Ansicht aus dem Power BI Service:
Das Problem dabei ist das in der Verbindung mit einem Data Warehouse / einer Data Platform nur der Quellserver angegeben wird. Wir erkennen aber nicht woher diese Informationen stammen. Also aus welchen Tabellen, Views oder Metriken.
Tools wie Microsoft Purview versprechen uns dieses Problem zu lösen, können dies aktuell aber nur unter sehr viel Aufwand und mit einigen Limitationen, womit diese Lösung für den Mittelstand nicht praktikabel ist.
Aber wie kann ich das nun besser machen?
Mit dbt Exposures können zusätzliche Informationen in das Model integriert werden. Das bedeutet Einträge im DAG generieren die mit der ref Funktion auf Ihre Quellen verweist.
Durch diese Informationen wird das Power BI Dataset "Jaffles by the Week" mit aufgenommen.
Es wird also sehr einfach ermöglicht die Lücke zwischen dem Power BI Service und dem Backend zu schließen.
Darüber hinaus kann die Modelausführung jetzt über diese Beziehungen gesteuert werden.
Model Ausführung Up- & Downstream
Nachdem wir unser komplettes DWH nun einmal visualisiert haben können wir für die zukünftige Ausführung der Modelle meinen Use Case betreffend die Verbindungen im DAG verwenden.
Heißt den Befehl zur Ausführung unserer Modelle können wir durch das hinzufügen eines "+" den Umfang des Aktualisierungsjobs mitgeben.
Mit dem "@" Zeichen werden alle Bestandteile des Graphen vor uns nach meinem aktuellen Modell selektiert. Dies ist insbesondere im Entwicklungsprozess hilfreich.
Fazit
dbt Lineage schließt eine Lücke die in nahezu allen Data Warehouses vorherrscht und das als "Abfallprodukt". Die Lineage ist Objektorientiert und nicht Spaltenorientiert organisiert. Dieses fehlende Feature wird aber in dbt durch andere Funktionen deutlich entschärft.
Endlich die Lücke zwischen Backend und Frontend zu schließen ist ein großer Schritt zu mehr Transparenz für alle Beteiligten.
Die nachträgliche Implementierung von Lineage in bestehende DWHs / Data Platforms allein kostet 6 stellige Projektbudgets und ist dann immer noch nur eine Momentaufnahme. Mit dbt machen wir also von Beginn an alles richtig und müssen dafür noch nicht einmal zusätzliche Governance Prozesse einführen (an die sich eh niemand hält).
In der Welt der Datenanalyse und -verarbeitung spielen Tools und Frameworks eine entscheidende Rolle. Eines dieser Tools, das in den letzten Jahren stark an Bedeutung gewonnen hat, ist DBT, das Data Build Tool. In diesem Artikel werden wir insbesondere auf das integrierte Testing von DBT genauer eingehen. Möchtest du mehr über DBT erfahren, lies gerne auch meinen Artikel "Was ist DBT?" oder "Teil 1" & "Teil 2" der Testing-Reihe und folge mir auf LinkedIn für noch mehr Infos.
.svg)
