Leitfaden zur Migration von Azure Synapse zu Snowflake¶
Snowflake-Migrationsframework¶
Eine typische Azure Synapse-zu-Snowflake-Migration kann in neun Hauptphasen unterteilt werden. Dieser Leitfaden bietet einen umfassenden Rahmen, um die technischen und strategischen Herausforderungen zu bewältigen und einen reibungslosen Übergang von der Azure-Analyseplattform zur Cloud-Datenplattform von Snowflake sicherzustellen.
Migrationsphasen¶
Phase 1: Planung und Entwurf¶
Diese anfängliche Phase ist entscheidend, um die Grundlage für eine erfolgreiche Migration zu schaffen. Eine Migration von Azure Synapse erfordert ein klares Verständnis seiner integrierten Komponenten sowie einen sorgfältig ausgearbeiteten Plan, um alle Beteiligten abzustimmen, den Umfang festzulegen und Budgetüberschreitungen zu vermeiden.
Konkrete Schritte:
Führen Sie eine gründliche Bewertung Ihrer Synapse-Umgebung durch:
Bestandsaufnahme und Analyse: Erfassen Sie alle Objekte in Ihrem Synapse-Arbeitsbereich, einschließlich Tabellen aus dem dedizierten SQL-Pool, Ansichten aus dem serverlosen SQL-Pool, Schemas, T-SQL-gespeicherte Prozeduren, Funktionen und Ansichten. Verwenden Sie die Systemansichten von Synapse (z. B. sys.tables, sys.procedures), um Metadaten zu sammeln.
Workloads analysieren: Verwenden Sie Azure Monitor und die dynamischen Verwaltungsansichten von Synapse (DMVs), um Abfragemuster, Benutzer-Parallelität, Ressourcennutzung (DWUs) und Leistungsengpässe zu identifizieren. Diese Daten sind entscheidend für die Entwicklung Ihrer Snowflake-Virtual-Warehouse-Strategie.
Abhängigkeiten identifizieren: Erfassen Sie alle vorgelagerten Datenquellen, insbesondere Azure Data Factory (ADF)-Pipelines, sowie nachgelagerte Verbraucher wie Power-BI-Berichte, Azure-Machine-Learning-Modelle und andere Anwendungen.
Migrationsbereich und Migrationsstrategie definieren:
Workloads priorisieren: Klassifizieren Sie Workloads nach geschäftlichen Auswirkungen und technischer Komplexität. Beginnen Sie mit einem leistungsstarken Workload mit geringer Komplexität (z. B. einem bestimmten Data Mart), um Wert zu demonstrieren und Momentum aufzubauen.
Migrationsansatz wählen: Entscheiden Sie sich entweder für einen „Lift-and-Shift“-Ansatz für eine schnellere Migration oder für eine Neuarchitektur, um Datenmodelle und Pipelines zu modernisieren.
Projektplan entwickeln:
Team aufstellen: Stellen Sie ein Migrationsteam mit klar definierten Rollen zusammen (Projektmanager, Data Engineer, Synapse-/SQL DBA, Snowflake-Architekt, Sicherheitsadministrator, Business-Analyst).
Zeitleiste erstellen: Definieren Sie realistische Zeitpläne und Meilensteine für jede der neun Phasen.
Erfolgskennzahlen definieren: Legen Sie klare KPIs fest, um den Erfolg zu messen, z. B. Kostenreduzierung, Verbesserung der Abfrageleistung und Benutzerzufriedenheit.
Phase 2: Umgebung und Sicherheit¶
Mit einem robusten Plan besteht der nächste Schritt darin, die Snowflake-Umgebung vorzubereiten und das Sicherheitsmodell von Azure zu übertragen. Das Hosten von Snowflake auf Azure wird dringend empfohlen, um den Datentransfer und die Netzwerkintegration zu vereinfachen.
Konkrete Schritte:
Einrichten Ihres Snowflake-Kontos:
Edition und Cloud-Anbieter wählen: Wählen Sie die Snowflake-Edition (z. B. Standard, Enterprise, Business Critical), die Ihren Anforderungen entspricht. Wählen Sie Azure als Cloud-Anbieter und dieselbe Region wie Ihren Azure Data Lake Storage (ADLS Gen2), um Datenübertragungskosten und Latenzzeiten zu minimieren.
Entwerfen einer Warehouse-Strategie: Erstellen Sie auf Grundlage der Workload-Analyse aus Phase 1 einen ersten Satz virtueller Warehouses. Isolieren Sie verschiedene Workloads (z. B. WH_LOADING, WH_TRANSFORM, WH_BI_ANALYTICS), um Ressourcenkonflikte zu verhindern. Beginnen Sie mit T-Shirt-Größen (z. B. X-Small, Small) und planen Sie, diese anhand von Performance-Tests anzupassen.
Sicherheitsmodell implementieren:
Azure-AD-Prinzipale auf Snowflake-Rollen abbilden: Übertragen Sie Benutzer und Gruppen aus Azure Active Directory (AAD) in das hierarchische Role-Based Access Control (RBAC)-Modell von Snowflake. Erstellen Sie eine Hierarchie von funktionalen Rollen (SYSADMIN, SECURITYADMIN) und greifen Sie auf die Rollen (BI_READ_ONLY, ETL_READ_WRITE) zu.
Netzwerkrichtlinien und Authentifizierung konfigurieren: Richten Sie Netzwerkrichtlinien ein, um den Zugriff über vertrauenswürdige IP-Adressen mithilfe von Azure Private Link für eine sichere Verbindung zu beschränken. Konfigurieren Sie SSO, indem Sie Snowflake als Enterprise-Anwendung in Azure AD einrichten.
Phase 3: Konvertierung von Datenbankcode¶
In dieser Phase werden die auf T-SQL basierenden DDL-, DML- und prozeduralen Codes aus Synapse so konvertiert, dass sie mit Snowflake kompatibel sind. Automatisierungstools können diesen Prozess beschleunigen, aber eine manuelle Überprüfung ist unerlässlich.
Konkrete Schritte:
DDL konvertieren (Datendefinitionssprache):
Tabellen und Ansichten: Extrahieren Sie CREATE TABLE und CREATE VIEW-Anweisungen von Synapse. Konvertieren Sie Synapse-spezifische Datentypen in ihre Snowflake-Äquivalente (siehe Anhang 2).
Synapse-spezifische Klauseln entfernen: Entfernen Sie Synapse-spezifische physische Verteilungsklauseln wie DISTRIBUTION (z. B. ROUND_ROBIN, HASH) sowie Indexstrategien wie CLUSTERED COLUMNSTORE INDEX. Snowflake verwaltet die Verteilung und Speicherung von Daten automatisch.
Einschränkungen neu implementieren: Snowflake erzwingt nur NOT NULL-Einschränkungen. PRIMARY KEY und UNIQUE-Einschränkungen sind informativ. Alle anderen Datenintegritätslogiken müssen in Ihre ETL/ELT-Prozesse verschoben werden.
Konvertieren von DML (Data Manipulation Language) und prozeduraler Code:
T-SQL-gespeicherte Prozeduren neu schreiben: Die in Synapse verwendeten T-SQL-gespeicherten Prozeduren müssen in einer von Snowflake unterstützten Sprache neu implementiert werden, beispielsweise in Snowflake Scripting (SQL), JavaScript oder Python.
SQL-Funktionen übersetzen: Ordnen Sie Synapse-/T-SQL-spezifische Funktionen ihren Snowflake-Entsprechungen zu (z. B. GETDATE() wird zu CURRENT_TIMESTAMP(), ISNULL() wird zu IFNULL()). Allgemeine Zuordnungen finden Sie in Anhang 3.
Phase 4: Datenmigration¶
Diese Phase konzentriert sich auf die physische Verschiebung historischer Daten von Ihren Synapse-SQL-Pools in Snowflake-Tabellen. Die effizienteste Methode nutzt Azure Data Lake Storage (ADLS Gen2) als zwischengeschalteten Stagingbereich.
Konkrete Schritte:
Entladen von Daten von Synapse nach ADLS Gen2:
Verwenden Sie den Befehl CREATE EXTERNAL TABLE AS SELECT (CETAS) in Synapse, um Daten aus Tabellen in einen bestimmten Container in Ihrem ADLS Gen2-Konto zu exportieren.
Formatieren Sie die Daten als Parquet oder komprimierte CSV-Dateien, um eine optimale Lade-Performance in Snowflake zu erreichen.
Daten von ADLS Gen2 in Snowflake laden:
Externen Stagingbereich erstellen: Erstellen Sie in Snowflake ein Storage-Integration-Objekt, um eine sichere Verbindung zu ADLS Gen2 herzustellen, und richten Sie anschließend einen externen Stagingbereich ein, der auf den Container mit den exportierten Daten verweist.
COPY INTO-Befehl verwenden: Verwenden Sie den Snowflake-Befehl COPY INTO <table> zum Laden der Daten aus dem ADLS-Stagingbereich in die Snowflake-Zieltabellen.
Größeres Warehouse nutzen: Verwenden Sie für den initialen Datenimport ein dediziertes, größeres virtuelles Warehouse, um den Prozess zu beschleunigen, und skalieren Sie es anschließend herunter oder setzen Sie es aus.
Phase 5: Datenaufnahme¶
Sobald die historischen Daten migriert sind, müssen Sie Ihre laufenden Datenaufnahmepipelines, meist in Azure Data Factory, neu gestalten, um Daten in Snowflake einspeisen zu können.
Konkrete Schritte:
Azure Data Factory migrieren (ADF)-Pipelines:
Ersetzen Sie in Ihren ADF-Pipelines Synapse-Datensets und -Aktivitäten durch deren Snowflake-Äquivalente. Verwenden Sie den nativen Konnektor von Snowflake in ADF sowohl für Quell- als auch für Zielaktivitäten.
Aktualisieren Sie alle Lookup- oder Skript-Aktivitäten, um den SQL-Dialekt von Snowflake zu verwenden.
Kontinuierliche Datenaufnahme mit Snowpipe implementieren:
Konfigurieren Sie Snowpipe für kontinuierliche Datenströme, die in ADLS Gen2 ankommen. Snowpipe lädt neue Datendateien automatisch und effizient in Snowflake-Tabellen, sobald sie eintreffen, und bietet so eine nahezu Echtzeit-Erfassungslösung. Dies kann durch Azure Event Grid-Benachrichtigungen getriggert werden.
Das Snowflake-Ökosystem nutzen:
Nutzen Sie die nativen Connectoren von Snowflake für Plattformen wie Kafka und Spark, um das direkte Data-Streaming zu vereinfachen.
Phase 6: Berichterstattung und Analyse¶
In dieser Phase werden alle nachgelagerten Anwendungen, insbesondere Power BI, umgeleitet, um Daten von Snowflake abzufragen.
Konkrete Schritte:
Verbindungstreiber aktualisieren: Stellen Sie sicher, dass Power BI Desktop und das lokale Daten-Gateway über die neuesten Snowflake-Treiber verfügen.
Power BI-Berichte umleiten:
Bearbeiten Sie in Power BI die Datenquelle für jeden Bericht und stellen Sie die Verbindung von Azure Synapse auf Snowflake um. Der native Power BI-Konnektor von Snowflake ist zertifiziert und wird empfohlen.
Testen Sie alle kritischen Berichte und Dashboards. Achten Sie genau auf Berichte, die DirectQuery verwenden, da sich die Leistungsmerkmale ändern werden.
Abfragen überprüfen und optimieren:
Einige Berichte können native T-SQL-Abfragen enthalten. Diese müssen umstrukturiert werden, um den SQL-Dialekt von Snowflake zu verwenden. Verwenden Sie das Query Profile-Tool in Snowflake und den Performance Analyzer in Power BI zur Optimierung von langsam ausgeführten Berichten.
Phase 7: Datenvalidierung und Testen¶
Gründliche Tests sind unerlässlich, um das Vertrauen der Kunden in die neue Plattform aufzubauen und sicherzustellen, dass Datenintegrität und -Performance den Erwartungen entsprechen.
Konkrete Schritte:
Datenvalidierung durchführen:
Zeilenzahlen: Vergleichen Sie die Zeilenanzahlen zwischen Quelltabellen in Synapse und Zieltabellen in Snowflake.
Validierung auf Zellenebene: Führen Sie für kritische Tabellen eine detailliertere Prüfung durch, indem Sie aggregierte Werte (SUM, AVG, MIN, MAX) in wichtigen Spalten vergleichen.
Abfrage- und Performance-Tests durchführen:
Benchmark-Abfragen: Führen Sie einen repräsentativen Satz von Abfragen sowohl gegen Synapse als auch gegen Snowflake aus und vergleichen Sie Ergebnisse und Performance.
BI-Tool-Performance: Testen Sie die Ladezeiten und die Interaktivität der wichtigsten Power BI-Dashboards, die mit Snowflake verbunden sind.
Benutzeraktualisierungstests (UAT):
Beziehen Sie Geschäftsanwender ein, um ihre Berichte zu validieren und ihre täglichen Aufgaben in der neuen Snowflake-Umgebung auszuführen.
Phase 8: Bereitstellung¶
Die Bereitstellung ist die letzte Umstellung von Azure Synapse auf Snowflake. Dieser Prozess sollte sorgfältig verwaltet werden, um Unterbrechungen des Geschäftsbetriebs zu minimieren.
Konkrete Schritte:
Übergangsplan erstellen:
Definieren Sie die Sequenz der Ereignisse für die Umstellung. Dazu gehört das Anhalten der ADF-Pipelines, die auf Synapse verweisen, das Durchführen einer finalen Datensynchronisation, das Umleiten aller Verbindungen sowie die Überprüfung des Systemzustands.
Endgültige Datensynchronisierung ausführen:
Führen Sie ein letztes inkrementelles Laden von Daten durch, um alle Datenänderungen zu erfassen, die während der Testphase aufgetreten sind.
Live gehen:
Stellen Sie alle Produktionsdatenpipelines und Benutzerverbindungen von Synapse auf Snowflake um.
Halten Sie die Synapse-Umgebung für eine kurze Zeit als Fallback verfügbar (aber wenn möglich pausiert), bevor die Stilllegung erfolgt.
Synapse stilllegen:
Sobald die Snowflake-Umgebung stabil und in der Produktion validiert wurde, können Sie Ihre Synapse-SQL-Pools stilllegen, um zusätzliche Kosten zu vermeiden.
Phase 9: Optimieren und ausführen¶
Diese letzte Phase ist ein fortlaufender Prozess der Verwaltung von Performance, Kosten und Governance in Ihrer neuen Snowflake-Umgebung.
Konkrete Schritte:
Performance- und Kostenoptimierung implementieren:
Optimale Warehouse-Größe festlegen: Überwachen Sie die Workload-Leistung kontinuierlich und passen Sie die Größe der virtuellen Warehouses entsprechend an. Dies ersetzt das Konzept der Skalierung von Synapse DWUs.
Aggressive Auto-Suspend-Richtlinien festlegen: Setzen Sie das Auto-Suspend-Timeout für alle Warehouses auf 60 Sekunden, um Kosten für ungenutzte Rechenzeit zu vermeiden.
Gruppierungsschlüssel verwenden: Analysieren Sie für sehr große Tabellen (mehrere Terabyte) Gruppierungsschlüssel, um die Performance hoch gefilterter Abfragen zu verbessern.
Langfristige FinOps und Governance einrichten:
Kosten überwachen: Verwenden Sie das ACCOUNT_USAGE-Schema und Ressourcenmonitore von Snowflake zur Verfolgung des Credit-Verbrauchs.
Sicherheit verbessern: Rollen und Berechtigungen werden regelmäßig überprüft. Implementieren Sie erweiterte Sicherheits-Features wie dynamische Datenmaskierung und Zeilenzugriffsrichtlinien für sensible Daten.
Anhang¶
Anhang 1: Snowflake im Vergleich zur Azure Synapse-Architektur¶
Feature |
Azure Synapse Analytics |
Snowflake |
|---|---|---|
Architektur |
Steuerknoten + Serverknoten (MPP für dedizierte Pools). Entkoppelter Speicher, aber entkoppelte Verarbeitung innerhalb eines Pools. |
Entkoppelte Datenverarbeitung, Speicher und Cloud-Services (Multi-Cluster, Shared Data). |
Speicher |
In Azure Data Lake Storage gespeicherte Daten, die vom SQL-Pool verwaltet werden. |
Zentraler Objektspeicher (Azure Blob) mit automatischer Mikropartitionierung. |
Server |
Dedizierte bereitgestellte SQL-Pools (skaliert nach DWUs) oder serverlose SQL-Pools (Zahlung pro Abfrage). |
Flexible, bedarfsgesteuerte virtuelle Warehouses (Computecluster). |
Parallelität |
Begrenzt durch DWU-Größe und maximale Anzahl der gleichzeitigen Abfrage-Slots (128) in einem dedizierten Pool. |
Hohe Parallelität durch Multi-Cluster-Warehouses, die automatisch eingerichtet werden. |
Skalierung |
Skalieren Sie dedizierte Pools, indem Sie DWUs ändern (kann einige Minuten dauern). Kann angehalten werden. |
Rechenleistung kann in Sekundenschnelle vertikal oder horizontal skaliert werden; der Speicher skaliert automatisch. |
Wartung |
Erfordert eine manuelle Pflege der Statistiken. Indizierungsstrategien erfordern Verwaltung. |
Vollständig verwaltet; Wartungsaufgaben wie Statistik und Komprimierung sind automatisiert. |
Anhang 2: Zuordnung von Datentypen¶
Azure Synapse (T-SQL) |
Snowflake |
Anmerkungen |
|---|---|---|
bigint |
BIGINT / NUMBER(19,0) |
|
int |
INT / NUMBER(10,0) |
|
smallint |
SMALLINT / NUMBER(5,0) |
|
tinyint |
TINYINT / NUMBER(3,0) |
|
bit |
BOOLEAN |
|
dezimal(p,s) / numerisch(p,s) |
NUMBER(P,S) |
|
Geld/Münzen |
NUMBER(19,4) / NUMBER(10,4) |
Die Best Practice ist, eine Zuordnung zu NUMBER vorzunehmen. |
float / real |
FLOAT |
|
date |
DATE |
|
datetime / datetime2 |
DATETIME / TIMESTAMP_NTZ |
TIMESTAMP_NTZ ist oft das bevorzugte Ziel. |
datetimeoffset |
TIMESTAMP_TZ |
|
smalldatetime |
DATETIME / TIMESTAMP_NTZ |
|
time |
TIME |
|
char(n)/varchar(n) |
VARCHAR(n) |
|
nchar(n) / nvarchar(n) |
VARCHAR(n) |
Snowflake verwendet standardmäßig UTF-8, sodass keine N-Präfixtypen benötigt werden. |
text/ntext |
VARCHAR |
Veraltete Typen; Zuordnung zu VARCHAR. |
binary(n)/varbinary(n) |
BINARY(n) |
|
uniqueidentifier |
VARCHAR(36) |
Speichern Sie als Zeichenfolge, und verwenden Sie UUID_STRING(), falls erforderlich. |
Anhangs 3: SQL und Funktionsunterschiede¶
Azure Synapse (T-SQL) |
Snowflake |
Anmerkungen |
|---|---|---|
GETDATE() |
CURRENT_TIMESTAMP() |
Snowflake bietet mehrere Funktionen für das aktuelle Datum/die aktuelle Uhrzeit. |
ISNULL(Ausdruck1, Ausdruck2) |
IFNULL(Ausdruck1, Ausdruck2) |
COALESCE ist der ANSI-Standard und funktioniert in beiden. |
TOP (n) |
LIMIT n |
Snowflake verwendet eine LIMIT-Klausel am Ende der Abfrage. |
IIF(bool, true, false) |
IFF(bool, true, false) |
Die Funktionalität ist identisch, der Name ist leicht unterschiedlich. |
DATEADD(Teil, Zahl, Datum) |
DATEADD(Teil, Zahl, Datum) |
Wird unterstützt, aber Datums-/Uhrzeitkomponenten können unterschiedliche Namen haben (z. B. tt vs. Tag). |
DATEDIFF(Teil, Anfang, Ende) |
DATEDIFF(Teil, Anfang, Ende) |
Wird unterstützt, aber Datums-/Uhrzeitkomponenten können unterschiedliche Namen haben. |
STRING_SPLIT |
SPLIT_TO_TABLE / SPLIT |
Snowflake bietet leistungsfähigere Funktionen zum Aufteilen von Zeichenfolgen. |
Prozedurale Sprache |
t-SQL (Gespeicherte Prozeduren) |
Snowflake Scripting, JavaScript, Java, Python |
DDL-Klauseln |
DISTRIBUTION, CLUSTERED COLUMNSTORE INDEX |
Keine. Ersetzt durch automatische Mikropartitionierung und optionale Gruppierungsschlüssel. |
Temperaturtabellen |
#temptable |
CREATE TEMPORARY TABLE |
Transaktionen |
BEGIN TRAN, COMMIT, ROLLBACK |
BEGIN, COMMIT, ROLLBACK |
Fehlerbehandlung |
TRY…CATCH |
BEGIN…EXCEPTION…END |