Snowpark Migration Accelerator: Praktische Übungen für die Migration

[Beachten Sie, dass dies auch Teil des Snowflake-Quickstarts für die End-to-End-Migration ist, der in den Snowflake-Quickstarts verfügbar ist.]

Das Verschieben der Logik und der Daten in einem Data Warehouse ist unerlässlich, um eine betriebsbereite Datenbank auf einer neuen Plattform zu erhalten. Um die Vorteile der neuen Plattform funktional nutzen zu können, müssen jedoch alle Pipelines, auf denen Daten innerhalb oder außerhalb dieser Datenplattform bewegt werden, ebenfalls neu positioniert oder neu plattformiert werden. Dies kann oft eine Herausforderung sein, da normalerweise eine Vielzahl von Pipelines verwendet wird. Diese HoL wird sich nur auf ein Problem konzentrieren, für das Snowflake eine gewisse Beschleunigung bieten kann. Beachten Sie jedoch, dass neue ETL- und Pipeline-Beschleuniger ständig weiterentwickelt werden.

Lassen Sie uns über die Pipeline und das Notebook sprechen, das wir in diesem Szenario verschieben. Zur Erinnerung: Dies ist eine SQL Server-Datenbank-Migration, die aber auf ein Proof of Concept beschränkt ist. Ein kleiner Data Mart in SQL Server wurde von AdventureWorks zu Snowflake verschoben. Es gibt ein grundlegendes Pipeline-Skript und ein Berichts-Notebook, das AdventureWorks als Teil dieses POC hinzugefügt hat. Hier ist eine Zusammenfassung der einzelnen Artefakte:

  • Das Pipeline-Skript wird in Python unter Verwendung von Spark geschrieben. Dieses Skript liest eine zugängliche Datei, die von einem älteren POS-System in einem lokalen Verzeichnis in regelmäßigen Abständen erzeugt und von einem Orchestrierungs-Tool ausgeführt werden. (So etwas wie Airflow, aber die Orchestrierung ist nicht Bestandteil des POC. Wir sind also nicht 100 %-ig sicher, was es ist.)

  • Das Notebook ist ein Berichts-Notebook, das aus der vorhandenen SQL Server-Datenbank und entsprechenden Berichten über einige zusammenfassende Kennzahlen liest.

Keine dieser Aufgaben ist zu komplex, aber beide stellen nur die Spitze des Eisbergs dar. Es gibt Hunderte von weiteren Pipeline-Skripten und -Notebooks, die sich auf andere Data Marts beziehen. Dieses POC verschiebt einfach diese beiden.

Beide verwenden Spark und greifen auf die SQL Server-Datenbank zu. Unser Ziel ist es also im Wesentlichen, die Vorgänge von Spark in Snowpark zu verschieben. Schauen wir mal, wie wir dies mit dem Snowpark Migration Accelerator (SMA) tun würden. Der SMA ist ein Partnertool von SnowConvert und ist auf demselben Konzept aufgebaut. Wir werden viele Schritte durchlaufen (die meisten davon werden ähnlich sein wie bei SnowConvert), aber beachten Sie, dass wir im Wesentlichen immer noch denselben Workflow von Bewertung -> Konvertierung -> Validierung durchlaufen, den wir bereits durchlaufen haben.

Hinweise zu dieser Umgebung für praktische Übungen

Diese praktischen Übungen verwenden den Snowpark Migration Accelerator und die Snowflake VS-Codeerweiterung. Um allerdings den größten Nutzen daraus zu ziehen, müssen Sie Python mit PySpark ausführen. Der einfachste Weg, dies zu tun, wäre das Starten einer Umgebung mit der Anaconda-Distribution. Diese enthält die meisten Pakete, die zur Ausführung des Codes in diesen praktischen Übungen benötigt werden.

Sie müssen noch die folgenden Ressourcen zur Verfügung stellen:

Ansonsten können Sie die praktischen Übungen immer noch mit einem Snowflake-Konto, dem SMA und der Snowflake VS-Codeerweiterung ausführen. Sie können nicht alles ausführen (insbesondere den Quellcode), aber Sie können alle konvertierten Elemente in Snowflake verwenden.

Beginnen wir nun damit, zu beurteilen, was wir haben.