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.

Ein SaaS-Unternehmen, das von einer Architektur aus drei Systemen (roher Lake auf S3, Warehouse auf Redshift und ein getrennter Jupyter Hub für ML) zu Databricks migrierte, beseitigte zwölf Pipelines zum Kopieren von Daten. Ein nächtliches ETL, das zuvor vier Stunden über zwei Systeme lief, war auf einem einzigen Spark-Cluster in 45 Minuten fertig. Die Vereinfachung betraf nicht nur das Tempo: Sie beseitigte 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 über die Registry befördert und an einem Endpunkt bereitgestellt, ohne die Plattform zu verlassen.

Ein Team für Kreditrisiko bei einem Finanzdienstleister verkürzte die Zeit bis zum Ausrollen eines Modells nach der Migration zu Databricks von sechs Wochen auf fünf Tage. Der Engpass war nicht das Training, sondern die Übergabe zwischen Data Science und ML Engineering. Auf dem alten Stack trainierten Data Scientists Modelle in Jupyter, exportierten sie als Pickle-Dateien und reichten sie Entwicklern, die die Pipeline der Merkmale im Produktivbetrieb nachbauten. Auf Databricks nutzen die Pipeline für das Training und die für die Bereitstellung denselben Code, dieselben Merkmale und dieselben Daten. Die Übergabe verschwand.

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, eine vektorisierte Ausführungsmaschine in C++, 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.

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 zuvor nächtlich ETL fuhr, um Clickstream-Daten von S3 nach Redshift zu bringen, bevor die morgendliche Analytik beginnen konnte, gewann das dreistündige Fenster für den Abgleich zurück: Analysten fragen die Daten von gestern nun ab, sobald die Pipelines fertig sind, und nicht drei Stunden später.

Ehrlich eingeordnet: Databricks ist nicht für alle Abfragen in SQL schneller als Snowflake. Der Optimierer von Snowflake und sein Umgang mit vielen gleichzeitigen Nutzern sind für BI-Lasten mit vielen Nutzern reifer. Databricks gewinnt bei komplexen mehrstufigen Transformationen, großen Joins, dem Training von Modellen und bei 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.

Lizenzen für Warehouses entfallen. Kommerzielle Data Warehouses (Teradata, Netezza, alte reservierte Instanzen in Redshift) tragen feste Lizenzkosten, unabhängig von der Nutzung. 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 auf Altsystemen überdimensioniert sind, und das sind die meisten.

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.

Daten im günstigen Objektspeicher der Cloud halten. Delta Lake auf S3, ADLS oder GCS kostet 0,02 US-Dollar pro GB und Monat. Verwalteter Speicher in einem Warehouse kostet typischerweise 5- bis 10-mal so viel. Bei 100 TB übersteigt allein die Ersparnis beim Speicher 10.000 US-Dollar pro Monat.

Der Einwand: Die Bepreisung von Databricks ist komplex (DBU plus Infrastruktur der Cloud), 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.

Ein Team für die Datenplattform, das zu Databricks migrierte, maß eine Verkürzung der Einarbeitung von drei Wochen auf vier Tage. Die Verbesserung kam nicht von besserer Dokumentation, sondern daher, dass alles an einem Ort war: die Daten, der Code, der Verlauf der Experimente und die Zugriffsrechte. Neue Entwickler mussten nicht lernen, wo die Dinge liegen, weil alles im selben Workspace lag.

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 Strategien für Partitionen wählen, Spalten mit hoher Kardinalität per Z-Ordering zusammenlegen 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. 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.

Der Datenkatalog von Dawiso erfasst Metadaten aus der alten Plattform und aus Databricks und liefert während des Übergangs eine einheitliche Sicht. Eine Analystin, die nach „customer_orders“ sucht, sieht sowohl die alte Tabelle in Redshift als auch die neue in Delta Lake, samt Lineage, die zeigt, wie sie zusammenhängen. Das hindert Teams daran, nach abgeschlossener Migration noch veraltete Daten des Altsystems abzufragen.

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 Glossar von Dawiso liefert die kanonischen Definitionen, auf die sich beide Systeme beziehen, und verhindert 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 BI-Werkzeugen, SaaS-Quellen und allen verbliebenen Altsystemen ab. Die Lineage spannt sich über die ganze Pipeline, von der Quelle über die Transformation in Databricks bis ins Dashboard. Über das Model Context Protocol (MCP) können KI-Agenten auf den zusammengeführten Katalog zugreifen, also Definitionen nachschlagen, die Aktualität prüfen und die Lineage über den gesamten Datenstapel nach der Migration validieren.

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 Systeme gibt.