Ein Entscheidungs-Framework für die ETL-Migration zu Databricks

Ihr Team verfügt über Hunderte von Stored Procedures, einige Scheduler, über Rollen und Schemata verteilte Berechtigungen und eine bevorstehende Frist für die Verlängerung des Cloud Data Warehouse. Niemand ist sich einig, was zuerst migriert werden soll. Einige möchten alles in PySpark neu schreiben. Andere wollen SQL unverändert übernehmen und das Thema damit abhaken. Was in der Diskussion untergeht: die Metadaten, die Lineage und die Berechtigungen, die mit dem Code migriert werden, sowie die Möglichkeit, diese auf dem Weg zu konsolidieren.

Keines der beiden Extreme funktioniert. Teams, die bei der Data-Warehouse-Migration erfolgreich sind, betrachten jeden Workload einzeln und wählen das richtige Tool für die jeweilige Aufgabe. Dieser Beitrag schlägt ein Entscheidungs-Framework für die Auswahl vor: wann Lakehouse (Databricks SQL), Spark Declarative Pipelines oder PySpark verwendet werden sollten und wie Sie die Arbeit phasenweise aufteilen, um Ergebnisse zu liefern, anstatt bei der Planung zu stagnieren.

Drei Wege, eine Migration

Auf Databricks können Sie ETL-Pipelines auf drei verschiedene Arten migrieren, die oft kombiniert werden.

Lakehouse (Databricks SQL)

Dies ist der direkteste Weg für SQL-fokussierte Teams. Er deckt ein Spektrum von einfach bis komplex ab. Er läuft auf SQL-Warehouses, die standardmäßig Photon-beschleunigt und vollständig mit ANSI und Spark SQL (%sql) kompatibel sind. Wählen Sie Serverless für variable oder unvorhersehbare Workloads (schneller Start, Skalierung auf Null, sekundengenaue Abrechnung). Wählen Sie Classic für gleichmäßige Workloads oder wenn Sie spezifische Netzwerk- oder Kostenkontrollen benötigen.

Eine einfache SQL-Aufgabe:

Wenn die Logik eine Ablaufsteuerung (Bedingungen), Schleifen, Variablen, Fehlerbehandlung oder eine parametergesteuerte Ausführung erfordert, bieten Stored Procedures diese prozedurale Ebene. Sie werden über Unity Catalog verwaltet und können aus Workflows mit Parametern aufgerufen werden.

Die Faustregel: Wenn Ihr Legacy-Code aus einer einzigen SQL-Anweisung besteht, migrieren Sie ihn als SQL-Task. Wenn er prozedurale Logik enthält (Variablen, Schleifen, Parameter, Fehlerbehandlung), kapseln Sie ihn in einer Stored Procedure, die von Unity Catalog verwaltet wird und aus Workflows aufgerufen werden kann. Kapseln Sie einfaches SQL nicht in einer Prozedur, nur weil das ursprüngliche System dies erforderte.

Spark Declarative Pipelines (SDP)

Die Teil von Lakeflow sind, verfolgen einen anderen Ansatz. Sie deklarieren, was Ihre Pipeline produzieren soll, und die Engine kümmert sich um Ausführungsreihenfolge, Wiederholungsversuche und Skalierung. Sie erhalten integrierte Datenqualitäts-Constraints, automatische Abhängigkeitsauflösung und eine einheitliche Batch- und Streaming-Verarbeitung in derselben Definition.

Unter der Haube entscheidet Enzyme, wann abgeleitete Tabellen inkrementell aktualisiert oder vollständig neu berechnet werden müssen. Autoscaling passt die Kapazität ohne manuelle Anpassung an Änderungen des Datenvolumens an. Unternehmen wie Block setzen auf dieses deklarative Modell, um die Pipeline-Orchestrierung bei steigender Nutzung zu vereinfachen.

PySpark und Spark SQL notebooks

Die Ihnen die volle Kontrolle bieten. Sie laufen auf Job-Clustern und verarbeiten Workloads, die nicht in ein SQL-Warehouse oder eine deklarative Pipeline passen.

Nutzen Sie PySpark wenn der Workload komplexe Geschäftslogik, ML-Feature-Engineering, API-Integrationen oder benutzerdefinierte Validierungen erfordert. Das folgende Beispiel bewertet Transaktionen mit einem in Unity Catalog registrierten Modell:

Nutzen Sie Spark SQL in einem Notebook, wenn die Sprache zwar SQL ist, der Workload jedoch die Kapazitäten eines SQL-Warehouses überschreiten könnte: sehr große Tabellen, intensive Shuffles, lang laufende Batch-ETL-Prozesse, bei denen Sie die explizite Kontrolle über Partitionierung, Broadcast Joins oder Caching haben möchten.

Aktivieren Sie Photon auf dem Job-Cluster für rechenintensive SQL- oder DataFrame-Arbeiten: große Joins, Aggregationen, Window-Funktionen, Scans über große spaltenbasierte Tabellen. Photon ist eine native, vektorisierte Engine, die diese Muster ohne Codeänderungen beschleunigt, einschließlich Pandas-UDFs (Arrow-basiert). Verzichten Sie auf Photon, wenn zeilenweise Python-UDFs dominieren, die Datensätze klein sind oder der Job rein aus I/O besteht.

Notebooks eignen sich auch gut für hybride Pipelines: Ingestion in SDP, Anreicherung in einem Notebook-Task.

Entscheidungsmatrix

Die folgende Tabelle dient als Ausgangspunkt für Teamdiskussionen, nicht als starre Regel.

Schnelle Entscheidungshilfe

Suchen Sie Ihr Team in der Spalte und die Komplexität Ihres Workloads in der Zeile. Die entsprechende Zelle zeigt Ihnen, wo Sie am besten anfangen.

Vier Phasen statt Big Bang

Entscheiden Sie sich lieber für "Was ist als Nächstes zu tun" in jeder Phase, anstatt festzulegen, "welcher Ansatz für alles" gilt.

Phase 1 – Analyse. Erfassen Sie Metriken aus Ihrem bestehenden Data Warehouse: CPU-Zeit, Laufzeit, Häufigkeit, Quell- und Zieltabellen. Klassifizieren Sie Workloads nach Komplexität. Nutzen Sie, wenn möglich, Migrationstools, um ein Inventar zu erstellen, das nach Wert im Vergleich zum Schwierigkeitsgrad bewertet ist. Wo Sie diese Daten finden, hängt von der Quelle ab. Fragen Sie auf Teradata DBC.QryLog ab. Verwenden Sie auf SQL Server sys.dm_exec_query_stats. Auf Oracle AWR-Berichte. Auf Snowflake QUERY_HISTORY. Die Details können variieren. Wenn Sie ein Integrationstool verwenden, können Sie dessen Metadaten nutzen, um Beziehungen zwischen Tabellen zu identifizieren, oder sich von einem LLM helfen lassen, diese Lineage aufzubauen. Das Ergebnis ist eine Übersicht, kein Plan für eine Neuschreibung. Das Ziel bleibt dasselbe: Priorisieren Sie Workloads nach Ressourcenverbrauch und Abhängigkeitsgrad, damit Sie wissen, wo Sie anfangen müssen. Richtig durchgeführt dauert diese Analyse mit Migrationstools nur wenige Tage statt Wochen manueller Skripterstellung.

Phase 2 – Quick Wins. Wählen Sie Workloads aus, die ein geringes Migrationsrisiko mit Anwendungsfällen mit hoher geschäftlicher Sichtbarkeit kombinieren. Das kann bedeuten, mit komplexen SQL-Jobs zu beginnen, die leicht zu konvertieren sind, oder mit Reporting-Pipelines, die den Stakeholdern die neue Plattform frühzeitig präsentieren. Einfache Anweisungen werden zu SQL-Tasks in Workflows. Prozedurale Logik wird zu Stored Procedures. Nutzen Sie Transpiler und KI-gestützte Konvertierung für die erste Übersetzung. Betreiben Sie beide Systeme parallel und vergleichen Sie Zeilenanzahlen, Prüfsummen und Stichproben-Datensätze. Es geht darum, Vertrauen aufzubauen – sowohl technischer als auch organisatorischer Art.

Walgreens hat beispielsweise das On-Premises-Teradata in einer schrittweisen Migration abgelöst und verarbeitet nun rund 40.000 Datenereignisse pro Sekunde auf dem Lakehouse, was die Optimierung der Lieferkette in fast 9.000 Filialen unterstützt.

Phase 3 – Modernisieren. Gestalten Sie nun die Pipelines neu, bei denen sich eine Modernisierung lohnt. Kandidaten dafür sind: Datenflüsse, bei denen Datenqualitäts-Constraints und Lineage manuelle Prüfungen reduzieren; Batch-Jobs, die von Streaming-Tabellen und CDC profitieren; Pipelines, bei denen Materialized Views die Komplexität verringern; sowie Metadaten, Berechtigungen und Audits, die zuvor in separaten Tools lagen und nun unter Unity Catalog konsolidiert sind. Ein bewährtes Muster ist es, das alte Verfahren als Fallback beizubehalten, während die neue Pipeline parallel läuft, bis sie die Validierung erfolgreich besteht. Modernisierte Pipelines verkürzen Batch-Fenster oft von Stunden auf Minuten und machen separate DQ-Tools überflüssig.

Phase 4 – Optimieren. Konsolidieren Sie redundante ETL-Pipelines, die nur existierten, um Einschränkungen des alten DW zu umgehen. Verlagern Sie komplexe Hotspots zu PySpark, wenn dies die Logik vereinfacht. Überprüfen Sie die Grenzen zwischen Batch und Streaming neu, da Sie nun über eine einheitliche Engine verfügen. Hier zahlt sich die Migration aus: Die alte Plattform ist abgeschaltet, redundante Pipelines sind verschwunden und die Architektur läuft auf einem einzigen System statt auf zweien.

Wo Migrationstools und KI ins Spiel kommen

Migrationstools automatisieren die mechanische Arbeit, ersetzen jedoch keine Architekturentscheidungen. Drei typische Rollen:

• Profiling und Analyse. Erfassen Sie Stored Procedures, SQL-Skripte und ETL-Jobs. Bilden Sie Abhängigkeiten ab. Lakebridge liefert eine Analyzer-Komponente mit, die bestehende Data-Warehouse-Plattformen scannt und ein Inventar von Objekten, Nutzungsmustern und Komplexität erstellt.
• Code-Konvertierung. Übersetzen Sie SQL und ETL von Teradata, Oracle, SQL Server, DataStage, Informatica und SSIS in Lakehouse- oder deklarative Pipelines. Der Converter von Lakebridge verarbeitet Stored Procedures und ETL-Flows, wobei öffentliche Richtlinien von bis zu 80 % Automatisierung und etwa doppelt so schnellen Projektlaufzeiten sprechen.
• Validierung. Vergleichen Sie Ergebnisse systemübergreifend mit automatisierten Prüfungen von Schemata, Zeilenanzahlen und Aggregaten. Lakebridge enthält einen Validator. Die Migrationsmethodik von Databricks behandelt den Abgleich als eine Phase erster Klasse und nicht als Nebensache.

Ein pragmatischer Ansatz: Lassen Sie Tools 60–80 % der ersten Konvertierung übernehmen und reservieren Sie die Zeit der Entwickler für die Muster, die Sie tatsächlich modernisieren möchten. Dies verhindert eine Eins-zu-eins-Übernahme technischer Schulden.

Was entfernt wird

Erfolgreiche Migrationen bedeuten die aktive Abschaltung von Systemen, nicht nur die Konvertierung von Code: eigenständige Scheduler-Server, benutzerdefinierte DQ-Frameworks, separate Lineage- und Metadaten-Tools, herstellerspezifische Compiler für Stored Procedures und selbst entwickelte Validierungsumgebungen. Die Migration ist erst abgeschlossen, wenn diese Systeme abgeschaltet sind und keine Kosten mehr verursachen.

Drei Anti-Patterns, die Migrationen ins Stocken bringen

• Einen einzigen Weg für alles zu wählen, ohne die Fähigkeiten des Teams, das Risikoprofil und den Workload-Typ zu berücksichtigen. Das reine SQL-Team verpasst Modernisierungschancen. Das reine PySpark-Team schreibt einfaches SQL ohne Grund neu.
• Nur den „Prozentsatz der Migration“ zu messen und dabei die Dauer des Parallelbetriebs, die Validierungszeit und die tatsächliche Abschaltung von Altsystemen zu ignorieren. Fünfzig Prozent migriert bedeuten nichts, wenn die alte Data-Warehouse-Plattform immer noch unter vollen Kosten läuft.
• Alte Scheduler und Zwischenschichten auf dem Lakehouse nachzubauen, anstatt Workflows und deklarative Pipelines zu nutzen. Eine Migration ist die Chance, die Pipeline-Orchestrierung zu vereinfachen. Nutzen Sie sie.

Wenn SQL-ETL über Engines, Schichten und Tools hinweg fragmentiert bleibt, bleibt auch die Plattform fragmentiert – selbst wenn die Daten in offenen Formaten vorliegen.

Es gibt nicht den einen richtigen Weg, Daten-Pipelines zu migrieren. Das Lakehouse bringt Sie schnell ans Ziel: einfache Tasks für einfache Logik, Stored Procedures, wenn Sie prozedurale Kontrolle benötigen. SDP bietet Ihnen moderne ETL-Pipelines mit integrierter Qualität und Lineage. Notebooks erledigen den Rest, egal ob Sie PySpark oder Spark SQL nutzen. Teilen Sie die Arbeit in Phasen auf, beginnen Sie mit Quick Wins und nutzen Sie jeden Beschleuniger, den Sie kriegen können.

Entdecken Sie den Databricks Migration Guide für technische Anleitungen oder probieren Sie es selbst mit der Databricks Free Edition aus.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag