Leitfaden zur Migration von Teradata zu Snowflake¶

Phase 1: Planung und Design¶

Diese Phase ist der entscheidende erste Schritt für eine erfolgreiche Snowflake-Migration. Sie bildet die Grundlage für den gesamten Migrationsprozess, indem sie den Umfang, die Ziele und die Anforderungen definiert. Diese Phase beinhaltet ein großes Verständnis der aktuellen Umgebung und eine klare Vorstellung von dem zukünftigen Zustand von Snowflake.

Während dieser Phase identifizieren Organisationen die wichtigsten geschäftlichen Faktoren und technischen Ziele für die Migration zu Snowflake, indem sie die folgenden Aufgaben ausführen:

Phase 2: Umgebung und Sicherheit¶

Einer der ersten Schritte, die wir empfehlen, ist die Einrichtung der notwendigen Umgebungen und Sicherheitsmaßnahmen, um mit der Migration zu beginnen. Vieles spielt zusammen – beginnen wir also mit der Sicherheit. Wie bei jeder Cloudplattform arbeitet Snowflake nach einem gemeinsamen Sicherheitsmodell zwischen der Plattform und Administratoren.

Phase 3: Konvertieren von Datenbankcode¶

SnowConvert AI versteht den Teradata-Quellcode und konvertiert die Data Definition Language (DDL), Data Manipulation Language (DML) und Funktionen im Quellcode auf das entsprechende SQL im Ziel: Snowflake SnowConvert AI kann den Quellcode in jedem dieser drei Formate migrieren: .sql, .dml oder .ddl.

In dieser Phase wird Code direkt aus dem Datenbankkatalog der Quellsysteme extrahiert, z. B. Tabellendefinitionen, Ansichten, gespeicherte Prozeduren und Funktionen. Sobald Sie diesen Code extrahiert haben, migrieren Sie den gesamten Code in die entsprechende DDLs (Data Definition Language) in Snowflake. Dieser Schritt umfasst auch die Migration von DML (Data Manipulation Language)-Skripten, die von Geschäftsanalysten zum Erstellen von Berichten oder Dashboards verwendet werden.

Lesen Sie unsere empfohlenen Extraktionsskripte hier

Teradaten DDL enthält typischerweise Verweise auf Primärindizes, Fallback oder Partitionierung. In Snowflake existieren diese Strukturen nicht auf dieselbe Weise:

• [Verwenden Sie SnowConvert AI für Teradata] (https://www.snowflake.com/en/migrate-to-the-cloud/snowconvert/), das den Konvertierungsprozess der Data Definition Language (DDL) erheblich vereinfacht, insbesondere bei einer großen Anzahl von Tabellen. Es automatisiert die Übersetzung der spezifischen Teradata-DDL-Konstrukte, wie Primärindexdefinitionen und Fallback-Optionen, in die entsprechenden Strukturen von Snowflake. Diese Automatisierung reduziert den manuellen Aufwand und minimiert das Fehlerrisiko, sodass sich die Teams auf die übergeordnete Migrationsstrategie und die Validierung konzentrieren können. Über die grundlegende DDL-Konvertierung hinaus behandelt SnowConvert AI auch Feinheiten wie die Zuordnung von Datentypen und die Umstrukturierung von Schemas. Es kann Datentypen automatisch an die in Snowflake verfügbaren Typen anpassen und dabei helfen zu entscheiden, ob Schemas für optimale Performance und eine bessere Verwaltung zusammengeführt oder aufgeteilt werden sollten. Dieser umfassende Ansatz stellt sicher, dass die migrierte Datenbankstruktur nicht nur funktionsfähig, sondern auch für die -Architektur von Snowflake optimiert ist.

• Passen Sie die Datentypen bei Bedarf an oder verwenden Sie den Migrations AI-Assistenten, um etwaige Fehler oder Warnungen (EWI, Errors oder Warnings) zu beheben.

• Entscheiden Sie, ob Schemas reorganisiert werden sollen (z. B. Aufteilen großer, monolithischer Schemas in mehrere Snowflake-Datenbanken).

Phase 4: Datenmigration¶

Zunächst ist es wichtig, zwischen der Migration historischer Daten und dem Hinzufügen neuer Daten zu unterscheiden. Die historische Datenmigration bezieht sich darauf, eine Momentaufnahme der Daten zu einem bestimmten Zeitpunkt zu erstellen und diese nach Snowflake zu übertragen. Wir empfehlen, zunächst eine exakte Kopie der Daten zu erstellen, ohne eine Transformation in Snowflake vorzunehmen. Durch diese erste Kopie wird die alte Plattform etwas ausgelastet, sodass Sie sie nur einmal ausführen und in Snowflake speichern sollten.

Ihre umführbaren Schritte:

• Migration historischer Daten durchführen: Erstellen Sie eine Momentaufnahme Ihrer Teradata-Daten zu einem bestimmten Zeitpunkt und übertragen Sie sie nach Snowflake – häufig als anfängliche Massenübertragung. Es wird empfohlen, zunächst eine exakte Kopie ohne Transformation zu erstellen.

• Inkrementelle Datenmigration planen: Richten Sie nach der ersten historischen Migration Prozesse ein, um neue oder geänderte Daten von Teradata kontinuierlich in Snowflake zu verschieben und Ihre Snowflake-Umgebung auf dem neuesten Stand zu halten.

Phase 5: Datenaufnahme¶

Bei der Pipeline-Migration zu Snowflake wird die auf Teradaten basierende Logik verschoben oder neu geschrieben, z. B. BTEQ-Skripte, gespeicherte Prozeduren, Makros oder spezielle ETL-Flüsse. Dies umfasst eine Orchestrierungsumstellung, bei der BTEQ- oder geplante Teradata-Jobs durch Streams und Tasks in Snowflake ersetzt werden, um inkrementelle Transformationen durchzuführen. Es erfordert außerdem eine Quell-/Ziel-Neuausrichtung, bei der mehrere eingehende Datenquellen, die bisher in Teradata landeten, auf Snowflake-Einbindungsmuster (COPY, Snowpipe) umgeleitet werden.

Während der Phase der Abfragekonvertierung und -optimierung wird Teradata SQL in Snowflake SQL konvertiert, was das Ersetzen von Makros durch gespeicherte Prozeduren oder Ansichten und das Umschreiben von QUALIFY-Logik sowie das Anpassen von gespeicherten Prozeduren und Verknüpfungsindizes umfassen kann. SnowConvert AI für Teradata kann einen großen Teil dieser Übersetzung automatisieren.

Da sich die Daten nun in Snowflake befinden, folgt der nächste Schritt: die Migration oder Neuschreibung der Teradata-basierten Logik – etwa BTEQ-Skripte, gespeicherte Prozeduren, Makros oder spezialisierte ETL-Flows.

Phase 6: Berichterstattung und Analyse¶

Da wir nun eine Datenbank mit historischen Daten und Live-Pipelines haben, die kontinuierlich neue Daten importieren, besteht der nächste Schritt darin, Wert aus diesen Daten mithilfe von Business Intelligence (BI) zu extrahieren. Die Berichterstellung kann mit Standard-BI-Tools oder benutzerdefinierten Abfragen erfolgen. In beiden Fällen muss das an die Datenbank gesendete SQL möglicherweise angepasst werden, um den Anforderungen von Snowflake zu entsprechen. Diese Anpassungen können von einfachen Namensänderungen (die während der Migration häufig sind) bis hin zu Syntaxunterschieden und komplexeren semantischen Unterschieden reichen. Sie alle müssen identifiziert und behandelt werden.

Wie beim Einbindungsprozess ist es entscheidend, die Nutzung der Altsystemplattform vollständig zu überprüfen und die daraus gewonnenen Erkenntnisse in den Migrationsplan einfließen zu lassen. Im Allgemeinen gibt es zwei Arten von Berichten, die berücksichtigt werden sollten: IT-eigene Berichte und geschäftseigene Berichte. Berichte, die von der IT verwaltet werden, lassen sich in der Regel leichter nachverfolgen, aber von Fachbereichen erstellte Berichte und komplexe Abfragen von Business-Usern erfordern einen anderen Ansatz.

Business-User sind wichtige Interessengruppen im Migrationsprozess und sollten in der RACI-Matrix während der Planungsphase berücksichtigt werden. Sie müssen in der Funktionsweise von Snowflake trainiert werden und die Unterschiede der Plattform genau verstehen. Auf diese Weise können sie ihre kundenspezifischen Abfragen und Berichte bei Bedarf ändern. Wir empfehlen in der Regel einen parallelen Schulungspfad für Business-User, gefolgt von offenen Sprechstunden mit Migrationsexperten, die dabei helfen, Plattformunterschiede zu erklären und die Benutzer bei den notwendigen Anpassungen zu unterstützen.

Die Geschäftsanwender sind letztendlich diejenigen, die die Migration „akzeptieren“. Sie haben die technische Migration möglicherweise aus IT-Sicht abgeschlossen, aber wenn die Business-User nicht einbezogen werden, verlassen sie sich möglicherweise weiterhin auf Tausende von Berichten, die für den Geschäftsbetrieb entscheidend sind. Wenn diese Berichte nicht so aktualisiert werden, dass sie mit Snowflake funktionieren, kann das Unternehmen nicht vollständig von der Altsystemplattform weg migrieren.

Teradata SQL hat einige Konstrukte, die nicht in Snowflake enthalten sind, und umgekehrt. Unterschiede:

• Macros: Nicht unterstützt von Snowflake; werden in der Regel durch gespeicherte Prozeduren oder Ansichten ersetzt.

• QUALIFY: Snowflake unterstütz QUALIFY nicht direkt. Schreiben Sie die Logik mithilfe einer Unterabfrage oder eines Outer-SELECT um.

• Gespeicherte Prozeduren: Teradata SP vs. Snowflake SP (SQL oder JavaScript-basiert). Die prozedurale Sprache unterscheidet sich.

• Join-Indizes: Haben kein direktes Äquivalent; verlassen sich auf das Bereinigen von Mikropartitionen und Gruppierungsschlüsseln.

• COLLECT STATISTICS: Teradata verwendet explizite Statistiken, während Snowflake diesen Prozess automatisch durchführt.

SnowConvert AI für Teradata wird für die automatisierte Übersetzung empfohlen. Sie kann Makros, gespeicherte Prozeduren und BTEQ-Skripte verarbeiten, die Snowflake-kompatiblen Code ausgeben.

Phase 7: Datenvalidierung und -tests¶

Dies führt uns zur Datenvalidierung und -tests, zwei oft unterschätzten Schritten bei der Migrationsplanung. Natürlich ist das Ziel, die Daten so gut zu bereinigen wie möglich, bevor diese Phase beginnt.

Jedes Unternehmen hat seine eigenen Testmethoden und Anforderungen, um Daten in die Produktion zu verschieben. Diese müssen von Beginn des Projekts an vollständig verstanden werden. Was sind also nützliche Strategien für die Datenvalidierung?

• Durchführen umfassender Tests bei der Snowflake-Migration: Während des Snowflake-Migrationsprozesses müssen umfassende Tests durchgeführt werden, einschließlich:

  1. Funktionstests: Überprüfen, ob alle migrierten Anwendungen und Funktionalitäten in der neuen Umgebung wie erwartet funktionieren, um Datenintegrität und -genauigkeit sicherzustellen.

  2. Performance-Tests: Zur Bewertung der Abfrage-Performance, der Geschwindigkeit beim Laden von Daten und der allgemeinen Reaktionsfähigkeit des Systems, um Performance-Engpässe zu erkennen und zu beheben.

  3. Benutzerakzeptanztests (UAT): Einbeziehung der Endbenutzer in den Testprozess, um sicherzustellen, dass das migrierte System deren Anforderungen entspricht, und um Feedback für mögliche Verbesserungen zu sammeln.

• Bereitstellen von Training und Dokumentation für die Snowflake-Migration:

  • Umfassende Schulungen für Endbenutzer zu Features, Funktionen und Best Practices von Snowflake zu Themen wie Datenzugriff, Abfrageoptimierung und Sicherheit.

  • Erstellen Sie eine umfassende Dokumentation, einschließlich Abbildungen der Systemarchitektur, Datenflussdiagramme, betriebliche Prozeduren, Benutzerhandbücher, Anleitungen zur Problembehandlung und FAQs zum einfachen Verweisen.

Phase 8: Bereitstellung¶

Wenn Sie schließlich für die Umstellung bereit sind, stellen Sie sicher, dass alle Interessengruppen auf einer Liste abgestimmt sind und verstehen, dass von diesem Zeitpunkt an Snowflake das System der Datensätze und nicht die alte Plattform sein wird. Sie benötigen die endgültigen und formalen Genehmigungen aller Beteiligten, bevor Sie fortfahren. Für alle Berichte, die nicht migriert wurden, sind nun die Geschäftsanwender verantwortlich. Aus diesem Grund ist es wichtig, die Benutzer nicht erst in letzter Minute einzubeziehen – Sie sollten von Anfang an in den Prozess einbezogen werden und sich des Zeitrahmens der Migration bewusst sein.

Überprüfen Sie außerdem, ob alle Berechtigungen ordnungsgemäß gewährt wurden. Wenn Sie z. B. Active Directory-basierte Rollen verwenden, stellen Sie sicher, dass diese in Snowflake erstellt und konfiguriert werden.

Einige zusätzliche Szenarien werden normalerweise bis zum Schluss aufgeschoben, sollten jedoch nicht übersehen werden:

• Ersatzschlüssel: Wenn Sie Ersatzschlüssel verwenden, beachten Sie, dass sich deren Lebenszyklus zwischen dem Altsystem und Snowflake unterscheiden kann. Diese Schlüssel müssen während der Umstellung synchronisiert werden.

• Cutover-Zeitpunkt: Abhängig von Ihrer Branche kann es im Laufe des Jahres mehr oder weniger erfolgreiche Zeitpunkte für die Durchführung einer Umstellung geben. Prüfen Sie den Zeitpunkt sorgfältig.

• Legacy-Plattformlizenz: Vergessen Sie nicht, dass Ihnen im Zusammenhang mit der Lizenz der alten Plattform möglicherweise strenge Fristen gesetzt werden. Achten Sie darauf, dass Sie bei der Umstellung solche Fristen berücksichtigen.

Phase 9: Optimieren und ausführen¶

Sobald ein System auf Snowflake migriert wurde, wechselt es in den normalen Wartungsmodus. Alle Softwaresysteme sind lebende Organismen, die eine laufende Wartung benötigen. Wir bezeichnen diese Phase nach der Migration als „Optimieren“ und „Ausführen“ und betonen, dass sie nicht Teil der Migration selbst ist.

Optimierung und kontinuierliche Verbesserung sind fortlaufende Prozesse, die nach der Migration stattfinden. Zu diesem Zeitpunkt übernimmt Ihr Team die volle Eigentümerschaft für das System in Snowflake. Das System wird sich weiter weiterentwickeln, und die Optimierung wird von Nutzungsmustern bestimmt.

Im Allgemeinen stellen wir fest, dass Jobs in Snowflake tendenziell schneller ausgeführt werden als auf den ursprünglichen Plattformen. Wenn die Leistung nicht den Erwartungen entspricht, müssen Sie möglicherweise einige Optimierungen vornehmen, um die einzigartige Architektur von Snowflake voll auszunutzen. Snowflake bietet verschiedene Abfrageanalyse-Tools, die helfen können, Engpässe zu identifizieren und gezielt bestimmte Teile des Workflows zu optimieren.

Während der Optimierungsphase müssen Sie möglicherweise verschiedene Aspekte des Systems erneut berücksichtigen. Der Vorteil ist, dass Sie bereits von den Möglichkeiten von Snowflake profitieren und Optimierungsaufgaben Teil Ihrer regelmäßigen Wartungsarbeiten werden.

Es wird empfohlen, sich in der Migrationsphase nur auf die Behebung kritischer Performance-Probleme zu konzentrieren. Die Optimierung wird am besten nach der Migration durchgeführt.

Anhang 1: Teradata-Datenbanken, die bei der Migration zu Snowflake ausgeschlossen werden sollen¶

Die folgende Liste von Datenbanken wird nur für Teradata benötigt und sollte nicht nach Snowflake migriert werden:

Anhang 2: Teradata-Datentypen zu Snowflake-Datentypen¶