Navigation durch die Synapse-Migration zu Databricks

Azure Synapse diente als zuverlässiges Fundament für SQL-Analysen in großem Maßstab, und Teams, die darauf aufgebaut haben, haben damals eine vernünftige Entscheidung getroffen. Eine Plattform, die in erster Linie um ein Data Warehouse herum konzipiert ist, ist jedoch nicht für das gesamte Spektrum dessen ausgelegt, was von Datenteams heute erwartet wird. Das Schließen dieser Lücken erfordert in der Regel zusätzliche Dienste, Integrationen und betrieblichen Aufwand, was sich im Laufe der Zeit summiert.

Die Migration zu Databricks ist eine Möglichkeit, dieses Problem zu lösen. In diesem Blog erläutern wir, wie Sie eine Synapse-Migration angehen und worauf Sie bei der Durchführung achten sollten.

Was eine Synapse-Migration ermöglicht

Bei den Synapse-Migrationsprojekten unserer Kunden sehen wir immer wieder drei wesentliche geschäftliche Treiber:

1. Einheitlicher Datenbestand. Mit dem Wachstum von Datenplattformen steigt auch die Anzahl der beteiligten Dienste. Beispielsweise verarbeiten Synapse Analytics-Pools eine bestimmte Art von Workloads, Spark-Pools eine andere, und serverloses SQL bietet Ad-hoc-Zugriff. Azure Data Factory wird oft parallel dazu eingesetzt, um alles zu orchestrieren. Viele Unternehmen haben zudem veraltete SSIS-Workloads, die weiterhin unterstützt werden müssen. Keine dieser Komponenten ist für sich genommen problematisch. Die Herausforderung entsteht jedoch, wenn zusätzliche Dienste eingeführt werden, da dies eine weitere Ebene für Governance, Überwachung, Berechtigungsverwaltung und betrieblichen Aufwand mit sich bringt.
   Databricks löst dieses Problem, indem es Data Engineering, Analytik, maschinelles Lernen und Governance auf einer einzigen Plattform vereint. Anstatt zwischen Diensten mit unterschiedlichen Betriebsmodellen zu wechseln, können Teams mit derselben zugrunde liegenden Architektur und demselben Governance-Framework arbeiten. Das Ergebnis sind geringere Komplexität, weniger Integrationspunkte und eine Plattform, die sich in großem Maßstab einfacher betreiben lässt.
2. Zukunftssicherheit. Der Fokus moderner Datenteams hat sich auf die Unterstützung von Modellen für maschinelles Lernen, Echtzeit-Datenpipelines und KI-gestützte Anwendungen verlagert. Alle diese Workloads hängen von denselben zugrunde liegenden Daten ab. Die Herausforderung besteht darin, dass traditionelle, Warehouse-zentrierte Architekturen nicht für dieses Maß an Konvergenz ausgelegt waren und primär auf BI-Anforderungen abzielten. Wenn die Anforderungen steigen, fügen Unternehmen oft weitere Dienste und spezialisierte Tools hinzu, um Funktionslücken zu schließen.
   Databricks ist für diese Konvergenz gebaut und vereint Daten, Analytik und KI auf einer einzigen Plattform. Da Unity Catalog eine konsistente Governance für Daten, Notebooks und KI/ML-Assets bietet und das Unity AI Gateway diese Kontrollen auf Modelle, Agenten und KI-Anwendungen ausdehnt, können Unternehmen neue KI-Workloads einführen, ohne neue Governance-Silos zu schaffen.
3. Betriebliche Effizienz. Obwohl die meisten Business Cases für eine Migration mit den Lizenzkosten beginnen, lassen sich dort selten die größten Einsparungen erzielen. Der größere Effekt ergibt sich oft aus der Reduzierung der Anzahl der Systeme, die Teams betreiben und unterstützen müssen. Weniger Dienste bedeuten weniger Integrationen, weniger Übergaben zwischen Tools und weniger potenzielle Probleme.

Unternehmen, die diesen Schritt bereits getan haben, sehen konkrete Ergebnisse. Beispielsweise migrierte Casey's, die drittgrößte Convenience-Store-Kette in den USA, ihre Analyseumgebung von Synapse zu Databricks Lakehouse (ehemals Databricks SQL) und verkürzte die Bereitstellungszeiten für betriebliche Daten von acht auf vier Stunden. Ein weiteres Beispiel ist Italgas, das seine Architektur durch die Ablösung von Synapse und Azure Analysis Services vereinfacht hat. Das Unternehmen verzeichnete eine Reduzierung der Workload-Kosten um 73 % und stellt gleichzeitig sowohl Power BI als auch KI-gestützte Analysen direkt aus Databricks bereit.

Auch wenn die Details von Unternehmen zu Unternehmen variieren, bleibt das Muster dasselbe: einfachere Architekturen, schnellere Datenbereitstellung und eine Plattform, die besser auf die Anforderungen moderner Datenteams abgestimmt ist.

Verstehen, was Sie tatsächlich migrieren

Eine Sache, die Teams zu Beginn einer Synapse-Migration oft unvorbereitet trifft, ist der Umfang dessen, was sie migrieren. Obwohl Azure Synapse oft als eine einzige Plattform betrachtet wird, besteht sie in der Praxis aus einer Vielzahl unterschiedlicher Dienste unter einer Marke. Jeder dieser Dienste erfordert möglicherweise eine andere Migrationsstrategie und weist einen unterschiedlichen Komplexitätsgrad auf.

Die meisten Migrationen erfordern den größten Aufwand bei Dedicated SQL Pools, in denen sich über Jahre hinweg Geschäftslogik, gespeicherte Prozeduren, Verteilungsstrategien, Indexierungsentscheidungen und Leistungsoptimierungen angesammelt haben. Doch die Komplexität macht selten beim SQL halt. Dieselbe Migration muss in der Regel auch die Orchestrierung (Azure Data Factory und Synapse Pipelines), Berechtigungen und Governance (SQL-Berechtigungen plus Microsoft Purview, wobei die Lineage oft manuell zusammengefügt wird) sowie BI- und Drittanbieter-Konnektivität (semantische Modelle, Berichte und nachgelagerte Tools, die direkt mit Synapse-Endpunkten verbunden sind) berücksichtigen. Dies ist der Teil des Bestands, der die meiste Neugestaltung, Tests und Validierung erfordert – und der Teil, der am ehesten unterschätzt wird.

Serverless SQL Pools sind im Allgemeinen einfacher, da sie in erster Linie eine Abfrageschicht über Dateien in einem Data Lake bereitstellen. Bei der Migration geht es hier meist um die Wiederherstellung von Ansichten, externen Tabellen und Zugriffsmustern und weniger um die Neugestaltung komplexer Workloads. Spark Pools sind die am einfachsten zu migrierende Komponente, da Synapse Spark und Databricks beide auf Apache Spark aufbauen und Notebooks oft mit relativ wenigen Änderungen migriert werden können.

Der entscheidende Punkt ist, dass sich diese Komponenten mit unterschiedlicher Geschwindigkeit bewegen, unterschiedliche Stakeholder einbeziehen und unterschiedliche Risiken bergen. Unternehmen, die die Migration als einen einzigen Arbeitsstrang mit einem einzigen Zeitplan angehen, unterschätzen oft sowohl den Aufwand als auch die Komplexität. An diesem Punkt geraten Zeitpläne ins Rutschen und Migrationsprogramme weiten sich über ihren ursprünglichen Rahmen aus. Für eine erfolgreiche Migration sollten Teams den Migrationsprozess strukturieren.

Wie Sie die Migration strukturieren

Eine Migration von Synapse zu Databricks ist kein einzelner Arbeitsstrang. Sie migrieren drei verschiedene Compute-Modelle, konsolidieren die Governance, modernisieren die Orchestrierung und überarbeiten jahrelang angesammelte T-SQL-Logik. Teams, die dies erfolgreich meistern, behandeln das Vorhaben eher als strukturiertes Programm denn als technisches Projekt mit einem phasenweisen Ansatz.

Discovery. Jede Migration beginnt mit dem Verständnis dessen, was tatsächlich ausgeführt wird. Der Lakebridge Profiler scannt den Synapse-Bestand und sammelt Metadaten zu Konfiguration, Ressourcennutzung, Abfragemustern und Performance-Baselines. Die Ergebnisse werden zur Erstellung eines TCO-Business-Case verwendet.

Assessment. Sobald die Bestandsaufnahme abgeschlossen ist, besteht der nächste Schritt darin, die Komplexität zu verstehen. Der Lakebridge Analyzer bewertet die T-SQL-Codebasis, klassifiziert jedes Objekt nach Komplexität, kennzeichnet nicht unterstützte Konstrukte und bildet Abhängigkeiten ab. Die Ergebnisse können verwendet werden, um den Zeitplan für die Migration und den damit verbundenen Aufwand zu bewerten sowie die Priorität der Asset-Migrationen festzulegen. Beginnen Sie mit Workloads geringer und mittlerer Komplexität als schnelle Erfolge („Low-Hanging Fruits“) und planen Sie den Aufwand für die kritischsten Anwendungsfälle im Anschluss.

Design. Sobald Transparenz über den Bestand herrscht, verlagert sich das Augenmerk auf die Architektur und das Design. Die erste Entscheidung betrifft den Ansatz: Lift-and-Shift, Modernisierung oder ein hybrider Ansatz. Für die meisten Synapse-Migrationen ist ein hybrider Ansatz die richtige Wahl. Automatisierte Tools übernehmen den Großteil der Codekonvertierung, um den Zeitplan für den Ausstieg aus Synapse einzuhalten, während die Modernisierung schrittweise erfolgt, sobald die Workloads auf Databricks laufen.

Die zweite Entscheidung betrifft die Reihenfolge. Ein BI-First-Ansatz führt in der Regel schneller zu ersten Erfolgen als der Start mit ETL. Mithilfe von Lakehouse Federation können Sie Synapse-Daten über Unity Catalog bereitstellen, noch bevor die zugrunde liegenden Pipelines migriert wurden. Ein praktischer Einstieg besteht darin, die geschäftsorientierten, erweiterten Daten (Ihre Data Marts) zuerst auf Databricks bereitzustellen und sie den Geschäftsanwendern dann direkt mit Genie für Analysen in natürlicher Sprache zur Verfügung zu stellen. Die geschäftlichen Stakeholder sehen so frühzeitig Fortschritte und Mehrwert, während die Engineering-Teams im Hintergrund die komplexeren ETL-Prozesse modernisieren. Lesen Sie unseren Blogbeitrag, um den für Sie passenden Migrationsansatz zu bestimmen.

Pilot. Vor der Skalierung muss die Migrationsstrategie anhand eines realen Workloads durchgängig validiert werden. Wählen Sie einen Leuchtturm-Anwendungsfall aus, migrieren Sie ihn von der Datenaufnahme bis zur Nutzung und überführen Sie ihn in die Produktion. Ein Pilotprojekt validiert die Architektur, das Governance-Modell, die Testverfahren und die Tools unter realen Bedingungen und liefert wiederverwendbare Assets für die folgenden Phasen.

Migration in Wellen. Für die Skalierungsphase wird eine Migration in Wellen empfohlen. Jede Welle ist so konzipiert, dass sie einen sichtbaren geschäftlichen Nutzen bringt und eine Feedbackschleife mit den Endanwendern etabliert.

Die Ausführung erfolgt in der Regel in vier parallelen Workstreams: Ingestion (Verschieben von ADF- und Synapse-Pipeline-Workloads zu Lakeflow Connect), Transformation (Migrieren von T-SQL-Prozeduren und Geschäftslogik zu Databricks), Orchestrierung (Verschieben von Zeitplänen und Abhängigkeiten zu Databricks Workflows) und Konsum (Umleiten von BI-Tools und semantischen Modellen auf Databricks SQL Warehouses). Durch die parallele Ausführung können Teams frühzeitig Mehrwert liefern und Synapse nach einem planbaren Zeitplan ablösen.

Databricks unterstützt Synapse-Migrationen aus verschiedenen Blickwinkeln: Beratung und Bereitstellung durch unser Forward Deployed Engineering-Team, zertifizierte Brickbuilder-Partner und Accelerators wie Lakebridge, die die Hauptarbeit automatisieren. Das Ziel besteht nicht nur darin, die Migration abzuschließen, sondern auch darin, die Fähigkeiten und das Betriebsmodell aufzubauen, die das Team benötigt, um die Plattform noch lange nach Projektende erfolgreich zu betreiben.

Daten-Ingestion

Vor der Konvertierung von SQL-Code müssen die Daten zunächst in das Lakehouse importiert werden. Databricks bietet hierfür verschiedene Optionen an, je nach Quellsystemen und betrieblichen Anforderungen.

Für viele gängige Unternehmensquellen bietet Lakeflow Connect eine verwaltete Ingestion-Lösung mit integrierten Connectoren und automatisierter Pipeline-Verwaltung. Gleichzeitig basiert Databricks auf offenen Speicherformaten, sodass Unternehmen eine Vielzahl von Ingestion-Tools von Drittanbietern nutzen können. Lösungen wie Fivetran, Airbyte und andere ETL/ELT-Plattformen können Daten direkt in Delta Lake importieren. So können Kunden bestehende Datenintegrations-Ökosysteme einbinden, anstatt an ein einziges Ingestion-Framework gebunden zu sein.

Code-Konvertierung in der Praxis

Sobald die Daten im Lakehouse verfügbar sind, verlagert sich der Migrationsaufwand auf die Code-Konvertierung, was in der Regel die komplexeste Phase der Migration darstellt. Während automatisierte Tools den Großteil der Übersetzung übernehmen (normalerweise etwa 80–90 %), entfällt der verbleibende Aufwand auf die Verfeinerung der prozeduralen Logik und das Auflösen von Mustern, die nicht automatisch übersetzt werden können.

Im Folgenden finden Sie einige Unterschiede in der Syntax von Synapse und Databricks, auf die Sie achten sollten.

Entfernen physischer Direktiven

Das häufigste Konvertierungsmuster ist das Entfernen von physischen Optimierungsdirektiven. Dedicated SQL Pools stützen sich stark auf Konstrukte wie HASH-Verteilung, ROUND_ROBIN-Verteilung, REPLICATE-Verteilung und Clustered-Columnstore-Indizes. Diese sind für das Performance-Tuning in Synapse von grundlegender Bedeutung, haben jedoch in Databricks keine direkte Entsprechung und werden daher bei der Migration in der Regel weggelassen.

Stattdessen setzt Databricks auf Speicheroptimierung und Liquid Clustering, um die Abfrageleistung zu verbessern. Ersteres wird automatisch durch Predictive Optimization erledigt, die kontinuierlich Wartungsarbeiten wie Dateikomprimierung, Erfassung von Statistiken und VACUUM für Delta-Tabellen durchführt. Letzteres wird durch Liquid Clustering bereitgestellt, das Daten in Delta-Tabellen anhand einer oder mehrerer Clustering-Spalten organisiert, um die Abfrageleistung zu verbessern. Die Auswahl der optimalen Clustering-Spalten setzt jedoch voraus, dass man versteht, wie Daten abgefragt werden – eine Aufgabe, die in der Praxis oft schwierig ist und sich mit der Weiterentwicklung der Workloads häufig ändert. Um diesen betrieblichen Aufwand zu verringern, hat Databricks CLUSTER BY AUTO eingeführt, das Clustering-Spalten basierend auf beobachteten Abfragezugriffsmustern automatisch identifiziert und kontinuierlich verfeinert. Zusammen reduzieren diese Funktionen den manuellen Aufwand für das physische Tuning im Vergleich zu Dedicated SQL Pools erheblich.

Entscheidungen zum physischen Design, die in Synapse erheblichen Entwicklungsaufwand erforderten, fallen einfach weg. Die Plattform übernimmt das, was zuvor manuell erledigt werden musste.

Funktionszuordnung

Die meisten häufig verwendeten T-SQL-Funktionen haben direkte Entsprechungen in Databricks, und Lakebridge übernimmt den Großteil der Zuordnungen automatisch.

Die häufigere Fehlerquelle sind nicht die Funktionszuordnungen selbst, sondern Verhaltensunterschiede, die sich auf subtile Weise auf die Ergebnisse auswirken. Der Vergleich von Zeichenfolgen (Strings) ist hierfür ein gutes Beispiel. Synapse Dedicated SQL Pools arbeiten in der Regel mit Sortierungen, bei denen die Groß-/Kleinschreibung nicht berücksichtigt wird (case-insensitive), während Databricks SQL standardmäßig die Groß-/Kleinschreibung beachtet (case-sensitive). Logik, die sich implizit auf Vergleiche ohne Berücksichtigung der Groß-/Kleinschreibung verlässt, liefert nach der Migration möglicherweise andere Ergebnisse. Wo erforderlich, sollten Vergleiche explizit mit LOWER() oder UPPER() auf beiden Seiten durchgeführt werden. Die Syntaxkonvertierung ist meist unkompliziert; semantische Unterschiede erfordern mehr Sorgfalt.

Stored Procedures: Erst migrieren, dann optimieren

Dank der nativen Unterstützung von Stored Procedures in Databricks können die meisten Synapse-Prozeduren mit ihrer gesamten Struktur migriert werden. Parameter, Variablen, bedingte Logik und DML-Operationen werden alle unterstützt.

Die Prozedur selbst ist selten das Problem. Die Komplexität liegt im Detail: Cursor, zeilenweise Verarbeitung, dynamisches SQL und Synapse-spezifische Performance-Optimierungen. Diese Muster erfordern Abwägung, nicht nur reine Übersetzung.

SCD Typ 2: Historie bewahren mit Delta Lake

Slowly Changing Dimensions (SCD) gehören zu den Bereichen, in denen Synapse-Implementierungen am stärksten variieren. Viele Unternehmen haben über Jahre hinweg eigene Stored Procedures und Merge-Logiken angesammelt. Das Migrationsziel besteht nicht darin, diese Implementierung exakt nachzubauen, sondern die geschäftliche Anforderung zu erfüllen: historische Versionen von Dimensionsdatensätzen zu pflegen, während der aktuelle Zustand abfragbar bleibt.

Ein gängiger Databricks-Ansatz umfasst zwei Schritte. Zuerst werden die geänderten Datensätze als abgelaufen markiert. Dann werden die neuen Versionen eingefügt.

Die ACID-Transaktionen von Delta Lake machen dieses Muster auch dann sicher, wenn mehrere Operationen beteiligt sind.

Fehlerbehandlung

Viele Stored Procedures in Synapse stützen sich auf TRY...CATCH-Blöcke, um Fehler abzufangen oder Audit-Einträge zu schreiben. Databricks SQL bietet native Entsprechungen über Condition Handler, sodass die meisten bestehenden Muster SQL-basiert bleiben können.

Einfache Szenarien wie Audit-Protokollierung und kontrollierte Fehler lassen sich in der Regel direkt übersetzen. Komplexere Workflows erfordern möglicherweise ein zusätzliches Design, insbesondere wenn eine nachgelagerte Koordinierung über Databricks Workflows involviert ist.

Was die Praxiserfahrung lehrt

Einige Erkenntnisse zeigen sich bei Synapse-Migrationen immer wieder, unabhängig von der Größe des Unternehmens oder der Komplexität der Systemlandschaft.

Beginnen Sie mit einer Bewertung, nicht mit der Konvertierung. Führen Sie Lakebridge Profiler und Analyzer aus, bevor Sie eine einzige Zeile konvertierten Code schreiben. Verschaffen Sie sich Klarheit über die tatsächliche Nutzung, den Umfang, die Komplexität und die Abhängigkeiten – und nutzen Sie diese Daten, um den Umfang wo immer möglich zu reduzieren.

Automatisieren Sie konsequent. Lakebridge übernimmt 80–90 % der Code-Konvertierung. Konzentrieren Sie die Entwicklungszeit auf die 10–20 %, die menschliches Urteilsvermögen erfordern – Cursor, dynamisches SQL, komplexe Fehlerbehandlung.

Unterschätzen Sie niemals die Validierung. In der Praxis erfordert die Validierung oft mehr Aufwand als die Migration selbst. Der effektivste Ansatz besteht darin, nach jeder Migrationswelle einen Abgleich durchzuführen und dabei Zeilenanzahlen, Aggregationen, Hash-basierte Datensatzvergleiche und toleranzbasierte Prüfungen für Werte zu vergleichen, bei denen eine exakte Übereinstimmung nicht angemessen ist. Lakebridge Reconcile unterstützt dies über all diese Dimensionen hinweg. Bei geschäftskritischen Workloads ermöglicht der parallele Betrieb beider Umgebungen vor der endgültigen Umstellung den Teams, die Ergebnisse direkt miteinander zu vergleichen, während die Benutzer weiterhin mit den vertrauten Berichten arbeiten.

Lösen Sie sich von Synapse-geprägtem Denken. Ein gutes Beispiel ist das Tabellendesign. Teams versuchen häufig, Synapse-HASH-Verteilungsschlüssel direkt auf Delta Lake-Partitionsspalten abzubilden. In den meisten Fällen führt dies zu unnötiger Komplexität und schlechter Performance. Werte mit hoher Kardinalität wie Kunden-IDs oder Bestell-IDs eignen sich selten als Partitionsschlüssel und lassen sich oft besser durch Liquid Clustering und die automatisierten Optimierungsfunktionen von Databricks wie die vorausschauende Wartung verwalten.

Bauen Sie nicht nach, was die Plattform jetzt automatisch erledigt. Migrationen bieten die Chance, Architekturen zu vereinfachen, anstatt sie exakt zu reproduzieren. Delta Lake, automatisierte Optimierung und moderne Lakehouse-Muster machen viele der manuellen Tuning-Techniken überflüssig, die in traditionellen Warehouse-Umgebungen erforderlich waren. Die Übernahme jeder historischen Optimierungsentscheidung in Databricks führt oft dazu, dass alte Einschränkungen beibehalten werden, ohne dass die Gründe für diese Einschränkungen noch existieren.

Bereiten Sie die Betriebsbereitschaft vor. In Delta-Tabellen sammeln sich im Laufe der Zeit durch inkrementelle Workloads naturgemäß kleine Dateien an. Ohne Komprimierungs- und Wartungsprozesse kann sich die Performance allmählich verschlechtern. Teams, die von traditionellen Data-Warehouse-Plattformen kommen, sind oft überrascht, dass die Speicheroptimierung Teil des laufenden Betriebsmodells wird. Dies ist nicht schwer zu verwalten, muss aber von Anfang an eingeplant werden.

Planen Sie das Change Management ein. Die meisten Synapse-Teams sind neu bei Databricks, und zu geringe Investitionen in die Befähigung sind einer der häufigsten Gründe, warum Projekte ihre Einführungsziele verfehlen. Setzen Sie den Enablement-Plan genauso ernsthaft um wie den technischen Plan.

Vermeiden Sie eine vorzeitige Stilllegung von Synapse. Bei den meisten erfolgreichen Migrationen bleibt die Altsystem-Umgebung nach der Verlagerung der Produktions-Workloads noch eine Zeit lang verfügbar. Die Rechenleistung kann pausiert werden, um die Kosten zu minimieren, während gleichzeitig eine Rollback-Option für den Fall unerwarteter Probleme erhalten bleibt. Noch wichtiger ist, dass dieses Sicherheitsnetz den geschäftlichen Stakeholdern Vertrauen gibt, während sich die neue Plattform im realen Einsatz bewährt.

Die Migration von Synapse zu Databricks ist selten nur ein reines Technologieprojekt. Im Kern geht es darum, eine Plattform zu vereinfachen, die im Laufe der Zeit immer komplexer geworden ist, und gleichzeitig ein Fundament zu schaffen, das die nächste Generation von Analysen, AI und Datenprodukten unterstützen kann. Obwohl die technische Arbeit wichtig ist, profitieren diejenigen Unternehmen am meisten von diesen Migrationen, die die Gelegenheit nutzen, gleichzeitig ihre Architektur zu vereinfachen, unnötige Komplexität zu eliminieren und ihre Betriebspraktiken zu modernisieren. Der größere Vorteil besteht darin, am Ende eine Datenplattform zu haben, die einfacher zu betreiben, leichter zu erweitern und besser auf die zukünftige Ausrichtung des Unternehmens abgestimmt ist.

Nächste Schritte

Wenn Sie am Anfang einer Synapse-Migration stehen:

• Führen Sie Lakebridge Profiler and Analyzer in Ihrer Umgebung aus. Erfassen Sie die Daten, bevor Sie den Arbeitsumfang festlegen.
• Lesen Sie den Blogbeitrag Migration Strategy: Lessons Learned und das eBook Transforming Legacy Data Warehouses.
• Wenn Sie praktische Unterstützung wünschen: Das Databricks FDE Team und zertifizierte Migrationspartner führen Synapse-Migrationen von Anfang bis Ende durch.

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