Schluss mit dem Tool-Zoo: Wie Lakeflow und Lakebase die Datenarchitektur radikal vereinfachen

Die Kosten der Fragmentierung: Warum Konsolidierung notwendig ist

Die Fehlersuche in modernen Datenlandschaften ist oft ineffizient: Wenn eine Komponente ausfällt, muss zur Analyse ein Abgleich von Logs über diverse Systeme hinweg erfolgen. Diese Fragmentierung ist der Kern vieler Stabilitätsprobleme.

Über Jahre gewachsene Architekturen gleichen häufig einem Flickenteppich: Es müssen spezialisierte Tools wie Fivetran oder Qlik für die Ingestion, Apache Kafka für das Streaming, dbt für die Transformationslogik und Apache Airflow für die Orchestrierung synchron gehalten werden.

Jede Schnittstelle zwischen diesen Komponenten erzeugt Metadaten-Brüche und Wartungsaufwand. Data Engineers investieren heute einen signifikanten Teil ihrer Arbeitszeit in die Instandhaltung dieser Integrationen („Integration Tax“), statt in die Entwicklung wertschöpfender Datenprodukte.

Die Databricks Data Intelligence Platform zielt darauf ab, diesen Integrationsaufwand architektonisch zu eliminieren. Im Folgenden betrachten wir, wie eine solche konsolidierte Infrastruktur technisch aufgebaut ist.

Lakeflow: Ganzheitliche Datenflüsse statt isolierter Tools

Anstatt für jeden Prozessschritt eine separate Lizenz und Infrastruktur zu betreiben, betrachtet Lakeflow die Datenpipeline als End-to-End-Prozess – von der Quelle bis zur Bereitstellung.

Resiliente Ingestion (Lakeflow Connect)

Die direkte Extraktion aus Enterprise-Systemen (wie SAP oder Salesforce) birgt Risiken für die Quellsysteme – insbesondere bei fehlgeschlagenen Transformationen.

Lakeflow Connect setzt hierfür auf eine Gateway-Architektur. Die Daten werden zunächst extrahiert und in einem Unity Catalog Volume gepuffert (Staging). Erst danach erfolgt die Verarbeitung.

Der Vorteil: Transformationen können beliebig oft neu gestartet werden, ohne das produktive ERP-System erneut durch Abfragen zu belasten. Funktionen wie Change Data Capture (CDC) und automatische Schema-Erkennung sind dabei standardmäßig integriert.

Ereignisverarbeitung ohne Overhead: Zerobus

Bislang war für die Verarbeitung von Echtzeit-Daten (IoT, Clickstreams) oft der Betrieb eines separaten Kafka-Clusters notwendig.

Mit Zerobus Ingest steht nun eine native, serverlose Alternative zur Verfügung. Über eine gRPC-Verbindung schreiben Clients Datensätze direkt in Delta Tables. Dadurch entfällt der administrative Aufwand einer komplexen Message-Queue-Infrastruktur für reine Ingestion-Szenarien.

• Performance: Bei optimierter Konfiguration stehen Daten in unter einer Sekunde für Abfragen bereit.
• Abgrenzung zu Kafka: Zerobus ist ideal für direkte Ingestion. Für Szenarien mit komplexer Stream-Processing-Logik vor der Ingestion oder Geo-Replikation über Rechenzentren hinweg sind Kafka oder Flink weiterhin die bevorzugten Technologien.

Vom „Wie“ zum „Was“: Deklaratives ETL

Klassische Spark-Jobs oder Airflow-DAGs bestehen oft zu großen Teilen aus Infrastruktur-Code (Checkpointing, Partitionierung, Merge-Logik).

Lakeflow Pipelines (Lakeflow Spark Declarative Pipelines | Databricks on AWS) und die Weiterentwicklung der Delta Live Tables setzen auf ein deklaratives Paradigma. Der Engineer definiert den Zielzustand, nicht den Prozessweg:„Erstelle eine Streaming-Tabelle basierend auf Quelle X, bereinige Duplikate und historisiere Änderungen.“

• Serverless Operations: Die Engine entscheidet autonom über inkrementelle Updates oder Full-Refreshs. Wartungsjobs wie OPTIMIZE oder VACUUM laufen abstrahiert im Hintergrund.
• Native Historisierung (Auto CDC): Die Implementierung von Slowly Changing Dimensions (SCD Type 2) erfolgt über standardisierte APIs – sei es via AUTO CDC INTO in SQL oder create_auto_cdc_flow in PySpark. Die Engine handhabt Updates, Inserts und Deletes inklusive korrekter Sequenzierung automatisch.
• Integrierte Qualitätssicherung: Mittels Expectations werden Validierungsregeln direkt am Datensatz definiert. Verletzen Daten diese Regeln (z. B. negative Umsatzwerte), können sie automatisch isoliert und in Quarantäne-Tabellen verschoben werden, ohne den Prozess zu stoppen.

Native Orchestrierung: Lakeflow Jobs

Die Steuerung erfolgt über Lakeflow Jobs (Lakeflow Jobs | Databricks on AWS). Diese decken mittlerweile den Großteil komplexer Orchestrierungsanforderungen nativ ab, was den Betrieb externer Tools (wie eines separaten Airflow-Servers) oft obsolet macht:

• Control Flow: Bedingte Ausführungen (If/Else-Logik) lassen sich direkt im Job-Graphen abbilden.
• Task Values: Dynamischer Parameteraustausch zwischen Tasks ermöglicht komplexe Abhängigkeiten ohne externe Datenbanken.
• Event-Driven: Jobs können ereignisbasiert (etwa durch File Arrival im Object Store) gestartet werden, statt nur zeitbasiert zu laufen.

Lakebase: Konvergenz von OLTP und OLAP

Eine der signifikantesten architektonischen Neuerungen betrifft die Datenbankebene. Bisher existierte eine strikte Trennung: Databricks für Analytics (OLAP) und externe relationale Datenbanken (beispielsweise Postgres) für operative Anwendungen. Dies führte zwangsläufig zu Datensilos und Synchronisationsbedarf.

Zero-ETL Architektur

Lakebase (Lakebase | Databricks) hebt diese Trennung auf. Es handelt sich um eine vollständig verwaltete, PostgreSQL-kompatible Datenbank innerhalb der Plattform. Entwickler nutzen sie für operative Workloads mit der gewohnten niedrigen Latenz.

Der architektonische Clou: Lakebase repliziert Transaktions-Logs über einen internen Mechanismus direkt in das Delta-Format.

Das Ergebnis: Ein Zero-ETL-Workflow, bei dem operative Daten ohne manuelle Pipelines in Echtzeit für Analysen im Lakehouse verfügbar sind.

Database Branching: CI/CD für Daten

Für DevOps-Teams bietet Lakebase mit Database Branching eine essenzielle Funktion zur Qualitätssicherung. Während das Branching von Code trivial ist, war das Klonen von Datenbanken bisher ressourcenintensiv.

Lakebase nutzt Copy-on-Write-Technologie: Ein vollständiger Klon der Produktionsdatenbank lässt sich in Sekundenbruchteilen erstellen. Da Branch und Original sich die physischen Datenblöcke teilen, bis Änderungen erfolgen, entstehen kaum Speicherkosten.

Anwendungsfälle:

• Risikoarme Tests von Schema-Migrationen auf Echtdaten.
• Isolierte Umgebungen für die Entwicklung und den Test von KI-Agenten.

Unity Catalog: Konsistente Governance

Das Unterscheidungsmerkmal zu einer heterogenen Tool-Landschaft ist die zentrale Klammer: Der Unity Catalog. Unabhängig davon, ob Daten via Zerobus einfließen, per Lakeflow Connect extrahiert oder in Lakebase erstellt werden – alle Metadaten liegen zentral vor.

Dies ermöglicht eine lückenlose Data Lineage über den gesamten Lebenszyklus der Daten. Governance wird somit integraler Bestandteil der Architektur und nicht erst nachträglich aufgesetzt.

Fazit: Konsolidierung als Effizienztreiber

Die Einführung von Lakeflow und Lakebase markiert einen Paradigmenwechsel von fragmentierten Einzelwerkzeugen hin zu einer integrierten Plattform.

Data Engineers werden von der Wartung fragiler Schnittstellen entlastet und können sich auf die Entwicklung robuster Datenprodukte fokussieren. Neben der technischen Stabilität bietet diese Konsolidierung auch erhebliche wirtschaftliche Vorteile. Wie sich diese Modernisierung monetär auswirkt und wie Legacy-Systeme abgelöst werden können, beleuchten wir im nächsten Teil.