Direkt zum Hauptinhalt
Plattform

Modernisierung von SQL-ETL im Lakehouse mit deklarativen Mustern

Wie SQL-Analysten und Analytics Engineers jetzt deklarative Flows für Append, CDC und Batch-ETL direkt in ihren Abfragen nutzen können.

von Matt Jones und Shanelle Roman

  • Deklaratives ETL wird im Rahmen einer umfassenderen „Declarative Everywhere“-Strategie direkt in das Lakehouse integriert.
  • SQL-Analysten und Analytics Engineers können jetzt deklarative Flows für APPEND-, AUTO-CDC- und REPLACE-WHERE-Batch-Updates nutzen, ohne komplexen prozeduralen Code schreiben zu müssen.
  • Anwender können ETL-Aufgaben auf Abfrageebene ganz einfach in ihren standardmäßigen SQL-Workflows ausführen oder für die mehrstufige, projektorientierte Entwicklung zum Lakeflow Pipelines Editor wechseln.

Databricks bringt deklaratives ETL in Data-Warehousing-Workflows im Lakehouse und macht es SQL-Anwendern leichter, komplexe Transformationslogik in vertrauten Umgebungen zu vereinfachen, in denen sie bereits arbeiten.

Dies ist Teil einer umfassenderen Strategie, das deklarative Ausführungsmodell hinter Apache Spark™ Declarative Pipelines in weitere Entwicklungsumgebungen auf ganz Databricks zu integrieren. Anstatt in einer speziellen, pipeline-orientierten Umgebung arbeiten zu müssen, können SQL-Anwender gängige ETL-Muster jetzt direkt in ihren SQL-Abfragen in Databricks Lakehouse definieren.

Wiederkehrende ETL-Muster im Lakehouse vereinfachen

Deklaratives SQL-ETL auf Databricks ist nicht neu. Heute verlassen sich bereits Tausende von SQL-fokussierten Anwendern auf deklarative Primitive wie Materialized Views und Streaming Tables, um wiederkehrende Transformationen zu vereinfachen, nachgelagerte Tabellen auf dem neuesten Stand zu halten und BI-Workloads zu beschleunigen.

Viele wiederkehrende ETL-Muster sind leicht zu beschreiben, aber schwer zu betreiben, da sie benutzerdefinierte SQL-Logik, manuelle Zeitplanung und Orchestrierungsaufwand erfordern. Zu diesen Mustern gehören das Anhängen neuer Datensätze, das Anwenden von CDC-Änderungen und das Aktualisieren nur der geänderten Daten.

Deklarative Primitive funktionieren, weil sie es Anwendern ermöglichen, die gewünschte Tabelle oder Sicht zu beschreiben, anstatt jeden Schritt zur Aktualisierung manuell zu codieren. Databricks übernimmt die Zeitplanung, Aktualisierung und gegebenenfalls die inkrementelle Verarbeitung, sodass Anwender die Logik zur Aktualisierung von Tabellen nicht manuell codieren müssen.

Wir erweitern nun denselben deklarativen Ansatz über den Lakeflow Pipelines Editor hinaus auf weitere wiederkehrende ETL-Muster für Data-Warehouse- und SQL-Spezialisten. Jetzt können Lakehouse-Anwender das gewünschte ETL-Muster definieren – beispielsweise direkt im SQL-Editor –, während Databricks die inkrementelle Verarbeitung, Update-Logik, Zeitplanung und Orchestrierung übernimmt, die für einen zuverlässigen Betrieb erforderlich sind.

image2.png
Inkrementelle REPLACE WHERE-Flows bringen gezielte Aktualisierungen ins Lakehouse

Die ersten im Lakehouse verfügbaren deklarativen Primitive

Die ersten deklarativen Operationen, die im Lakehouse SQL-Editor verfügbar sind, decken drei gängige wiederkehrende ETL-Muster ab: Append-Only-Updates, Change Data Capture und Batch-Overwrites.

Viele dieser Muster sind bereits über deklarative APIs wie AUTO CDC in Lakeflow verfügbar. Der Unterschied besteht hier darin, sie direkt im Lakehouse für SQL-Analysten zugänglich zu machen.

Diese Flows können nach einem Zeitplan aktualisiert, durch vorgelagerte Updates ausgelöst, bei Bedarf ausgeführt oder über SQL-Tasks in Jobs orchestriert werden.

Append-Only-Updates

Append-Only-Updates sind heute das Standardmuster hinter vielen Streaming-Tabellen. Sie werden verwendet, um neue Datensätze aus einer Quelle inkrementell an eine Zieltabelle anzuhängen.

Sie werden häufig für Ingestion-Workloads verwendet, wie das Laden neuer Datensätze aus dem Cloud-Objektspeicher mit Auto Loader.

Anstatt wiederholte Insert-Logik zu schreiben und zu planen, können SQL-Anwender einen einfachen APPEND-Flow definieren, der automatisch neue im Vergleich zu bereits verarbeiteten Daten in der Quelle verfolgt.

Databricks übernimmt die Statusverfolgung und hängt neue Datensätze inkrementell an, sobald sie eintreffen, wobei die zugrunde liegende serverlose Pipeline automatisch verwaltet wird.

Dies bietet SQL-Anwendern eine einfache Möglichkeit, die Datenaufnahme im Append-Stil zu operationalisieren, ohne manuell eine separate Pipeline erstellen, planen oder verwalten zu müssen.

Erfahren Sie, wie Sie APPEND-Flows im Lakehouse definieren.

Change Data Capture

CDC-Pipelines gehören zu den häufigsten – und komplexesten – Mustern im SQL-ETL. Teams verwenden oft MERGE INTO, um Inserts, Updates und Deletes zu verarbeiten. CDC-Daten können jedoch in der falschen Reihenfolge eingehen, was zusätzliche Logik erfordert, um fehlerhafte Ergebnisse zu vermeiden.

Mit AUTO CDC können SQL-Anwender die CDC-Logik mit wenigen Zeilen deklarativem Code im Lakehouse definieren. Mit AUTO CDC ist es einfach, Schlüssel, Sequenzierung, die Behandlung von Löschungen und die Speicherung der Ergebnisse als SCD Typ 1 oder SCD Typ 2 festzulegen – ohne komplexe Merge-Pipelines manuell schreiben zu müssen.

„Bei bsport hat uns SQL AUTO CDC eine viel einfachere und modularere Möglichkeit zur Verwaltung der Datenaufnahme in Databricks eröffnet. Durch die Entkopplung von Tabellen-Ladevorgängen aus einer einzelnen Pipeline haben wir die Verfügbarkeit und Datenaktualität auf unserer gesamten Plattform verbessert. Es ermöglicht uns, Daten von Drittanbietern unabhängig zu verarbeiten, was uns ein besseres Fehlermanagement bietet, die Orchestrierungskomplexität reduziert und die Einrichtung insgesamt einfacher zu betreiben und zu skalieren macht. Für unser Team hat dies einen saubereren, flexibleren SQL-basierten Workflow mit höherer Zuverlässigkeit in der Produktion geschaffen.“—Adrien Marteau, Head of Data, bsport

Erfahren Sie, wie Sie AUTO CDC-Flows für SCD Typ 1 und Typ 2 erstellen.

Batch-Overwrites

Einige Batch-ETL-Workloads müssen nur eine bestimmte Teilmenge von Daten aktualisieren, beispielsweise einen Datumsbereich, eine Partition oder ein Geschäftssegment. Traditionell lösen Teams dies oft mit teuren vollständigen Neuberechnungen oder benutzerdefinierter Überschreibungslogik.

REPLACE WHERE-Flows bringen ein deklaratives Muster für die gezielte inkrementelle Batch-Neuberechnung ins Lakehouse. Anwender definieren ein Prädikat auf der Zieltabelle, und Databricks aktualisiert diesen Bereich automatisch.

Mit Enzyme, der automatischen Inkrementalisierungs-Engine von Databricks, kann Databricks nach Möglichkeit nur die Daten identifizieren und verarbeiten, die sich innerhalb des angegebenen Prädikats geändert haben, anstatt die gesamte Zieltabelle neu zu berechnen oder den gesamten übereinstimmenden Bereich neu zu schreiben.

In Lakehouse-Benchmark-Tests lief das von Enzyme unterstützte REPLACE WHERE 3,4-mal schneller und war 2,5-mal kostengünstiger als das herkömmliche REPLACE WHERE. Dies ist nützlich für die selektive Wiederverarbeitung, Schema-Evolution, Backfills und das Iterieren auf einem kleinen Datenfenster, bevor ein größerer historischer Bereich verarbeitet wird.

Erfahren Sie, wie Sie REPLACE WHERE-Flows verwenden, um eine gezielte Teilmenge einer Tabelle zu aktualisieren (und lesen Sie den Community-Blog hier).

TL;DR: Warum das für SQL-Anwender wichtig ist

Die Modernisierung Ihres ETL erfordert kein vollständiges Umschreiben oder eine Alles-oder-Nichts-Entscheidung für komplexe Pipeline-Frameworks. Durch die Integration deklarativer Semantik in Ihre bestehenden Lakehouse-SQL-Operationen können Sie Ihren bestehenden Code flexibel mit modernisiertem deklarativem SQL kombinieren, wo es am sinnvollsten ist.

Sie können Ihre bestehenden, fein abgestimmten prozeduralen SQL-Abfragen für benutzerdefinierte Aufgaben beibehalten, während Sie deklarative Operationen wie Append-Only-Ingestion, AUTO CDC oder gezielte Batch-Overwrites für wiederkehrende, wartungsintensive Muster nahtlos integrieren. Dies bietet Ihnen das Beste aus beiden Welten: die volle Kontrolle über Ihre traditionelle SQL-Logik zusammen mit automatisierter Statusverwaltung, Abhängigkeitsbehandlung und Schema-Evolution, wo immer Sie es wünschen – und das alles direkt im Lakehouse.

Von deklarativen Primitiven zu vollständigen deklarativen Pipelines

Das Einbinden deklarativer Primitive in Ihre täglichen SQL-Workflows bietet einen praktischen, reibungslosen Ausgangspunkt für die Verwaltung einzelner Tabellen und inkrementeller Logik. Wenn Ihr Projekt an Umfang und Komplexität zunimmt, kann sich Ihr Entwicklungs-Workflow ganz natürlich mitentwickeln.

Für Teams, die mehrere zusammenhängende Transformationen, gemeinsame Abhängigkeiten und Produktions-Workflows verwalten, bietet der Lakeflow Pipelines Editor eine umfassendere, projektorientierte Entwicklungsumgebung für deklaratives ETL – mit Unterstützung für Multi-File-Entwicklung, Abhängigkeitsmanagement, Pipeline-Visualisierung, integrierte Validierung und Bereitstellung in der Produktion.

image1.png
Der Lakeflow Pipelines Editor

Dies ist besonders nützlich für Teams, die viele zusammenhängende Transformationen über Domänen, Datenprodukte oder Geschäftsbereiche hinweg verwalten. Anstatt unzusammenhängende Skripte zu pflegen oder die gesamte Logik in einem einzigen großen Projekt zu zentralisieren, können Teams deklarative Flows in kontrollierten, teameigenen Pipelines auf Databricks organisieren. Mit Unity Catalog kann jedes Team auf gemeinsamen Datenbeständen aufbauen, Berechtigungen konsistent verwalten und die Lineage über Pipelines und nachgelagerte Verbraucher hinweg nachvollziehen.

SQL-Anwender können mit deklarativen Flows im vertrauten SQL-Editor beginnen und dann zum Pipelines Editor wechseln, wenn sie eine strukturiertere Umgebung für größere Projekte, tiefergehendes Pipeline-Management und teambasierte Entwicklung benötigen.

Erfahren Sie mehr über das Erstellen deklarativer ETL-Workflows mit dem Lakeflow Pipelines Editor.

Nutzen Sie Genie Code, um schneller loszulegen

Genie Code erleichtert es SQL-Anwendern, diese deklarativen ETL-Muster in den bereits von ihnen genutzten Workflows zu entdecken und anzuwenden. Anstatt bei Null anzufangen oder vorhandenes SQL manuell in ein produktionsbereites Muster zu übersetzen, können Benutzer Genie Code bitten, sie beim Generieren, Erklären und Verfeinern deklarativer Flows zu unterstützen.

Beispielsweise kann ein Benutzer, der mit CDC-Daten arbeitet, Genie Code bitten, einen AUTO-CDC-Flow zu erstellen – einschließlich der entsprechenden Schlüssel, der Sequenzspalte, der Löschbehandlung und des SCD-Typ-1- oder SCD-Typ-2-Verhaltens. Ein Benutzer, der mit wiederkehrender Batch-Logik arbeitet, kann Genie Code bitten, eine vorhandene Überschreibungslogik in einen inkrementellen REPLACE-WHERE-Flow umzuwandeln.

Da deklaratives ETL in immer mehr Erstellungsumgebungen verfügbar wird, kann Genie Code Benutzer dabei unterstützen, das richtige deklarative Muster für die jeweilige Aufgabe zu finden.

Erkunden Sie für den Einstieg die in den einzelnen Abschnitten oben verlinkte Dokumentation – und nutzen Sie Genie Code im SQL-Editor, um herauszufinden, wo APPEND-Flows, AUTO-CDC-Flows oder REPLACE-WHERE-Flows Ihre bestehende ETL-Logik vereinfachen können.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag

Erhalten Sie die neuesten Beiträge in Ihrem Posteingang

Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.