Lakeflow Connect auf Databricks: SaaS- und CDC-Daten verwaltet laden
Wann Lakeflow Connect Databricks für Salesforce, SQL Server CDC und Managed Ingestion passt, und wann Fivetran oder Eigenbau sinnvoller sind.
Die Kernaussagen auf einen Blick.
- Lakeflow Connect stellt verwaltete Konnektoren für SaaS-Anwendungen und Datenbanken direkt in Databricks bereit: SaaS-Quellen wie Salesforce, Workday, ServiceNow und Datenbank-CDC für SQL Server, Oracle, Postgres und MySQL. Daten aus SaaS-Quellen und Datenbank-CDC landen direkt in Unity Catalog.
- Funktionsumfang und Reifegrad unterscheiden sich je nach Quelle; Salesforce, Workday und SQL Server sind allgemein verfügbar, andere Quellen sind Public Preview, weniger verbreitete SaaS-Quellen fehlen teilweise noch.
- Gegenüber Fivetran punktet Lakeflow Connect vor allem durch die direkte Integration in Unity Catalog und bei der Konsolidierung der Lizenzlandschaft. Der noch kleinere Konnektorkatalog bleibt aber ein wichtiger Nachteil, weil Long-Tail-Quellen und Spezialdatenbanken fehlen. Für nicht unterstützte Quellen können externe Werkzeuge weiterhin die sinnvollere Lösung sein.
- Mein Vorschlag: zuerst die eigene Quellenliste mit dem aktuellen Lakeflow-Connect-Katalog abgleichen und Lakeflow Connect dort einsetzen, wo der Konnektor reif genug ist und der Governance-Vorteil zählt. Die Zuordnung regelmäßig nachziehen, da der Katalog laufend wächst.
Inhaltsverzeichnis
Zeit, die Konnektorstrategie neu zu denken
In vielen Plattformprogrammen treffen gerade mehrere Anforderungen gleichzeitig aufeinander: Weitere Workloads ziehen ohnehin gerade auf Databricks um, und die Ingestion soll nicht das letzte Werkzeug außerhalb der Plattform bleiben. Zusätzlich soll künftig eine SQL-Server-Datenbank per CDC angebunden werden. Das Vertriebsreporting soll künftig nicht mehr vollständig am alten Data Warehouse hängen. Und Salesforce-Daten, die heute über einen selbst gebauten REST-Export alle vier Stunden in einem S3-Bucket landen, sollen künftig strukturiert und mit nachvollziehbarer Herkunft in Bronze geladen werden. Damit müssen mehrere Ladewege gleichzeitig bewertet werden.
Eine ähnliche Situation entsteht in vielen gewachsenen Datenplattformen, die ihre Ingestion-Landschaft konsolidieren wollen. Fivetran wird häufig eingesetzt, weil sich Standardquellen damit schnell anbinden lassen: Salesforce-, HubSpot- und Workday-Daten schnell produktiv. Mit mehr Quellen und höherem Datenvolumen steigen jedoch oft auch die laufenden Kosten. Dazu kommt der Wunsch nach durchgängiger Governance, die externe Tools oft nur teilweise abdecken: wer auf welche Tabellen und Daten zugegriffen hat, welche Spalte aus welcher Quelle kommt, welche Pipeline wohin schreibt. Lineage, Berechtigungen und Auditierung sollten möglichst zentral verwaltet werden. Sie sollten nicht über mehrere Tools, Repositories und Berechtigungsmodelle verteilt sein.
Lakeflow Connect holt verwaltete Ingestion stärker in die Databricks-Plattform. Die Idee dahinter ist klar: ein verwalteter Ingestion-Ansatz ähnlich wie bei Fivetran, ohne zusätzliche Konnektorplattform, mit Tabellen direkt in Unity Catalog und mit Databricks-verwaltetem Compute innerhalb der bestehenden Plattform. Die Entscheidung sollte nicht pauschal für oder gegen Lakeflow Connect fallen. Jede Quelle sollte einzeln bewertet werden, wann Lakeflow Connect geeignet ist und welche Strecken weiterhin extern betrieben werden.
Was ist Lakeflow Connect auf Databricks?
Lakeflow Connect ist die Konnektor-Komponente im Lakeflow-Stack, neben Lakeflow Declarative Pipelines (Transformation) und Lakeflow Jobs (Orchestrierung). Technisch bedeutet das: Eine von Databricks verwaltete Pipeline liest die Daten aus einer SaaS-Anwendung oder einer transaktionalen Datenbank und lädt sie in eine Bronze-Tabelle, die direkt in Unity Catalog verwaltet wird. Die Pipeline wird auf von Databricks verwaltetem Compute ausgeführt. Das Plattformteam muss dafür keinen eigenen Cluster aufsetzen und betreiben. Databricks beschreibt Lakeflow Connect als verwalteten Ingestion-Pfad ins Lakehouse, bei dem Salesforce, Workday und SQL Server allgemein verfügbar sind.
Vier Quellsystem-Kategorien fließen dabei in dieselbe Databricks Data Intelligence Platform: On-Premises-Datenbanken, Cloud-Datenbanken, Cloud-Storage und SaaS-Anwendungen. Lakeflow Connect übernimmt die verwaltete Anbindung dieser Quellen; die Plattform selbst bedient von dort aus GenAI & RAG, Data Science, Streaming-Analytics, BI & Reporting und Data Sharing, durchgängig getragen von zwei Fundament-Schichten: Unified Governance und Compute & Storage.
Dass die CDC-Funktionen schon vergleichsweise reif sind, liegt an ihrer Herkunft. Die Datenbank-CDC-Engine stammt aus der Übernahme von Arcion durch Databricks im Jahr 2023. Arcion war vorher ein eigenständiger CDC-Anbieter mit logbasierter Replikation für SQL Server, Oracle, Postgres und MySQL. Die Technologie ist inzwischen in Lakeflow Connect integriert und schreibt CDC-Streams in Delta-Bronze, mit Schema-Behandlung und Zeitplan. Eine zusätzliche CDC-Plattform muss dadurch nicht separat betrieben werden.
Aus Plattform-Sicht ist Lakeflow Connect ein verwalteter Ladeweg direkt nach Unity Catalog. Lakeflow Connect ist aber kein allgemeines ETL-Framework und keine Lösung für beliebige APIs. Im Vergleich zu externen Managed-ELT-Tools entsteht ein klarer Trade-off: Die direkte Integration in Unity Catalog reduziert Governance- und Betriebsaufwand. Dafür ist die Auswahl unterstützter Quellen derzeit kleiner als bei etablierten Konnektorplattformen. Microsoft Learn dokumentiert die verwalteten Connectors für Azure Databricks im selben Pflegestand wie die AWS-Dokumentation.
Welche Ladewege es daneben gibt und wann welcher passt, ordnen wir im Überblick zu Ingestion-Mustern auf Databricks ein.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
SaaS-Quellen und Database CDC
Lakeflow Connect deckt zwei unterschiedliche Arten der Datenanbindung ab. Diese beiden Familien sollten getrennt bewertet werden, da sich Einrichtung, Betrieb und Produktreife unterscheiden.
SaaS-Connectoren. Salesforce, Workday, ServiceNow, Google Analytics, Marketo und weitere SaaS-Quellen sind als Managed-Pipelines verfügbar. Die Pipeline greift mit hinterlegter Authentifizierung auf die API der SaaS-Anwendung zu, liest die ausgewählten Objekte aus (Account, Opportunity, Worker, Incident) und schreibt sie nach Schedule in Bronze-Tabellen. Schema-Erweiterungen in der Quelle werden in den meisten Fällen automatisch übernommen. Der Setup-Aufwand pro Quelle liegt bei der Authentifizierung und der Auswahl der relevanten Objekte. Der zusätzliche Aufwand für Zeitplan und Ausführung bleibt meist überschaubar.
Database CDC. SQL Server, Oracle, Postgres und MySQL nutzen die aus Arcion hervorgegangene CDC-Engine. Log-basierte Replikation aus dem Transaction-Log der Quell-Datenbank überträgt Inserts, Updates und Deletes fortlaufend nach Bronze. So werden echte Änderungen verarbeitet, nicht regelmäßig komplette Datenstände kopiert. Dadurch sind deutlich kürzere Aktualisierungsintervalle möglich und die Last auf der Quelldatenbank bleibt vergleichsweise niedrig.
| Achse | SaaS-Connectoren | Database CDC |
|---|---|---|
| Quelle | REST/SOAP-APIs von SaaS-Anwendungen | OLTP-Datenbanken über Transaction-Log |
| Mechanik | periodischer API-Abruf pro Objekt | logbasierte Änderungsreplikation |
| Latenz | Minuten bis Stunden je Schedule | wenige Minuten |
| Engine | quellspezifische Konnektorlogik | Arcion-Engine im Backend |
| Quell-Last | API-Quotas, Rate-Limits | CDC-Reader auf dem Log, geringe Zusatzlast |
| Schema-Drift | Automatische Übernahme | Schema-Evolution mit Erkennung von DDL-Änderungen |
Die praktische Konsequenz: SaaS-Quellen sind in der Regel vergleichsweise einfach im Setup, da im Wesentlichen Authentifizierung, Objektauswahl und Zeitplan konfiguriert werden. Database CDC braucht dagegen mehr technische Vorbereitung: Netzwerkpfad zur Quelldatenbank, CDC-Konfiguration auf der Quelle und das Verständnis, dass CDC als Teil der Quellarchitektur und des Datenbankbetriebs eingeplant werden muss. Im Gegenzug stehen zeitnähere und granularere Änderungsdaten zur Verfügung, weil Bronze aus realen Änderungen besteht statt aus periodischen Snapshots.
Salesforce, Workday, SQL Server und Public Preview
Der verfügbare Konnektorkatalog wächst laufend. Die folgende Übersicht ist eine Momentaufnahme und sollte vor jeder Entscheidung mit der aktuellen Lakeflow-Connect-Dokumentation für Managed Connectors abgeglichen werden, weil sich Produktstatus, Regionen und Cloud-Unterstützung ändern können.
| Quelle | Familie | Produktstatus | Anmerkung |
|---|---|---|---|
| Salesforce | SaaS | Generally Available | Standard- und Custom-Objekte, Schedule pro Pipeline |
| Workday | SaaS | Generally Available | Reports-as-a-Service und ausgewählte Domänen |
| SQL Server (CDC) | Database CDC | Generally Available | logbasiert, Ingestion-Gateway pro Quellumgebung |
| ServiceNow | SaaS | Public Preview | typische ITSM-Tabellen mit Schema-Mapping |
| Google Analytics | SaaS | Public Preview | GA4-Datenmodell |
| Marketo | SaaS | Public Preview | Activity-Streams und Lead-Daten |
| SharePoint | SaaS | Public Preview | Listen und Dokument-Metadaten |
| PostgreSQL (CDC) | Database CDC | Public Preview | log-basiert, ähnliche Mechanik wie SQL Server |
| MySQL (CDC) | Database CDC | Public Preview | binlog-basiert |
| Oracle (CDC) | Database CDC | Public Preview | Redo-Log-basiert, mit höherem Konfigurationsaufwand |
| SAP | SaaS | eigener Integrationsweg | SAP Databricks Connect und OData-Pfad, eigener Vertragsrahmen |
| weniger verbreitete SaaS-Quellen (Stripe, Intercom, …) | SaaS | nicht im Katalog enthalten | nicht gelistet, derzeit kein nativer Konnektor verfügbar |
Die Liste kann sich von Quartal zu Quartal ändern. Konnektoren, die heute noch in Preview sind, werden Schritt für Schritt allgemein verfügbar, und neue SaaS-Quellen kommen laufend dazu. Der jeweilige Produktstatus sollte deshalb zum geplanten Migrationszeitpunkt erneut geprüft werden. Entscheidend ist, ob ein Konnektor zum benötigten Zeitpunkt mit dem erforderlichen Supportniveau verfügbar ist.
Neben den von Databricks verwalteten Konnektoren gibt es seit Kurzem Community Connectors: quelloffene Konnektoren für Quellen ohne Managed-Support, gebaut und gepflegt von der Community statt von Databricks. Technisch implementieren sie das LakeflowConnect-Interface über die Spark Python Data Source API; der Konnektor-Code wird aus einem GitHub-Repository in den Workspace geklont und zur Laufzeit von einer Lakeflow-Pipeline ausgeführt. Eine nicht gelistete Quelle lässt sich mit den Templates im Lakeflow-Community-Connectors-Repository auch selbst als Konnektor bauen.
Beta-Status
Das Feature ist Beta und braucht eine Admin-Freischaltung über die Previews-Seite, bevor es im Workspace nutzbar ist.
Keine SLA-Garantie
Databricks gibt weder SLA noch Forward-Compatibility-Zusagen für Community Connectors.
Betrieb bleibt Eigenleistung
Pflege, Updates und Betrieb des Konnektor-Codes bleiben vollständig beim eigenen Team.
Damit sind Community Connectors ein Mittelweg zwischen Managed Connector und vollem Eigenbau: eine Option für Long-Tail-Quellen, aber mit dem Reife- und Betriebsprofil eines Community-Projekts statt eines verwalteten Dienstes.
Wann passt Lakeflow Connect?
Für jede Quelle sollten drei Kriterien geprüft werden: Reifegrad des Konnektors, Governance-Vorteil und Kostenlogik. Sprechen alle drei Punkte dafür, ist Lakeflow Connect meist die naheliegende Lösung. Gibt es dagegen klare Einschränkungen bei einem dieser Kriterien, bleibt ein externes Tool die bewusst gewählte Alternative.
Lakeflow Connect wählen, wenn
- Salesforce mit Standard- und Custom-Objekten angebunden wird: Konnektor ist allgemein verfügbar und die Governance-Relevanz für Vertriebsdaten ist hoch
- eine bestehende Fivetran-Strecke für Salesforce, Workday oder ServiceNow konsolidiert werden soll
- SQL-Server-CDC ansteht und keine separate CDC-Plattform neben Databricks betrieben werden soll: die Arcion-Engine übernimmt die log-basierte Replikation
- Workday oder ServiceNow im Scope sind und eine Public-Preview-Reife für nicht-kritische Pipelines akzeptabel ist
Externes Tool wählen, wenn
- die Quelle Stripe, Intercom oder ein internes System ohne nativen Konnektor ist
- SAP-Daten angebunden werden sollen: dafür ist der dedizierte SAP-Databricks-Connect-Pfad oder OData vorgesehen, nicht Lakeflow Connect
- ein Preview-Konnektor für die eigene Kritikalität nicht ausreicht, weil volle SLA-Garantien fehlen
Ein konkretes Beispiel macht den Governance-Vorteil greifbar: Salesforce Sales Cloud läuft über Lakeflow Connect in die Medallion-Architektur ein, durchläuft Bronze, Silver und Gold und speist von dort Machine Learning und GenAI (MosaicML, MLflow). Am Ende steht ein Intelligent Churn Agent, der Kündigungswahrscheinlichkeit, wertvolle Kunden und passende Retention-Maßnahmen bestimmt, mit Governance, Observability und Multicloud-Fähigkeit (Unity Catalog, Iceberg, Delta Lake, Parquet) als durchgängigem Fundament.
Governance, Kosten und Konnektor-Breite im Vergleich
Damit geht es nicht nur darum, ob ein Konnektor existiert, sondern welches Werkzeug für die jeweilige Quelle besser passt. Die folgende Übersicht stellt Lakeflow Connect, Fivetran und Eigenbau entlang der Kriterien gegenüber, die für die Entscheidung wirklich relevant sind.
| Achse | Lakeflow Connect | Fivetran | Eigenbau |
|---|---|---|---|
| Konnektorbreite | wachsend, Long-Tail teilweise fehlend | breit, inklusive vieler Long-Tail-SaaS-Quellen | beliebig, aber mit Engineering-Aufwand je Quelle |
| Lizenz-Modell | DBU-basiert, kein separater Vertrag | zeilenbasiert, separater Vertrag | nur Cloud- und Engineering-Kosten |
| Governance-Bindung | nativ in Unity Catalog | Catalog-Synchronisation notwendig | manuell, häufig uneinheitlich |
| Lock-in | hoch zum Databricks-Stack | mittel, exportierbar | gering, aber Wartungslast |
| Setup-Aufwand pro Quelle | niedrig (SaaS) bis mittel (CDC) | niedrig | mittel bis hoch |
| Reife | gemischt (allgemein verfügbar / Preview) | hoch über alle Konnektoren | hängt vom eigenen Team ab |
Der Vergleich zwischen Lakeflow Connect und Fivetran entscheidet sich vor allem an drei Punkten Konnektor-Reife, Governance-Wert und bestehende Lizenzkosten und Vertragsbedingungen. Die reine Verfügbarkeit eines Konnektors reicht als Entscheidungsgrundlage nicht aus. Bei produktionsreifen Konnektoren und hohen Governance-Anforderungen bietet Lakeflow Connect häufig den größten Nutzen. Für Long-Tail-SaaS und Spezialdatenbanken bleibt ein externes Tool oft die bessere Wahl.
Was kostet Lakeflow Connect?
Die beiden Produkte rechnen sehr unterschiedlich ab. Ein fairer Kostenvergleich braucht deshalb echte Mengen, Änderungsraten und Laufzeiten.
Fivetran rechnet nach aktiven Zeilen pro Monat ab. Bei 50 Millionen Salesforce-Sätzen pro Monat hängen die Kosten vor allem an den monatlich aktiven Datensätzen und nicht an der tatsächlichen Laufzeit einzelner Pipelines. Der Preis ist vorhersehbar, skaliert aber linear mit der Datenmenge. Fivetran beschreibt das eigene Modell als verbrauchsbasiertes Pricing pro aktiver Zeile mit Volumenrabatten ab höheren Stufen.
Lakeflow Connect rechnet über Databricks Units ab. Die verwalteten Pipelines verbrauchen DBUs während der Ingestion-Laufzeit; der Verbrauch hängt am Daten-Volumen, an der Abruffrequenz und an der Komplexität der Schema-Behandlung. Databricks listet die DBU-Tarife für Lakeflow Connect auf der Pricing-Seite und unterscheidet dort SaaS-Connectoren und Database-CDC mit jeweils eigenen Tarifen. Eine separate Konnektorlizenz entfällt. Die Kosten werden über die bestehende Databricks- und Cloud-Abrechnung erfasst.
Welches Modell günstiger ist, hängt von Datenvolumen, Änderungsrate und Ausführungsfrequenz ab. Viele Quellen mit geringem Daten- und Änderungsvolumen sind im DBU-Modell oft günstiger, weil die Polling-DBUs für kleine Datasets gering sind. Wenige sehr große Quellen mit hohem Zeilen-Volumen können dagegen im nutzungsabhängigen DBU-Modell höhere Kosten verursachen als in einem zeilenbasierten Tarif, je nach Cloud-Provider und Schedule. Konkrete Zahlen lassen sich ohne Lastprofil kaum seriös berechnen. Die Preisstruktur ist nur die Grundlage für eine eigene Kalkulation und ersetzt keinen pauschalen Vergleich.
Ein weiterer Vorteil liegt im organisatorischen Aufwand: Lakeflow Connect spart den separaten Fivetran-Vertrag mit Beschaffung, Verlängerung und Lieferantenprüfung. In Cloud-affinen Organisationen sollte dieser reduzierte Verwaltungsaufwand ebenfalls in die Gesamtbetrachtung einfließen.
Warum Lakeflow Connect bei Lineage und Audit stark ist
Ein wichtiger Vorteil von Lakeflow Connect wird in reinen Konnektorvergleichen oft unterschätzt: die direkte Integration in Unity Catalog. Tabellen, die durch eine Lakeflow-Pipeline geschrieben werden, sind von Beginn an regulär verwaltete Unity-Catalog-Objekte: Mit Berechtigungen, mit Lineage zurück bis zur Pipeline-Definition, mit Tags und Audit-Logs.
Wie die Catalog-Schicht im Plattform-Stack greift, klären wir im Überblick zu Unity Catalog auf Databricks.
Lakeflow Connect, Auto Loader und Zerobus: Welcher Ingestion-Pfad passt wann?
Lakeflow Connect deckt bestimmte Quelltypen ab, aber nicht alle. Im Lakeflow-Stack gibt es drei klar getrennte Ladewege. Jeder Ladeweg passt zu einem anderen Quellen- und Latenzprofil.
Lakeflow Connect
Passt zu SaaS-Quellen über API und zu Datenbank-CDC über Transaction Logs, für unterstützte SaaS-Anwendungen und relationale Datenbanken mit CDC-Fähigkeit.
Auto Loader
Übernimmt die inkrementelle Verarbeitung von Dateien aus Cloud-Speichern (S3, ADLS, GCS) mit Exactly-Once-Semantik und Schema-Evolution.
Zerobus
Passt zu Low-Latency-Events im Sekundenbereich oder darunter, besser geeignet als ein periodisch arbeitender Managed Connector.
Mehr zu den einzelnen Pfaden: Auto Loader auf Databricks und Zerobus-Ingest auf Databricks.
Eine bestehende Structured-Streaming-Pipeline auf Kafka oder Event Hubs bleibt ein eigener Anwendungsfall. Sie kann weiterhin sinnvoll sein, wenn bereits eine etablierte Streaming-Plattform und entsprechendes Betriebswissen vorhanden sind und die Quelle in keinen der drei verwalteten Pfade passt. Welche Lade-Strategie wann passt und wie sich die Mechanik gegen klassisches ETL verhält, klären wir im Überblick zu ETL gegen ELT auf Databricks.
Migration von Fivetran zu Lakeflow Connect: Roadmap mit Parallelbetrieb
Alle Quellen an einem festen Stichtag umzustellen ist selten sinnvoll und selten der schnellste sichere Weg. Die meisten Plattformen, die wir begleiten, setzen meist auf eine schrittweise Migration über mehrere Monate mit klaren Phasen.
Bestehende Quellen mit dem Konnektorkatalog abgleichen
Die bestehende Quell-Liste wird mit den aktuell verfügbaren Lakeflow-Connect-Konnektoren abgeglichen. Für jede Quelle entsteht eine klare Entscheidung: Generally Available, Preview akzeptabel oder nicht verfügbar (bleibt bei Fivetran oder Eigenbau). Das Ergebnis ist zunächst eine priorisierte Grundlage für die weitere Planung.
Pilotmigration für ein bis zwei Quellen
Eine Salesforce- oder SQL-Server-CDC-Pipeline wird parallel in Lakeflow Connect aufgebaut und für vier bis sechs Wochen parallel zur bestehenden Fivetran-Pipeline betrieben. Schema-Mappings, Latenzen, Datenvollständigkeit sowie Berechtigungen und Lineage in Unity Catalog werden geprüft.
Schrittweise Umstellung
Erfüllt der Pilot die fachlichen und technischen Anforderungen, werden weitere Quellen einzeln umgezogen, jeweils mit einer Übergangsphase, in der alte und neue Pipeline parallel laufen, bis das Reporting stabil auf Lakeflow Connect umgestellt ist.
Externe Lizenzen und Verträge anpassen
Erst wenn der Großteil der Quellen migriert ist, wird die Fivetran-Lizenz auf die verbleibenden Long-Tail-Quellen reduziert. Eine zu frühe Reduzierung oder Kündigung kann die Rückfalloption während der Migration einschränken.
Der Parallelbetrieb sollte von Anfang an Teil der Migrationsplanung sein. Er verursacht vorübergehend Kosten für beide Lösungen (DBU für Lakeflow plus Fivetran-Vertrag), reduziert aber das Risiko unvollständiger oder fachlich abweichender Daten, die bei einer Umstellung auf einen Schlag typisch sind: fehlende Felder in Bronze, falsche Schedules, übersehene Custom-Objekte. Geplanter Parallelbetrieb ist häufig günstiger als eine ungeplante Rückmigration nach einer fehlerhaften Umschaltung.
Was Lakeflow Connect nicht löst
Mehrere Quelltypen werden weiterhin nicht durch Lakeflow Connect abgedeckt und brauchen einen anderen Lade-Mechanismus.
Long-Tail-SaaS ohne Konnektor
Stripe, Intercom, kleinere Marketing-Tools oder interne Web-Apps ohne Standard-Konnektor sind nicht im Katalog. Es bleiben externe Konnektorplattformen, eigene API-Pipelines oder ein selbst gebauter Community Connector, mit Eigenbau-Aufwand, laufender Pflege und ohne SLA-Sicherheit.
Sub-Sekunden-Latenz
Aktualisierungsanforderungen im Sekunden- oder Subsekundenbereich passen nicht zum typischen Lakeflow-Connect-Profil. Hier trägt Zerobus oder eine direkte Event-Hub-Anbindung besser.
Nicht unterstützte oder ältere Datenbanken
DB2 auf z/OS, ältere Sybase-Instanzen oder spezialisierte In-Memory-Datenbanken liegen außerhalb der Arcion-Engine. Hier hilft ein dedizierter CDC-Connector, Debezium oder eine individuell entwickelte, snapshotbasierte Extraktion.
Wie die einzelnen Ladewege im Lakeflow-Stack zusammenspielen und wann welcher passt, zeigen wir im Überblick zu Data Engineering auf Databricks.
Grenzen von Lakeflow Connect auf Databricks
Unvollständiger Konnektorkatalog
Lakeflow Connect ist noch ein junges Produkt, die Liste ändert sich quartalsweise. Für jede Entscheidung zählt der aktuelle Stand in der Dokumentation, nicht ein älterer Roadmap-Stand.
CDC-Technologie aus Arcion-Übernahme
Die zugrunde liegende CDC-Engine hat eine längere Betriebshistorie als das Produkt Lakeflow Connect selbst und läuft heute unter dem Lakeflow-Dach mit Databricks-Support. Diese Herkunft sollte in Architektur- und Betriebsentscheidungen offen berücksichtigt werden.
Public-Preview ohne volle SLA
Preview-Konnektoren haben keine vollen SLA-Garantien und können sich in der Schema-Behandlung ändern. Für unkritische Anwendungsfälle als Übergangslösung nutzbar, für regulatorisch relevante Datenstrecken meist nicht ausreichend.
Höhere Databricks-Bindung
Eine Lakeflow-Connect-Pipeline läuft nur in Databricks. Ohne klare Databricks-Strategie bieten Fivetran oder Airbyte mehr Portabilität zwischen Zielplattformen.
Ein fünfter Punkt betrifft SAP: SAP läuft nicht über den Lakeflow-Connect-Katalog, sondern über Business Data Cloud. SAP-Daten landen nicht über einen Managed Connector im Lakehouse, sondern über SAP Business Data Cloud: Die Daten werden per Delta Sharing im Zero-Copy-Modus zwischen BDC und dem eigenen Databricks geteilt, statt physisch kopiert zu werden. Wie sich SAP-Datenprodukte konkret anbinden lassen, zeigt der Überblick zu BDC Connect. Das ist kein Nachteil von Lakeflow Connect, sondern ein eigener Pfad mit eigener Vertrags- und Betriebslogik, der separat geplant werden muss.
Diese Grenzen sprechen für eine Entscheidung pro Quelle. Quellen mit reifem Konnektor und hohem Governance-Bedarf sind gute Kandidaten für Lakeflow Connect. Für die übrigen Quellen sollte ein alternativer Ladeweg ausdrücklich dokumentiert werden.
Fazit
Lakeflow Connect ist sinnvoll für SaaS-Quellen und Datenbank-CDC mit reifem Konnektor, wenn Lineage, Berechtigungen und Audit über Unity Catalog wichtig sind.
Lakeflow Connect ist besonders sinnvoll für SaaS-Quellen und Datenbank-CDC, wenn ein passender Konnektor mit ausreichendem Reifegrad verfügbar ist und wenn Lineage, Berechtigungen und Audit über Unity Catalog wichtig sind. Besonders relevant ist das für Plattformen mit Salesforce-, Workday- und SQL-Server-CDC-Quellen, die aktuell noch über externe Ingestion-Tools angebunden sind und in eine durchgängige Catalog-Schicht migriert werden sollen. Ein zweiter Treiber ist die Reduzierung separater Konnektorplattformen und Lieferantenverträge.
Für Plattformen mit vielen weniger verbreiteten SaaS-Quellen, mit Spezial-Datenbanken oder mit einer Multi-Plattform-Strategie ohne Databricks-Festlegung bleibt ein externes Tool oft die bewusst bessere Wahl. Fivetran bleibt für zahlreiche Quellen und Plattformstrategien weiterhin eine geeignete Lösung. Beide Ansätze können in derselben Ingestion-Architektur sinnvoll nebeneinander bestehen. Entscheidend ist die richtige Zuordnung pro Quelle.
Zuerst sollte für jede bestehende und geplante Quelle geprüft werden, ob ein nativer Konnektor verfügbar ist. Lakeflow Connect dort einsetzen, wo der Konnektor allgemein verfügbar und der Governance-Hebel relevant ist. Preview-Konnektoren sollten nur genutzt werden, wenn Änderungen oder Ausfälle fachlich vertretbar sind. SAP über den dedizierten Track. Nicht unterstützte SaaS-Quellen bleiben bei externen Konnektoren oder eigenen API-Pipelines. Diese Zuordnung sollte regelmäßig überprüft werden. Das Ergebnis ist eine Ingestion-Architektur, die neue native Konnektoren schrittweise übernehmen kann, ohne bei jeder neuen Quelle die gesamte Werkzeugstrategie neu zu diskutieren.
FAQ
Lakeflow Connect ist die verwaltete Konnektorplattform innerhalb von Databricks. Eine verwaltete Pipeline lädt Daten aus einer SaaS-Anwendung (Salesforce, Workday, ServiceNow) oder einer transaktionalen Datenbank (SQL Server, Oracle, Postgres, MySQL) in eine Bronze-Tabelle, die direkt in Unity Catalog verwaltet wird. Die Pipeline läuft auf Serverless-Compute, ohne dass ein eigener Cluster betrieben werden muss, und ist im DBU-Modell abgerechnet.
