Data Ingestion auf Databricks: Dateien, APIs, Datenbanken und CDC laden
Die Kernaussagen auf einen Blick.
- Data Ingestion auf Databricks lässt sich auf vier Quellklassen und drei zentrale native Ladewege reduzieren.
- Auto Loader bedient Cloud-Files, Lakeflow Connect die SaaS- und CDC-Quellen, Zerobus Ingest die Low-Latency-Events. Die Ladewege unterscheiden sich vor allem bei Latenz, Schemaänderungen und historischen Backfills.
- Wird für jeden Anwendungsfall ein eigenes Werkzeug eingeführt, entstehen doppelte Lizenzkosten, getrennte Governance-Strukturen und uneinheitliche Betriebsprozesse.
- Mein Vorschlag: Die Plattform sollte auf wenige verbindlich definierte Ladewege standardisiert werden. Native Pfade sind der Default. Externe Werkzeuge sollten nur eingesetzt werden, wenn eine Quelle nicht nativ unterstützt wird oder bestehende Verträge einen kurzfristigen Wechsel unwirtschaftlich machen.
Inhaltsverzeichnis
Für jede Quelle eine eigene Strecke
Die Plattform läuft seit zwei Jahren. Salesforce kommt über Fivetran, SAP wird per nächtlichem Export auf S3 abgelegt und über einen handgeschriebenen Spark-Job geladen, die Marketing-Cloud schickt Files über SFTP, IoT-Events laufen über einen Confluent-Kafka-Cluster, der für genau zwei Werke aufgebaut wurde. Damit werden vier unterschiedliche Ladewege von verschiedenen Teams mit jeweils eigenen Monitoring- und Logging-Ansätzen betrieben. Es ist nicht eindeutig geklärt, ob sich historische Daten über alle Strecken hinweg zuverlässig nachladen lassen.
Diese Situation tritt häufig auf, sobald eine Plattform mehrere Quellsysteme integriert. Für neue Anforderungen wird häufig jeweils ein weiteres Werkzeug eingeführt, mit jeder neuen Quelle kommt eine zusätzliche, individuell betriebene Pipeline hinzu, und nach einiger Zeit fehlt ein einheitliches Modell für Ingestion, Betrieb und Verantwortung. Stattdessen entsteht eine heterogene Pipeline-Landschaft mit teilweise ungeklärter Ownership.
Wie viele technisch unterschiedliche Ladewege werden aktuell betrieben? Welches Team trägt für jeden Ladeweg die operative Verantwortung? Was passiert in jeder Strecke, wenn sich das Schema einer Quelle ändert? Nach welchen Kriterien wird der Ladeweg für eine neue Quelle ausgewählt?
Die zentrale Aussage lautet: Auf Databricks gibt es eine kleine Matrix aus vier bis fünf Quell-Klassen und drei nativen Lade-Pfaden. Eine standardisierte Plattform kann die meisten Quellen mit drei bis vier klar definierten Ladewegen abdecken. Eine individuelle Werkzeugwahl pro Anwendungsfall führt dagegen zu einer schwer wartbaren Pipeline-Landschaft, die sich langfristig nur mit hohem Aufwand einheitlich betreiben lässt. Das ist die zentrale Frage hinter dem Überblick zu Data Engineering auf Databricks.
Was ist Data Ingestion auf Databricks?
Data Ingestion bezeichnet die Übernahme von Quelldaten in die Databricks-Plattform. Dabei werden Daten aus Quellsystemen in einer Form bereitgestellt, auf der nachgelagerte Verarbeitungsschritte aufbauen können: als Bronze-Tabelle in Delta Lake. Die Quellen sind heterogen (Cloud-Storage, SaaS-APIs, operative Datenbanken, Event-Ströme), und die Art der Quelle bestimmt wesentlich, welcher technische Ladeweg geeignet ist. Databricks beschreibt in der Übersicht zur Ingestion auf Databricks eigene Lade-Pfade pro Quell-Klasse.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Dateien, APIs, CDC und Events
Bevor ein Ladepfad gewählt wird, sollte die Quelle klassifiziert werden. Für die meisten Plattformen reicht eine Einteilung in vier Quellklassen sowie einen Sonderfall aus:
Cloud-Files
Dateien, die in einem Object Store landen (S3, ADLS, GCS): CSV, Parquet, JSON, Avro. Typische Lieferanten: Partner-Drops, SaaS-Exports, klassische ETL-Engines, Daten-Marktplätze.
SaaS-APIs
Anwendungs-APIs aus Standard-Software wie Salesforce, Workday, ServiceNow, NetSuite, Google Analytics, Marketing-Clouds.
OLTP-CDC
Änderungen aus operativen Datenbanken über Change Data Capture: SQL Server, Oracle, Postgres, MySQL, SAP HANA.
Event-Streams
Kontinuierliche Ereignis-Ströme mit Sekunden- oder Sub-Sekunden-Verzögerung: IoT-Sensoren, Click-Streams, Telemetrie, Transaktions-Events.
Direktzugriff (Sonderfall)
Die Quelle wird direkt aus dem Lakehouse abgefragt, ohne vorgelagertes Laden, über Lakehouse Federation.
Für die nativen Ladewege gilt grundsätzlich ein ELT-Ansatz: Die Daten werden zunächst möglichst unverändert in der Bronze-Schicht gespeichert. Fachliche und technische Transformationen erfolgen anschließend in Silver und Gold. Was Ingestion und ETL voneinander unterscheidet und warum dieser Default für Databricks gesetzt ist, klären wir im Überblick zu ETL vs. ELT auf Databricks. Die Schichten-Logik selbst kommt aus der Medallion-Architektur.
Standard für inkrementelle Cloud-File-Ingestion
Auto Loader (cloudFiles) liest inkrementell neue Dateien aus Cloud-Storage und lädt sie in Bronze-Tabellen. Auto Loader erkennt neu eingehende Dateien und verarbeitet nur bislang unbekannte Objekte, leitet das Schema aus den Daten ab und verarbeitet Schemaänderungen abhängig von der gewählten Strategie: sie werden übernommen, abgefangen oder abgelehnt. Der Pfad funktioniert kontinuierlich als Streaming-Query oder ausgelöst über einen Job-Trigger.
Auto Loader eignet sich insbesondere für regelmäßig eingehende Dateien in Cloud-Objektspeichern, in denen täglich, stündlich oder im Minutentakt neue Dateien landen. Partner-Lieferungen über S3, SaaS-Exports nach ADLS, Mainframe-Auszüge nach GCS, klassische Batch-Strecken, die in Files enden. Der Dienst ist auch für sehr große Dateibestände ausgelegt. Der Verarbeitungsstatus der Dateien muss dabei nicht selbst entwickelt und gepflegt werden. Databricks dokumentiert die Pfad-Mechanik in der Anleitung zur inkrementellen Ingestion aus Cloud-Object-Storage.
Wofür Auto Loader nicht geeignet ist: SaaS-APIs, OLTP-CDC, Event-Streams. Eine API- oder CDC-Quelle zunächst künstlich als Datei bereitzustellen, erzeugt zusätzliche Latenz und Betriebsaufwand. Die Konfigurations-Tiefe von Auto Loader (Modi der Schema-Erkennung, Datei-Notifikation, Trigger-Strategien) führen wir im Kurzprofil zu Auto Loader auf Databricks aus.
Managed Connectoren für SaaS, Datenbanken und CDC
Lakeflow Connect stellt verwaltete Konnektoren für SaaS-Anwendungen und operative Datenbanken bereit. Databricks beschreibt in der Übersicht zu Lakeflow Connect verwaltete Konnektoren für SaaS-Anwendungen, Datenbanken und File-Quellen, darunter Salesforce, Workday, ServiceNow, NetSuite, Google Analytics, Shopify und SQL Server. Die Ingestion-Pipelines werden als verwaltete Databricks-Ressourcen betrieben. Lebenszyklus, Monitoring und Berechtigungen sind in die Databricks-Plattform integriert.
Die Konnektoren teilen sich inzwischen in zwei Ebenen: von Databricks gepflegte verwaltete Konnektoren und Community-Konnektoren, die über ein offenes Connector-SDK bereitgestellt werden und das abgedeckte Quell-Spektrum erweitern. Für viele Long-Tail-Quellen, die kein verwalteter Konnektor abdeckt, existiert dadurch ein Konnektor, ohne dass eine Eigenentwicklung nötig wird. Verwaltete und Community-Konnektoren unterscheiden sich allerdings in Reife, Wartung und Support. Das gehört in die Bewertung pro Quelle.
Lakeflow Connect eignet sich insbesondere für Standard-SaaS-Quellen, bei denen Databricks einen Konnektor pflegt (Salesforce, Workday, ServiceNow, NetSuite, Google Analytics, SQL Server, Oracle, Postgres). CDC aus operativen Datenbanken läuft über Log-basiertes Capture. Dadurch muss das Plattformteam keinen eigenen CDC-Stack auf Basis von Debezium oder Spark betreiben. Initialer Datenbestand, laufende Änderungen und Schemaabweichungen werden durch den jeweiligen Konnektor verarbeitet.
Wofür Lakeflow Connect nicht geeignet ist: hochindividuelle Eigen-Anwendungen mit eigenem API-Schema, Nischen-Tools, für die weder ein verwalteter noch ein Community-Konnektor existiert, Event-Streams mit Sub-Sekunden-Latenz. Die konkrete Konnektor-Liste und die Mechanik von Initial-Load und CDC führen wir im Kurzprofil zu Lakeflow Connect aus.
Lakeflow Connect kann insbesondere bei Standardquellen den Bedarf an zusätzlichen ETL-Plattformen reduzieren. Eine Plattform, die Fivetran oder Airbyte für SaaS-Quellen einsetzt und gleichzeitig Databricks als Ziel betreibt: Für bestehende Konnektoren sollte geprüft werden, ob eine Migration technisch und wirtschaftlich sinnvoll ist.
Low-Latency Event Ingestion ohne Kafka
Zerobus Ingest ist der neueste der drei nativen Ladewege. Anwendungen senden Ereignisse über ein SDK direkt an die Databricks-Plattform und schreiben sie in Delta-Tabellen. Ein zusätzlicher Message Broker ist dafür nicht erforderlich; daher der Name. Die Verzögerung von Ereignis zur Tabelle liegt im Sub-Sekunden-Bereich. Databricks dokumentiert das Direkt-Ingest-Modell in der Lakeflow-Connect-Zerobus-Übersicht.
Ein Ingestion-Endpoint für die gesamte Plattform..
IoT-Geräte, Backend-Services und Mobile Apps senden Events über gRPC oder REST direkt an Zerobus. Der Service schreibt sie ohne Message Broker in Delta-Tabellen, governed durch Unity Catalog, verfügbar für Dashboards, Transformationen und AI.
Delta Lake
Parquet
IcebergZerobus Ingest eignet sich für Anwendungen, die direkt in das Lakehouse schreiben sollen. Klick-Events aus Web- oder Mobile-Apps, Transaktions-Events aus operativen Systemen, Telemetriedaten aus eigenen Anwendungen und Produkten, IoT-Events aus überschaubaren Werks- oder Anlagen-Setups. Der Ansatz kann den Betriebsaufwand gegenüber einer zusätzlichen Kafka-Infrastruktur reduzieren, weil der Broker entfällt.
Weniger geeignet ist Zerobus Ingest für Szenarien, in denen mehrere unabhängige Systeme denselben Ereignisstrom konsumieren. Bestehende Kafka-Landschaften mit Hunderten von Topics und etablierten Consumern. Komplexe zustandsbehaftete Streaming-Verarbeitung mit Joins, Fenstern und State, die besser in einer dafür ausgelegten Streaming-Engine umgesetzt wird. Die Details zu SDKs, Verzögerung und unterstützten Mustern führen wir im Kurzprofil zu Zerobus Ingest aus.
COPY INTO, Structured Streaming und Lakehouse Federation richtig einordnen
Die drei nativen Ladewege decken einen Großteil der üblichen Quellen ab. Weitere Werkzeuge sind Sonderfälle, die in jeder Lade-Matrix benannt werden müssen. Sie sollten jedoch klar abgegrenzt werden, damit sie nicht ohne konkreten Grund als zusätzliche Standardwege entstehen.
Structured Streaming
Programmierbare Streaming-Engine in Apache Spark, für eigene Logik gegen einen externen Broker: bestehendes Kafka- oder Kinesis-Setup, Joins zwischen Strömen, eigene Fenster-Logik. Bei reinen Cloud-Files-Strömen bleibt Auto Loader die einfachere Wahl, für schlanken Event-Ingest Zerobus.
COPY INTO
SQL-Pfad für einmalige oder unregelmäßige Dateiimporte: Backfill, manuelle Initialladung, seltene Batch-Strecken. Für kontinuierlich eingehende Dateien bietet Auto Loader das geeignetere Zustands- und Schemamanagement.
Lakehouse Federation
Kein Lade-Pfad, sondern direkter Zugriff auf externe Daten als Foreign Catalog, ohne sie zuvor zu kopieren. Sinnvoll bei niedriger Abfragefrequenz, kleinem Datensatz oder wenn eine zusätzliche Kopie organisatorisch nicht vorgesehen ist.
Lakeflow Declarative Pipelines
Kein eigener Quell-Pfad, sondern das deklarative Framework, in dem Auto Loader und Streaming Tables inkrementelle Verarbeitung, Abhängigkeiten und Datenqualitäts-Erwartungen über Bronze, Silver und Gold beschreiben.
Welche Quelle passt zu welchem Ingestion-Pfad?
Die Ladearchitektur lässt sich als Zuordnung von Quellklassen zu standardisierten Ladewegen darstellen. Auf der einen Achse stehen die Quell-Klassen, auf der anderen Achse die nativen Pfade plus Sonderfälle. Jede Quelle sollte einem primären Ladeweg eindeutig zugeordnet werden.
| Quell-Klasse | Beispiel | Empfohlener Pfad | Verzögerung | Schema-Evolution | Nachladen historischer Daten |
|---|---|---|---|---|---|
| Cloud-Files | Partner-CSV auf S3, SaaS-Export nach ADLS | Auto Loader | Minuten bis kontinuierlich | im Konnektor konfiguriert | über Pfad und Trigger steuerbar |
| SaaS-APIs | Salesforce, Workday, ServiceNow | Lakeflow Connect | Minuten | im Konnektor verwaltet | über Konnektor-Initial-Load |
| OLTP-CDC | SAP HANA, Oracle, SQL Server, Postgres | Lakeflow Connect | Sekunden bis Minuten | im Konnektor verwaltet | über Initial-Snapshot plus Log |
| Event-Streams (einfach) | Klick-Events, App-Telemetrie, kleine IoT-Setups | Zerobus Ingest | Sub-Sekunden | über Tabellen-Schema | aus dem Quell-System |
| Event-Streams (komplex) | bestehende Kafka-Landschaft, mehrere Consumer | Structured Streaming gegen Kafka | Sub-Sekunden | manuell im Job | aus dem Broker |
| File-Backfill / einmalige Loads | Initial-Migration, manueller Refresh | COPY INTO | einmalig | manuell | manuell |
| Quelle bleibt extern | Drittsystem mit niedriger Abfragefrequenz | Lakehouse Federation | live (Query-Zeit) | n.a. | n.a. |
| Geteilte Daten (extern) | Partner- oder Konzern-Datasets über einen Share | Delta Sharing | live bis nach Share-Aktualisierung | vom Anbieter verwaltet | über den Share verfügbar |
| SAP Business Data Cloud | SAP-Datenprodukte aus S/4HANA, Datasphere | BDC Connect (Delta-Sharing-basiert) | nahezu live | im Datenprodukt verwaltet | über das geteilte Datenprodukt |
Für die Zuordnung sind insbesondere folgende Kriterien relevant: Verzögerung der Verfügbarkeit, Verhalten bei Schema-Drift, Backfill-Fähigkeit, Verfügbarkeit eines Konnektors und das Betriebsmodell. Eine ungeeignete Zuordnung führt häufig zu zusätzlichen Exporten, Zwischenformaten oder manueller Logik, beispielsweise CDC durch regelmäßige vollständige Dateiexporte nachzubilden, weil die Konnektor-Frage nicht gestellt wurde.
Fivetran, Airbyte, ADF oder native Databricks Ingestion?
Die Frage „brauchen wir Fivetran, wenn wir Databricks haben" gehört in jeden Architektur-Workshop. Ob ein externes Tool erforderlich ist, hängt von der konkreten Quelle und den bestehenden Rahmenbedingungen ab. Entscheidend sind Konnektorverfügbarkeit, bestehende Verträge und Migrationsaufwand.
Fivetran, Airbyte und vergleichbare Managed-ELT-Tools sind als gezielt eingesetzte Ergänzung in drei Fällen sinnvoll:
Spezial-Konnektor
Eine Nischen-Quelle, die Fivetran als verwalteten Konnektor hat und Lakeflow Connect nicht, kann über den vorhandenen Konnektor schneller und risikoärmer angebunden werden als über eine Eigenentwicklung.
Laufender Vertrag
Läuft Fivetran bereits stabil mit zwei Jahren Restlaufzeit, muss eine Migration wirtschaftlich gegen Restlaufzeit und bestehende Betriebskosten abgewogen werden. Vertragliche Rahmenbedingungen beeinflussen den möglichen Umsetzungszeitpunkt.
Konsolidierungs-Brücke
In einem Plattform-Wechsel kann Fivetran als Brücke dienen, bis die nativen Pfade aufgebaut sind und die Strecken nacheinander umgezogen werden.
Kafka sollte separat betrachtet werden. Eine bestehende Kafka-Plattform übernimmt häufig eine übergreifende Event-Verteilungsfunktion und ist nicht lediglich ein Ingestion-Werkzeug; Databricks hängt dann als ein Consumer dran, über Structured Streaming oder Lakeflow Declarative Pipelines. Für wenige ausschließlich nach Databricks gerichtete Eventquellen kann der Aufbau einer neuen Kafka-Plattform unverhältnismäßig aufwendig sein. Für genau diesen Fall ist Zerobus Ingest die direktere Antwort.
Azure Data Factory und AWS Glue sind die Cloud-eigenen ETL-Engines. Sie passen dort, wo eine Cloud-Pipeline-Logik bereits etabliert ist und einzelne Strecken in das Lakehouse führen sollen, ohne dass ein zweites Werkzeug aufgebaut wird. Werden sie ohne klaren Grund parallel zu den nativen Databricks-Diensten als Standard eingesetzt, entstehen zusätzliche Betriebs- und Governance-Strukturen.
Entscheidend sind weniger einzelne Produktfunktionen als die Auswirkungen auf Betrieb, Governance und Verantwortlichkeiten.
Unity Catalog, Monitoring, Backfill und Ownership
Die nativen Ladewege lassen sich in ein gemeinsames Governance- und Betriebsmodell integrieren. Unity Catalog liegt über allen Bronze-Tabellen, unabhängig davon, über welchen Ladeweg die Daten aufgenommen wurden: gleiche Berechtigungen, gleiche Tags, gleiche Lineage, gleiches Audit-Log. Eine Pipeline, die über Lakeflow Connect läuft, kann im Katalog nach denselben Berechtigungs-, Klassifizierungs- und Auditregeln verwaltet werden wie eine Auto-Loader-Strecke und eine Zerobus-Tabelle.
Der wesentliche Vorteil liegt in der einheitlichen Verwaltung über mehrere Quelltypen hinweg. Eine Plattform mit Fivetran für Salesforce, ADF für SQL Server und Kafka für Events trägt drei getrennte Berechtigungs-Modelle, drei getrennte Lineage-Quellen und drei getrennte Audit-Konzepte. Selbst wenn jede einzelne Strecke sauber läuft: Die Governance muss sonst über mehrere voneinander getrennte Systeme hinweg umgesetzt werden.
Für jeden standardisierten Ladeweg sollte ein eigenes Betriebsmodell definiert werden. Pro Lade-Pfad gibt es einen Eigentümer für die Konfiguration, einen einheitlichen Monitoring-Standard, ein definiertes Verhalten bei Quell-Ausfall und eine Backfill-Strategie. Vier Punkte gehören in jede Pfad-Definition:
Eigentümer der Pfad-Klasse
Ein Team verantwortet alle Lakeflow-Connect-Pipelines, ein anderes alle Auto-Loader-Strecken. Für jede Ladewegklasse sollte eine eindeutige operative Verantwortung bestehen.
Monitoring-Standard
Gleiche Metriken über alle Strecken einer Pfad-Klasse: Verzögerung, Erfolgsquote, verarbeitete Datenmenge, Schema-Änderungen.
Fehler-Verhalten
Definiertes Vorgehen bei Quell-Ausfall, definierte Eskalation, festgelegtes Verhalten der Bronze-Tabelle bei fehlenden oder verspäteten Quelldaten.
Backfill-Strategie
Die Backfill-Strategie sollte vor der Produktivsetzung festgelegt und getestet werden.
Diese vier Punkte sind die operative Grundlage dafür, dass Ingestion in einer wachsenden Plattform betreibbar bleibt. Ohne diese Standards muss für jede neue Quelle erneut über Betrieb, Fehlerbehandlung und historische Daten entschieden werden.
Migration bestehender Ingestion-Strecken auf native Databricks Pfade
Die meisten Plattformen verfügen bereits über produktive Ingestion-Strecken. Die häufigere Frage lautet: Wie lassen sich bestehende Pipelines aus Fivetran, ADF, Eigenbau-Spark-Jobs oder einem alten Kafka-Setup schrittweise auf die standardisierten Ladewege überführen?
Ein schrittweises Vorgehen kann in vier Phasen erfolgen. Dadurch muss nicht die gesamte Ingestion-Landschaft gleichzeitig migriert werden.
Bestandsaufnahme
Jede laufende Strecke wird einer der vier Quell-Klassen zugeordnet, das aktuelle Tool wird notiert, Verzögerung, Schema-Verhalten und Backfill-Erfahrung werden dokumentiert. Das Ergebnis ist ein strukturiertes Inventar aller bestehenden Strecken: Quelle, Klasse, aktuelles Tool, vorgeschlagener nativer Pfad, geschätzter Aufwand.
Kandidaten priorisieren
SaaS-Quellen über Fivetran, die in Lakeflow Connect verfügbar sind, sind häufig geeignete Kandidaten für eine frühe Migrationswelle. OLTP-CDC-Strecken folgen, sobald Lakeflow Connect den jeweiligen Datenbank-Typ unterstützt. Eigenbau-Spark-Jobs für Cloud-Files sind sehr oft Auto-Loader-Kandidaten. Bestehende Kafka-Strecken sollten beibehalten werden, wenn weitere Konsumenten oder zentrale Event-Funktionen davon abhängen. Ein Wechsel zu Zerobus ist vor allem dann sinnvoll, wenn Databricks der einzige relevante Konsument ist.
Paralleler Umzug
Alte und neue Pipeline laufen gleichzeitig, die Daten werden in zwei Bronze-Tabellen geschrieben und fachlich und technisch miteinander verglichen. Die bestehende Pipeline sollte erst abgeschaltet werden, wenn die neue Strecke über einen definierten Zeitraum validierte Ergebnisse liefert.
Lizenz konsolidieren
Erst wenn alle Strecken eines externen Tools umgezogen sind, wird der Vertrag gekündigt oder reduziert. Eine vorzeitige Vertragskündigung kann andernfalls zu fehlenden oder unterbrochenen Ladeprozessen führen.
Was die Lade-Architektur nicht löst
Die Matrix legt fest, wie Quelldaten zuverlässig in die Bronze-Schicht gelangen. Transformation, Modellierung und Orchestrierung sind davon getrennte Architekturaufgaben.
Die Transformation von Bronze über Silver nach Gold ist ein eigenes Architektur-Thema. Welche Tabellen modelliert werden, wie Datenqualität geprüft wird, wie Tests in die Pipelines kommen, welche Materialisierungs-Strategie für Aggregate gilt: Diese Entscheidungen müssen in der Transformationsarchitektur getroffen werden, etwa im Überblick zu Declarative Pipelines auf Databricks. Die Ingestion-Architektur schafft eine verlässliche Grundlage für die nachgelagerten Schichten.
Auch die zeitliche und technische Orchestrierung wird durch den Ladeweg allein nicht geregelt. Wann eine Pipeline läuft, welche Pipelines voneinander abhängen, wie ein Backfill koordiniert wird über mehrere Strecken hinweg: Diese Verantwortung liegt bei der übergeordneten Job- und Workflow-Steuerung, etwa über Lakeflow Jobs.
Die Governance über alle Schichten hinweg läuft über Unity Catalog. Wie Unity Catalog Berechtigungen, Lineage und Auditierbarkeit über Bronze, Silver und Gold trägt, klären wir im Überblick zu Unity Catalog.
Grenzen der Data Ingestion auf Databricks
Die Einteilung in drei native Hauptpfade ist ein bewusst vereinfachtes Architekturmodell. Sie funktioniert für die meisten Mittelstands- und Enterprise-Plattformen. Für bestimmte Quellen und Anforderungen sind jedoch zusätzliche Lösungen erforderlich.
Konnektor-Lücken in Lakeflow Connect
Die Konnektor-Liste wächst, deckt aber nicht jede SaaS-Anwendung ab. Für nicht unterstützte Quellen muss zwischen Eigenentwicklung, externem Konnektor und bewusster Nichtanbindung entschieden werden.
Kürzere Betriebshistorie bei Zerobus
Für unkritische Telemetrie ist das tragbar. Bei geschäftskritischen oder regulierten Ereignissen sollte der Ansatz sorgfältig gegen etablierte Broker-Architekturen geprüft werden.
Schemaänderungen ohne automatische Auflösung
Auto Loader und Lakeflow Connect bieten Modi für Schema-Drift, aber jede Strategie hat Trade-offs: zusätzliche Spalten ignorieren, automatisch ergänzen, Pipeline anhalten und manuell freigeben.
Historische Nachladungen pro Ladeweg
Lakeflow Connect hat Initial-Load-Mechanismen, Auto Loader kann gezielt Pfade neu lesen, Zerobus braucht eine eigene Backfill-Strategie aus dem Quellsystem. Das gehört in jede Pfad-Definition vor dem ersten Produktiv-Lauf.
Mehrere Migrationswellen bei Werkzeug-Ablösung
Eine Konsolidierung von Fivetran oder ADF braucht Monate, manchmal Jahre, weil parallele Strecken stabilisiert und vertraglich aufgeräumt werden müssen.
Nicht jede Quelle muss repliziert werden
Lakehouse Federation ist die Antwort, wenn eine Quelle bewusst extern bleibt. Eine Plattform, die ohne konkreten Nutzungsbedarf jede Quelle übernimmt, erzeugt zusätzliche Datenkopien und dauerhaften Synchronisationsaufwand.
Fazit
Eine verbindliche Lade-Matrix wird sinnvoll, sobald mehrere unterschiedliche Quelltypen dauerhaft betrieben werden, und sobald weitere Quellen und Teams hinzukommen.
Entsteht andernfalls schrittweise eine uneinheitliche und schwer wartbare Ingestion-Landschaft.
Besonders relevant wird die Matrix für Plattformen, die gerade aus der Pilotphase in den Regelbetrieb wechseln, für gewachsene Landschaften mit fünf bis zehn unterschiedlichen Lade-Wegen und für Konsolidierungs-Projekte, in denen externe Tools nacheinander abgelöst werden sollen. Drei Anzeichen sprechen für eine Standardisierung der Ladewege:
- mehrere Teams betreiben jeweils eigene Lade-Strecken mit eigenem Logging
- für jede neue Quelle wird ohne übergreifenden Standard erneut ein Werkzeug ausgewählt
- Backfill und Schema-Drift sind in jeder Strecke anders gelöst
Bei einer einzelnen Quelle ist zunächst eine robuste erste Pipeline wichtiger als ein umfassendes Zielmodell. Sind die relevanten Quellklassen bereits über klar definierte native Wege abgedeckt und bleibt nur eine Konnektor-Lücke, ist die Matrix bereits da. Eine grundlegende Neugestaltung ist nicht erforderlich.
Eine Ladearchitektur besteht nicht nur aus einzelnen technischen Pipelines. Sie definiert wenige standardisierte Ladewege, auf denen gemeinsame Regeln für Governance, Betrieb und Datenqualität aufbauen.
Die zulässigen Ladewege und ihre Einsatzbereiche sollten verbindlich dokumentiert werden, schreibt sie auf eine Seite, nehmt Auto Loader, Lakeflow Connect und Zerobus als Default. Für jeden externen Ladeweg sollte ein nachvollziehbarer technischer oder wirtschaftlicher Grund dokumentiert werden. Eine neue Quelle kann anschließend anhand definierter Kriterien einem bestehenden Ladeweg zugeordnet werden.
FAQ
Data Ingestion auf Databricks bezeichnet das Laden roher Daten aus Quellsystemen in Bronze-Tabellen in Delta Lake. Drei native Pfade decken die wesentlichen Quell-Klassen ab: Auto Loader für Cloud-Files, Lakeflow Connect für SaaS-Anwendungen und OLTP-CDC, Zerobus Ingest für Low-Latency-Events. Transformation passiert nach dem Laden in den Silver- und Gold-Schichten der Medallion-Architektur.
