Warum Unternehmen zu Databricks migrieren - und was sie dabei lernen

Organisationen migrieren aus einem von zwei Gründen zu Databricks: Sie brauchen eine vereinte Plattform für Data Engineering und ML (statt eines zersplitterten Stacks aus unverbundenen Werkzeugen), oder sie brauchen die Ökonomie des Lakehouse (statt der teuren Doppelung aus Warehouse und Lake eine gesteuerte Schicht auf dem Objektspeicher der Cloud). Manchmal beides.

Die Migration ist nicht trivial. Sie bedeutet, Pipelines auf eine neue Plattform zu heben, Teams auf Spark und Delta Lake zu schulen und die Governance neu zu denken. Doch für Organisationen, deren Arbeitslasten Data Engineering, Analytik mit SQL und ML umfassen, rechtfertigt der Gewinn aus der Konsolidierung den Aufwand. Dieser Artikel behandelt die fünf häufigsten Treiber, wie realistische Ergebnisse aussehen und wo Migrationen stecken bleiben.

Lakes und Warehouses zusammenführen

Das ist der häufigste Treiber. Organisationen, die S3 und Redshift, ADLS und Synapse oder GCS und BigQuery neben einem getrennten Data Lake betreiben, pflegen zwei Kopien der Daten, zwei Sätze an ETL-Pipelines, zwei Rechtemodelle und zwei Qualifikationsprofile. Der Mehraufwand ist real: Ein mittelgroßes SaaS-Unternehmen kann 15 Pipelines haben, die einzig dazu da sind, Daten zwischen Lake und Warehouse zu kopieren.

Das Lakehouse von Databricks ersetzt beide durch Delta Lake auf dem Objektspeicher der Cloud. Clickstream-Daten, Transaktionsdaten und unstrukturierte Dokumente landen alle im selben Delta Lake. Entwickler bauen Transformationen in Spark, Analysten fragen mit SQL ab, und Data Scientists trainieren Modelle, alles gegen dieselben gesteuerten Tabellen. Keine Pipelines zum Kopieren, keine Verzögerungen beim Abgleich, keine widersprüchlichen Schemata.

Nehmen Sie ein SaaS-Unternehmen mit einer Architektur aus drei Systemen (roher Lake auf S3, Warehouse auf Redshift und ein getrennter Jupyter Hub für ML). Der Umzug zu Databricks beseitigt jede Pipeline, deren einzige Aufgabe das Kopieren von Daten zwischen Lake und Warehouse ist, und das nächtliche ETL muss nicht mehr in zwei Systemen fertig werden, bevor Analysten beginnen können. Die Vereinfachung betrifft nicht nur das Tempo: Sie beseitigt die Klasse von Fehlern, die dadurch entsteht, dass Daten in verschiedenen Systemen zu verschiedenen Zeiten ankommen.

ML und KI auf derselben Plattform

Alte Stacks zwingen Data Scientists, Daten aus dem Warehouse in getrennte Umgebungen für ML und KI zu exportieren, etwa SageMaker, Vertex AI, eigenständige Jupyter-Notebooks oder GPU-Server nach Bedarf. Dieser Schritt des Exports ist die Stelle, an der Dinge kaputtgehen. Trainingsdaten laufen aus dem Takt mit den produktiven Tabellen. Feature Engineering in Notebooks ist nicht reproduzierbar. Das Ausrollen eines Modells verlangt ein eigenes Betriebsteam, das es paketiert und bereitstellt.

Databricks beseitigt den Schritt des Exports. Trainingsdaten bleiben im Delta Lake. Feature Engineering läuft in derselben Spark-Umgebung, die auch die produktiven Pipelines baut. MLflow verfolgt jedes Experiment, also Parameter, Kennzahlen, Artefakte und Versionen eines Modells. Ist ein Modell reif für den Produktivbetrieb, wird es in Unity Catalog registriert und an einem Endpunkt von Model Serving bereitgestellt, ohne die Plattform zu verlassen.

Nehmen Sie ein typisches Team für Kreditrisiko bei einem Finanzdienstleister. Der Engpass auf dem Weg eines Modells in den Produktivbetrieb ist selten das Training, sondern die Übergabe zwischen Data Science und ML Engineering. Auf einem alten Stack trainieren Data Scientists Modelle in Jupyter, exportieren sie als Pickle-Dateien und reichen sie Entwicklern, die die Pipeline der Merkmale im Produktivbetrieb nachbauen. Auf Databricks können die Pipeline für das Training und die für die Bereitstellung denselben Code, dieselben Merkmale und dieselben Daten nutzen, was den Großteil dieser Übergabe beseitigt.

Leistung im großen Maßstab

Die Leistungsgewinne einer Migration kommen aus zwei Quellen: aus der Laufzeitumgebung von Databricks selbst und aus dem Wegfall der Datenbewegung.

Die Verbesserungen der Laufzeitumgebung sind greifbar. Die Photon-Engine, die native vektorisierte Abfrage-Engine von Databricks, beschleunigt Operationen in SQL und auf DataFrames. Die adaptive Ausführung von Abfragen optimiert Abfragepläne zur Laufzeit anhand der tatsächlichen Verteilung der Daten. Optimierungen in Delta Lake wie Z-Ordering (verwandte Daten liegen auf der Platte beieinander) und Data Skipping (nur relevante Dateien werden gelesen) senken die Ein- und Ausgabe bei analytischen Abfragen. Für neue Tabellen empfiehlt Databricks Liquid Clustering, das Partitionierung und Z-Ordering ersetzt.

Der größere Gewinn ist allerdings architektonisch. Wenn eine Abfrage direkt auf dem Lakehouse läuft, statt auf den Abgleich von Lake zu Warehouse zu warten, kommt das Ergebnis schneller, weil es den Schritt des Abgleichs nicht mehr gibt. Ein Händler, der nächtlich ETL fährt, um Clickstream-Daten von S3 nach Redshift zu bringen, bevor die morgendliche Analytik beginnen kann, gewinnt dieses Fenster für den Abgleich zurück: Dauert die Kopie drei Stunden, können Analysten die Daten von gestern drei Stunden früher abfragen, sobald die Pipelines fertig sind.

Ehrlich eingeordnet: Databricks ist nicht für alle Abfragen in SQL schneller als Snowflake. Snowflake ist auf SQL- und BI-Lasten mit vielen gleichzeitigen Nutzern ausgerichtet, und viele Teams empfinden es für diesen Zweck als einfacher im Betrieb. Databricks passt typischerweise besser zu komplexen mehrstufigen Transformationen, großen Joins, dem Training von Modellen und Streaming. Der Vorteil bei der Leistung hängt von der Arbeitslast ab und gilt nicht allgemein.

Kosten neu ordnen

Eine Migration zu Databricks spart nicht von selbst Geld. Teams, die sofortige Kostensenkung erwarten, werden oft enttäuscht. Die Ersparnisse kommen aus drei konkreten Mechanismen, und jeder verlangt bewusstes Handeln.

Feste Kapazität für Warehouses entfällt. Warehouse-Appliances vor Ort und Verträge mit fester Kapazität (Systeme von Teradata oder Netezza, reservierte Kapazität in Redshift) kosten dasselbe, ob sie ausgelastet sind oder nicht. Sie durch die verbrauchsbasierte Bepreisung von Databricks zu ersetzen, bringt Kosten und tatsächliche Last in Einklang. Am größten sind die Ersparnisse für Organisationen, die ihre Altsysteme überdimensioniert haben.

Automatisches Skalieren und Beenden senkt untätige Rechenzeit. Cluster in Databricks skalieren herunter, wenn Lasten fertig sind, und beenden sich, wenn sie untätig sind. Alte Infrastruktur vor Ort läuft rund um die Uhr, ob sie jemand nutzt oder nicht. Die Ersparnis ist proportional dazu, wie viel Leerlauf Ihre heutige Infrastruktur trägt. Eine Plattform mit durchschnittlich 30 % Auslastung hat erheblichen Spielraum.

Eine einzige Kopie der Daten im Objektspeicher der Cloud halten. Tabellen in Delta Lake liegen in S3, ADLS oder GCS zu den Preisen von Objektspeicher: Amazon S3 Standard kostet laut Liste 0,023 US-Dollar pro GB und Monat für die ersten 50 TB in US East (N. Virginia), Stand Oktober 2026. Verwalteter Speicher in einem Warehouse ist pro GB nicht unbedingt viel teurer (Amazon Redshift Managed Storage kostet laut Liste 0,024 US-Dollar pro GB und Monat in derselben Region), daher entsteht die größere Ersparnis dadurch, dass dieselben Daten nicht mehr doppelt gespeichert und kopiert werden.

Der Einwand: Die Bepreisung von Databricks ist komplex (DBU plus Infrastruktur der Cloud). Auf AWS Premium liegen die Listenpreise zum Beispiel bei 0,15 US-Dollar je DBU für Jobs Compute und 0,55 US-Dollar je DBU für All-Purpose Compute, und ohne aktive Optimierung, also Jobs Compute für Batch, erzwungenes automatisches Beenden und die Nutzung von Spot-Instanzen, können die Kosten die der Altsysteme übersteigen. Kosten neu zu ordnen geschieht nicht von selbst; es verlangt fortlaufende Steuerung.

Produktivität und Zusammenarbeit im Team

Der am wenigsten glamouröse Grund für eine Migration, aber einer der wirksamsten. Zersplitterte Werkzeugstapel erzeugen organisatorische Reibung, die jedes Projekt verlangsamt.

Auf einem alten Stack nutzen Data Engineers Airflow und eigene Skripte, Data Scientists Jupyter und SageMaker, Analysten SQL Server und Excel, und alle schicken einander Dateien per E-Mail. Eine neue Data Engineerin einzuarbeiten heißt, ihr vier Systeme, drei Rechtemodelle und zwei Wege des Ausrollens beizubringen. Wissen lebt auf einzelnen Laptops, nicht in gemeinsamer Infrastruktur.

Auf Databricks arbeiten alle drei Rollen im selben Workspace. Notebooks unterstützen Python, SQL, Scala und R im selben Dokument. Die Anbindung an die Versionsverwaltung sorgt dafür, dass Code in Git liegt und nicht im persönlichen Verzeichnis. Unity Catalog gibt allen Auffindbarkeit: Ein neues Teammitglied kann nach „customer_orders“ suchen und findet die kanonische Tabelle, wer sie verantwortet und was von ihr abhängt.

Bei der Einarbeitung zeigt sich das zuerst. Die Verbesserung kommt nicht von besserer Dokumentation, sondern daher, dass alles an einem Ort ist: die Daten, der Code, der Verlauf der Experimente und die Zugriffsrechte. Neue Entwickler müssen nicht lernen, wo die Dinge liegen, weil alles im selben Workspace liegt.

Wo Migrationen stecken bleiben

Dieser Abschnitt ist es, was einen realistischen Leitfaden von Werbematerial unterscheidet. Jede Migration trifft auf Reibungspunkte.

Die Lernkurve bei Spark wird unterschätzt. Teams mit tiefen Kenntnissen in SQL, aber ohne Erfahrung mit verteiltem Rechnen, stehen vor einem steilen Anstieg. Spark SQL deckt einfache Analytik ab, doch die ganze Plattform, also Orchestrierung von Pipelines, Streaming, UDFs und das Abstimmen von Clustern, verlangt Verständnis von Partitionierung, Shuffles und Speicherverwaltung. Rechnen Sie für erfahrene Entwicklerinnen in SQL mit zwei bis vier Wochen praktischer Schulung.

Eigene Optimierungen der Altplattform gehen verloren. Alte Warehouses sammeln über Jahre von Hand abgestimmte materialisierte Sichten, eigene Indizes und abfragespezifische Optimierungen an. Diese lassen sich nicht unmittelbar auf Spark übertragen. Gleichwertige Leistung verlangt neues Optimieren: die richtigen Schlüssel für das Clustering wählen (Liquid Clustering ersetzt bei neuen Tabellen Partitionierung und Z-Ordering) und Spark für bestimmte Lasten konfigurieren.

Lücken in der Governance während des Übergangs. Die Zeit zwischen dem Abschalten der alten Governance und dem vollständigen Ausrollen von Unity Catalog ist gefährlich. Wird das alte Rechtemodell abgebaut, bevor das neue bereit ist, verlieren Teams entweder den Zugang (was Arbeit blockiert) oder bekommen zu viel Zugang (ein Risiko für die Compliance). Lassen Sie die Systeme der Governance während des Übergangs parallel laufen.

Die Falle des reinen Umzugs. Schlechte Pipelines unverändert auf eine neue Plattform zu heben, ergibt schlechte Pipelines auf einer neuen Plattform. Eine Migration ist eine Gelegenheit, aufzuräumen, doch Teams unter Termindruck überspringen das Aufräumen und enden mit Spark-Jobs, die schlechter sind als die Originale, weil sie nicht für verteilte Ausführung entworfen wurden.

Planung, die funktioniert

Erfolgreiche Migrationen folgen einem Vorgehen in Phasen. Der Versuch, alles auf einmal zu migrieren, ist das häufigste Versagensmuster.

Phase 1 (Wochen 1-4): Erfassen und Pilot auswählen. Katalogisieren Sie jede bestehende Arbeitslast nach fachlichem Wert und Aufwand der Migration. Wählen Sie ein oder zwei Lasten, die hohen Wert und geringe Komplexität haben; tägliche ETL-Pipelines sind meist die besten Kandidaten. Setzen Sie den Workspace in Databricks auf, richten Sie das Netzwerk in der Cloud ein und legen Sie die erste Struktur in Unity Catalog an.

Phase 2 (Wochen 5-8): Pilotmigration und Validierung. Migrieren Sie die ausgewählten Lasten nach Databricks. Lassen Sie die alte und die neue Fassung parallel laufen, vergleichen Sie die Ergebnisse auf Korrektheit und messen Sie die Leistung. Lakehouse Federation kann unterstützte Altsysteme wie Amazon Redshift oder Teradata direkt aus Databricks abfragen, was den direkten Vergleich der beiden Fassungen erleichtert. Diese Phase belegt, dass der Ansatz trägt, bevor Sie sich auf den Produktivbetrieb festlegen. Schulen Sie das Team in dieser Zeit auf Spark, Notebooks und Delta Lake.

Phase 3 (Wochen 9-16): erste Welle in den Produktivbetrieb. Migrieren Sie den ersten Schwung produktiver Lasten. Richten Sie das Rahmenwerk der Governance ein, also Unity Catalog für die Governance innerhalb von Databricks und Dawiso für die plattformübergreifende. Setzen Sie Überwachung, Alarmierung und Kostenkontrollen auf. Schalten Sie die alten Fassungen migrierter Lasten ab, sobald sie validiert sind.

Phase 4 (ab Woche 17): übrige Lasten und Abschaltung. Migrieren Sie die übrigen Lasten in weiteren Wellen, nach Priorität geordnet. Schalten Sie die alte Infrastruktur ab, sobald eine Welle fertig ist. Optimieren Sie die Kosten; jetzt liefern Abnahmevereinbarungen, Spot-Instanzen und die Optimierung nach Art der Last spürbare Ersparnisse.

Wie Dawiso die Migration unterstützt

Während einer Migration betreiben Organisationen zwei Systeme gleichzeitig, die Altplattform und Databricks. Diese Übergangszeit ist die, in der Lücken in der Governance am gefährlichsten sind. Teams brauchen Sicht auf beide Systeme zugleich: welche Datensätze migriert sind, welche auf dem Altsystem bleiben und ob die migrierten Fassungen den Originalen entsprechen.

Sind sowohl die Altplattform als auch Databricks angebunden, hält der Datenkatalog von Dawiso während des Übergangs die Metadaten beider nebeneinander. Eine Analystin, die nach „customer_orders“ sucht, findet sowohl die alte Tabelle im Warehouse als auch die neue in Delta Lake, und das Team kann im Katalog festhalten, welche aktuell ist. Das hilft zu verhindern, dass Teams nach abgeschlossener Migration noch veraltete Daten des Altsystems abfragen.

Das Business Glossary sorgt dafür, dass die Definitionen der Kennzahlen korrekt übergehen. „Umsatz“, „aktives Abonnement“ und „Abwanderungsquote“ müssen im neuen System dasselbe bedeuten wie im alten. Das Business Glossary von Dawiso hält die kanonischen Definitionen und verknüpft sie mit den Tabellen auf beiden Plattformen, sodass das Team die Pipeline auf Databricks gegen die vereinbarte Definition prüfen kann, und verhindert so das verbreitete Scheitern einer Migration, bei dem „Umsatz“ in der Pipeline auf Databricks anders berechnet wird als in der auf Redshift.

Nach der Migration deckt die plattformübergreifende Governance von Dawiso Databricks neben den BI-Werkzeugen, SaaS-Quellen und verbliebenen Altsystemen ab, die Sie anbinden. Wie tief die Lineage reicht, hängt von der Quelle ab: Der Databricks-Konnektor liest Objekte aus Unity Catalog und die Lineage auf Spaltenebene aus der Systemtabelle system.access.column_lineage, während die Lineage aus Power BI auf Objektebene erfasst wird. Über das Model Context Protocol (MCP) ermöglicht der Dawiso MCP-Server KI-Agenten, den Katalog zu durchsuchen, Objektdetails einschließlich der Glossarbegriffe zu lesen, die Lineage zu verfolgen und Datenstichproben über die angebundenen Quellen hinweg anzusehen.

Fazit

Die fünf Treiber einer Migration, also Konsolidierung im Lakehouse, vereintes ML, Leistungsgewinne, neu geordnete Kosten und Produktivität im Team, sind real und messbar. Doch eine Migration ist kein Projekt zum Ausrollen und Vergessen. Die Organisationen, die Erfolg haben, behandeln sie als Wandel in Phasen: zuerst ein Pilot, dann die Leistung validieren, die Governance einrichten, schrittweise wachsen und die Kosten optimieren, sobald die Plattform stabil ist. Die Organisationen, die sich schwertun, versuchen alles auf einmal zu migrieren, überspringen das Einrichten der Governance oder erwarten, dass die neue Plattform Probleme löst, die in Wahrheit Probleme der Datenqualität auf der alten waren. Ein plattformübergreifender Katalog wie Dawiso macht den Übergang sicherer, weil er während der ganzen Migration Sicht auf beide angebundenen Systeme gibt.

Quellen

• Databricks - Manage model lifecycle in Unity Catalog
• Databricks - What is Photon?
• Databricks - Use liquid clustering for tables
• Forrester / Databricks - Forrester Total Economic Impact Spotlight
• AWS - Amazon S3 pricing
• AWS - Amazon Redshift pricing
• Databricks - Databricks pricing
• Flexera - Flexera 2026 State of the Cloud Report
• Databricks - Connect to external databases and catalogs (Lakehouse Federation)
• Dawiso Help - Databricks connector
• Dawiso Help - Power BI connector
• Dawiso Help - Dawiso Model Context Protocol (MCP)