Einleitung
Mit dem stetigen Wachstum und der zunehmenden Komplexität von Datenökosystemen wird der Bedarf an resilienten Data Pipelines mit schneller Time-to-Market immer wichtiger. Dies motiviert Unternehmen, neue Methoden für ihre ETL-Prozesse einzusetzen, wie zum Beispiel deklarative Pipelines, die es Entwicklern ermöglichen, sich darauf zu konzentrieren, wie der gewünschte Endzustand der Daten aussehen soll, ohne sich um die Ausführungsreihenfolge der Aufgaben kümmern zu müssen.
Mit der Einführung von Delta Live Tables verfolgt Databricks das Ziel, diesen Ansatz auf seiner Plattform umzusetzen und eine Datenverarbeitungslösung bereitzustellen, die die Transformationslogik für den Nutzer übernimmt und zusätzliche Funktionen wie automatisierte Data Quality Checks, Monitoring und Observability bietet.
Deklarativer Ansatz für Data Pipelines
Der Einsatz eines deklarativen Ansatzes ist nicht einzigartig im Data Engineering. Im DevOps-Bereich haben Tools wie Kubernetes und Terraform die Deployment-Praktiken durch das Konzept Infrastructure as Code revolutioniert, das es Ingenieuren ermöglicht, den gewünschten Zustand der Infrastruktur und Umgebung zu definieren, anstatt jeden operativen Schritt einzeln festzulegen. Ähnlich ermöglichen deklarative Pipelines es, den Endzustand der Datenbank zu definieren, während die operativen Aktivitäten vom System übernommen werden.
Traditionell werden ETL-Pipelines erstellt, indem die Ausführungsreihenfolge der Aufgaben explizit festgelegt wird, wobei der Fokus auf den Beziehungen zwischen den Tasks liegt, um konsistente Ergebnisse zu gewährleisten, fehlende Daten zu vermeiden und Duplikate auszuschließen.
Ein typischer Prozess kann in folgenden Schritten definiert werden:
- Herunterladen der Dateien aus dem Storage
- Laden der Daten in Staging Tables
- Durchführung von Transformationen, Zusammenführen von Daten aus verschiedenen Quellen
- Laden in das endgültige Ziel und Durchführung von Data Quality Checks
Obwohl dieser imperative Ansatz flexibel und bekannt ist, kann er mit zunehmender Komplexität der Pipeline schwer skalierbar und wartbar werden, da der Entwickler die Data Lineage manuell abbilden muss. Das erschwert die Optimierung hinsichtlich Parallelisierung, Skalierung und minimaler Kosten.
Deklarative Pipelines hingegen erfordern keine explizite Festlegung der Transformationsreihenfolge. Der Autor der Pipeline gibt an, wie der Endzustand der Daten aussehen soll, und die Pipeline-Engine bestimmt automatisch die tatsächlichen Schritte, d. h. die Reihenfolge der Transformationen, das Scheduling der Tasks, das Handling von Abhängigkeiten, die Ressourcenallokation und die Optimierung. Theoretisch bietet dieser Ansatz Skalierbarkeit und Einfachheit für immer komplexere Datenlösungen.
Diese Methode kann in vielen Anwendungsfällen eine gute Wahl sein, aber bei der Entscheidung für ein deklaratives Framework sollte man die geringere Flexibilität berücksichtigen, da solche Lösungen operative Details abstrahieren, was das Debugging und Troubleshooting erschweren kann. Auch Vendor Lock-in kann ein Problem sein, etwa durch proprietäre Syntax oder plattformspezifische Integrationen.
Einführung in Delta Live Tables
Delta Live Tables (DLT) ist ein deklaratives ETL-Framework zum Aufbau skalierbarer und zuverlässiger Data Processing Pipelines. Es ermöglicht den Nutzern, sich auf die Transformationen und die gewünschten Datenstrukturen zu konzentrieren, während Orchestrierung, Compute-Infrastruktur, Data Quality und Fehlerbehandlung automatisch verwaltet werden.
Was ist der Unterschied zwischen Delta Live Tables und Delta Tables?
Delta Table ist das Standard-Datenformat in Databricks, das das Parquet-Format erweitert und ACID-Transaktionen ermöglicht. Delta Live Tables hingegen erlaubt es, den Datenfluss zwischen diesen Tabellen zu beschreiben, sie zu erstellen und Updates zu verwalten.
DLT verwendet folgende Datasets, um die Ergebnisse deklarativer Abfragen zu verwalten:
- Streaming Table – Delta Table mit Unterstützung für Streaming und inkrementelle Datenverarbeitung, immer bezogen auf eine kontinuierlich oder inkrementell wachsende Datenquelle.
- View – logisches Dataset, das bei jeder Abfrage neu berechnet wird, nützlich zur Aufteilung großer Abfragen in kleinere.
- Materialized View – View mit vorab berechneten Ergebnissen, die bei jedem Pipeline-Update aktualisiert werden.
Delta Live Tables verwendet diese Datasets zur Definition einer Pipeline, die die Haupteinheit für Data Processing Workflows ist. Eine Pipeline wird in der Regel in einer Quelldatei (Notebook oder Python-Datei) definiert, die alle Definitionen von Streaming Tables und Materialized Views in SQL oder Python enthält. Nach der Erstellung des Pipeline-Codes mit der Logik muss die Pipeline selbst mit ihrer Konfiguration angelegt werden.
Wichtige Funktionen von Delta Live Tables:
- Automatisches Abhängigkeitsmanagement und Pipeline-Visualisierung
- Data Quality Enforcement
- Inkrementelle und Streaming Data Processing
- Integriertes Monitoring und Observability
Beispiel für eine DLT-Pipeline
In diesem Kapitel wird eine Beispiel-Pipeline mit Delta Live Tables erstellt, um die Möglichkeiten des Frameworks zu demonstrieren. Das Beispiel verwendet Daten aus /databricks-datasets auf DBFS, speziell das retail-org Dataset. Der Prozess liest Verkaufsdaten, verbindet sie mit Produktdaten und ermittelt die meistverkauften Produktkategorien.
Voraussetzungen:
- Berechtigung zur Cluster-Erstellung
- Lese-/Schreibzugriff auf den Hive Metastore
- Delta Live Tables muss im Workspace aktiviert sein
Schritte zur Erstellung der Pipeline:
- Erstellen Sie ein Databricks SQL Notebook und fügen Sie den Code ein, jede SQL-Anweisung in eine eigene Zelle.
- Definieren Sie die Bronze-Schicht (Ingestion) mit Autoloader.
- Verbinden Sie Verkaufs- und Produktdaten, erstellen Sie eine Tabelle mit Produktkategorie und Data Quality Check.
- Erstellen Sie eine Gold Table mit aggregierten Verkäufen nach Kategorie.
Wenn wir auf einen der Pipeline-Schritte klicken, sehen wir Details des Datensatzes. Von hier aus können wir direkt zum Datenkatalog gehen, um zu sehen, wie die Daten aussehen. Dies wäre keine Option, wenn wir das Zielschema bei der Definition der Pipeline nicht angeben würden.
Wir können auch unsere in der Tabelle product_sales_categorised definierte DQ-Erwartung überprüfen. Es sind keine Fehler aufgetreten, da alle Produktkennungen von sales_orders in der Produkttabelle verfügbar waren.
Wir können auch zu unserem Notebook zurückkehren und die Pipeline von dort aus ausführen, sobald sie mit der Pipeline gekoppelt ist. Es ermöglicht einfachere Änderungen und Debugging an der Pipeline, da wir nicht zwischen Notebook und DLT-Pipeline hin und her wechseln müssen.
Deklarative Data Pipelines vereinfachen die Erstellung und Wartung komplexer Workflows und ermöglichen es Data Teams, sich auf Insights statt auf Infrastruktur zu konzentrieren. Delta Live Tables ist ein Beispiel für diesen Ansatz und ermöglicht zuverlässige Pipelines in Python oder SQL mit automatischer Orchestrierung, Data Quality Controls, inkrementeller Verarbeitung und Monitoring.
Databricks tests mit github aktionen
