[Trends] Analytic Engineering mit Dbt oder DataForm

Analytik-Ingenieure? Oder Analytic Engineering?

‍

Ein weiterer neuer Begriff in der Datenwelt oder ist er ein Beispiel für cleveres Marketing? Analytic Engineering ist ein Begriff, der von dem Team hinter Dbt, Data Build Tool, geprägt wurde.
Dbt und das kürzlich übernommene DataForm sind Tools, die das Data Engineering und die Data Governance für in SQL ausgedrückte Datenpipelines vereinfachen.

Die wichtigsten Triebkräfte für diese Technologie sind das Aufkommen von Cloud-basierten Data Warehouses und das auf dem Markt verfügbare SQL-Wissen.

‍

Der Übergang zu Cloud Data Warehouses

In der Datenwelt haben wir das Zeitalter der schwer zu skalierenden relationalen Datenbanken und Data-Warehouse-Appliances erlebt, die oft auf teurer Hardware vor Ort betrieben werden.
Gefolgt von der Einführung von Dokumenten- oder Key-Value-Datenbanken mit flexiblen Schemata, aber weniger leistungsfähigen oder komplexeren Abfragefunktionen.
Die Datenverarbeitung verlagerte sich von traditionellen ETL-Tools hin zu einer groß angelegten verteilten Datenverarbeitung für strukturierte und unstrukturierte Daten auf massiven, aber schwer zu verwaltenden Hadoop/Spark-Clustern. Heutzutage vereinfachen Cloud-Plattformen und unabhängige Anbieter die Cluster-Verwaltung in der Cloud und bieten mehr Flexibilität bei der bedarfsgerechten Skalierung von Clustern.

Andererseits sind moderne Cloud-Data-Warehouses mit einer Architektur, die aus leistungsstarkem, aber erschwinglichem spaltenbasiertem Speicher und flexibler Rechenleistung besteht, ein entscheidender Fortschritt.
Es ist möglich, große Datenmengen zu speichern und die strukturierten und halbstrukturierten Daten (JSON/XML) mit SQL zu transformieren oder abzufragen.
Das Cloud-Data-Warehouse übersetzt die SQL-Anweisung automatisch in eine hochgradig optimierte verteilte Verarbeitung, ohne dass eine einzige Zeile in der Cloud geschrieben werden muss.

Die Leistungsfähigkeit von SQL

SQL ist aufgrund des deklarativen Charakters und des auf dem Markt verfügbaren Wissens ein Dauerthema in der Daten- und KI-Welt.
Ursprünglich waren Datenverarbeitung und maschinelles Lernen nur durch die Entwicklung von Programmen in Java, Scala, Python usw. möglich. Heutzutage geht der Trend dahin, SQL-Unterstützung hinzuzufügen, um die Programmierung zu vermeiden oder zu minimieren. Gute Beispiele sind Apache Kafka mit KSQL, Apache SparkSQL, FlinkSQL, BigQuery ML, BlazingSQL, BeamSQL.

Warum? SQL-Kenntnisse sind auf dem Markt leichter zu finden als Entwickler mit Big-Data- oder ML-Erfahrung. Personen, die an Datenvisualisierungen arbeiten, kennen oder lernen SQL schneller als Java oder Python. Analysten, die zu Datenwissenschaftlern werden, ziehen es oft vor, SQL zu verwenden, anstatt zu programmieren oder sich auf ein separates Data-Engineering-Team zu verlassen.

Das Problem mit SQL

SQL kann jedoch schwierig zu verwalten sein.
SQL-Anweisungen landen in der Datenbank als Ansichten, Skripte, gespeicherte Verfahren oder geplante Abfragen. Dynamisches oder wiederverwendbares SQL ist schwer zu schreiben. Abhängigkeiten zwischen Tabellen/Views müssen in Cloud Data Warehouses oft manuell verwaltet werden.
SQL-Anweisungen, die mit Code vermischt sind, können unübersichtlich sein.
Die Verwendung eines modernen Job-Orchestrators löst einige dieser Probleme, da ein containerisierter Schritt oder Operator auf eine versionierte, parametrisierte SQL-Anweisung oder ein Skript verweisen kann.

Wir müssen also ein bisschen mehr Best Practices der Softwaretechnik einführen.
Und das ist es, was Dbt und Dataform tun.

Dbt - Technik und Datenverwaltung

Dbt kombiniert Konfigurationsdateien, die die verfügbaren Quelltabellen und Ausgabeartefakte(Berichte/Notizbücher/Dashboards/...) beschreiben, mit Datentransformationen, die als Modelle bezeichnet und mit Hilfe von SQL-Vorlagen geschrieben werden.
Alles wird in Dateien gespeichert, so dass es ein Kinderspiel ist, die Dateien in Git wie jeden anderen Code zu versionieren.

Mit Hilfe von Konfigurationsdateien und Variablen ist es einfach, zwischen verschiedenen Umgebungen zu wechseln.
Mit Hilfe von Materialisierungen ist es eine kleine Codeänderung, um eine Ansicht in eine Tabelle zu verwandeln (truncate/load oder incremental/append-only).
Durch die Kombination von ein wenig Code, Vorlagen und SQL ist es nicht so kompliziert, komplexe SQL auf der Grundlage von Konfiguration, Variablen oder Abfrageergebnissen zu erzeugen. Dbtvault, zur Speicherung von Daten nach den Data Vault 2.0 Modellierungsprinzipien, ist eines der besten Beispiele.

Anstatt auf die physische Datenbank und den Tabellennamen zu verweisen, wird empfohlen, die Syntax "source" und "ref" zu verwenden. Dbt erzeugt automatisch eine DAG, die alle Abhängigkeiten berücksichtigt und alle Schritte in der richtigen Reihenfolge ausführt.
Außerdem bietet dies genau die Art von Datenabfolge, die Endbenutzer und Daten/ML-Ingenieure suchen.
In den Konfigurationsdateien lassen sich problemlos Tabellen- und Spaltenbeschreibungen sowie Datentests hinzufügen.
Datentests sind unverzichtbar, da Cloud-Data-Warehouses oft keine eindeutigen oder Fremdschlüssel-Beschränkungen erzwingen. Und jeder weiß, dass der Kampf mit der Datenqualität in den meisten Datenpipelines leider eine Realität ist.
Müssen Sie Ihre Datenpipeline dokumentieren? Dbt verwendet die Konfigurationsdateien und Modelle, um eine einfach zu bedienende und anpassbare Dokumentations-Website zu erstellen.

‍

Dbt im ML6-Technologiesystem

Bei ML6 verwenden wir BigQuery in einer Vielzahl von Projekten.
Dbt ist seit etwa 1,5 Jahren Teil unseres Tech-Stacks. Die Auswirkungen sind gewaltig.
SQL-basierte Schritte in Datenpipelines sind einfacher zu schreiben, komplexe dynamische Logik wird nur einmal geschrieben und mehrfach wiederverwendet.

Teams, die auf Daten angewiesen sind, profitieren von den automatisch erstellten Dokumenten, der Datenhistorie und den Datentests.

Aus technischer Sicht gefällt uns die Flexibilität von Dbt.
Es lässt sich leicht in unsere Coding- und DataOps/MLOps-Best-Practices integrieren.
Die DAG kann vollständig serverlos mit Cloud Build, containerisiert mit Kubeflow oder als Teil einer Apache Airflow/CloudComposer DAG ausgeführt werden.

2021 könnte das Jahr des "Analytic Engineering" werden. Wir freuen uns auf das schnell wachsende Dbt-Ökosystem. Wir verfolgen genau, wie Dataform in die Google Cloud Platform integriert wird, weil die Funktionalität sehr ähnlich ist, aber die Open-Source-Community kleiner ist.

Behalten Sie unseren Blog im Auge, denn wir werden in Kürze einen Bericht über Dbt Cloud, Dataform und einen technischeren Dbt-Blog veröffentlichen.

‍