Snowpark Migration Accelerator: Notebook-Konvertierung¶
Wechseln wir zum Berichts-Notebook in unserer Codebasis: Einfaches Berichts-Notebook – SqlServer Spark.ipynb. Wir werden einen ähnlichen Satz von Schritten durchlaufen wie beim Pipeline-Skript.
Alle Probleme lösen: „Probleme“ bezeichnet hier die Probleme, die durch den SMA erzeugt werden. Werfen Sie einen Blick auf den Ausgabecode. Beheben Sie Parsing-Fehler und Konvertierungsfehler, und untersuchen Sie die Warnungen.
Sitzungsaufrufe auflösen: Wie der Sitzungsaufruf im Ausgabecode geschrieben wird, hängt davon ab, wo die Datei ausgeführt werden soll. Wir werden das Problem lösen, um die Codedateien an dem gleichen Speicherort auszuführen, an dem sie ursprünglich ausgeführt werden sollten, und um sie anschließend in Snowflake auszuführen.
Ein-/Ausgaben auflösen: Verbindungen zu verschiedenen Quellen können nicht vollständig durch den SMA aufgelöst werden. Es gibt Unterschiede zwischen den Plattformen, und der SMA wird dies in der Regel ignorieren. Dies wird auch davon beeinflusst, wo die Datei ausgeführt werden soll.
** Bereinigen und Testen **! Lassen Sie uns den Code ausführen. Überprüfen Sie, ob es funktioniert. Wir werden in diesen praktischen Übungen einfache Tests durchführen, aber es gibt Tools, mit denen Sie umfangreichere Tests und Datenvalidierungen durchführen können, einschließlich Snowpark Python Checkpoints.
Fangen wir an!
Alle Probleme lösen¶
Im Weiteren werden wir uns die Probleme mit dem Notebook ansehen.
(Beachten Sie, dass Sie das Notebook in VS Code öffnen können, aber um es angemessen anzuzeigen, sollten Sie die Jupyter-Erweiterung für VS Code installieren. Alternativ können Sie dieses auch in Jupyter öffnen, aber Snowflake empfiehlt weiterhin VS Code mit installierter Snowflake-Erweiterung).
Sie können das Vergleichs-Feature verwenden, um beide Seite an Seite anzuzeigen, wie wir es mit der Pipeline-Datei getan haben, obwohl sie dann eher wie eine JSON-Datei aussieht:

Beachten Sie, dass es nur zwei eindeutige EWIs in diesem Notebook gibt. Sie können zur Suchleiste zurückkehren, um sie zu finden, aber da dies so kurz ist, können Sie auch einfach nach unten scrollen. Dies sind die spezifischen Probleme:
SPRKPY1002 => pyspark.sql.readwriter.DataFrameReader.jdbc wird nicht unterstützt. Dies ist ein ähnliches Problem wie das, das wir in der Pipeline-Datei gesehen haben, aber das war ein Schreibaufruf. Dies ist ein Leseaufruf für die SQL-Serverdatenbank. Wir werden dies gleich lösen.
SPRKPY1068 => „pyspark.sql.dataframe.DataFrame.toPandas wird nicht unterstützt, wenn es Spalten des Typs ArrayType gibt. Eine Problemumgehung ist allerdings vorhanden. Weitere Informationen dazu finden Sie in der Dokumentation. Dies ist eine weitere Warnung. Wenn wir dieser Funktion in Snowpark ein Array übergeben, funktioniert es möglicherweise nicht. Achten Sie darauf, wenn wir es testen.
Und das war’s für das Notebook und unsere Probleme. Wir haben einen Parsing-Fehler behoben und erkannt, dass wir die Ein-/Ausgaben korrigieren müssen. Weiterhin gibt es ein paar potenzielle Funktionsunterschiede, die wir im Blick behalten sollten. Lassen Sie uns zum nächsten Schritt übergehen: dem Auflösen aller Sitzungsaufrufe.
Sitzungsaufrufe auflösen¶
Um die Sitzungsaufrufe im Berichts-Notebook zu aktualisieren, müssen wir die Zelle suchen, die den Sitzungsaufruf enthält. Das sieht wie folgt aus:

Lassen Sie uns nun das tun, was wir bereits für unsere Pipeline-Datei getan haben:
Ändern Sie alle Verweise auf die Sitzungsvariable „spark“ in „session“ (beachten Sie, dass dies im gesamten Notebook der Fall ist).
Entfernen Sie die Konfigurationsfunktion mit dem Spark-Treiber.
Das Vorher und Nachher sieht wie folgt aus:
# Old Session
spark = Session.builder.config('spark.driver.extraClassPath', driver_path).app_name("AdventureWorksSummary", True).getOrCreate()
spark.update_query_tag({"origin":"sf_sit","name":"sma","version":{"major":7,"minor":4,"patch":10},"attributes":{"language":"Python"}})
# New Session
# Session
session = Session.builder.app_name("AdventureWorksSummary", True).getOrCreate()
session.update_query_tag({"origin":"sf_sit","name":"sma","version":{"major":7,"minor":4,"patch":10},"attributes":{"language":"Python"}})
Beachten Sie, dass sich in dieser Zelle anderer Code befindet. Dieser Code:
url = sql_server_url
properties = {'user' : sql_server_user, 'password' : sql_server_password}
# Spark dataframe.
#EWI: SPRKPY1002 => pyspark.sql.readwriter.DataFrameReader.jdbc is not supported
df = session.read.jdbc(url = url, table = 'dbo.DimCustomer', properties = properties)
print('Session successfully setup.')
Wir sind fast bereit, die Anweisung zum Lesen zu übernehmen, aber wir sind noch nicht dort. Lassen Sie uns das alles in eine andere Zelle verschieben. Erstellen Sie eine neue Zelle unterhalb dieser Zelle, und verschieben Sie diesen Code in diese Zelle. Diese wird wie folgt aussehen:

Ist das alles, was wir für den Sitzungsaufruf benötigen? Nein. Rufen Sie die vorherige Seite unter Anmerkungen zu Sitzungsaufrufen auf (und überprüfen Sie sie möglicherweise). Sie müssen entweder sicherstellen, dass Ihre Datei „connection.toml“ Ihre Verbindungsinformationen enthält, oder Sie müssen die Verbindungsparameter, die Sie in der Sitzung verwenden möchten, explizit angeben.
Auflösen der Eingaben/Ausgaben¶
Lassen Sie uns nun unsere Ein- und Ausgaben auflösen. Beachten Sie, dass dies je nachdem, ob Sie die Dateien lokal oder in Snowflake ausführen, unterschiedlich ist. Beim Notebook kann jedoch alles lokal oder in Snowflake ausgeführt werden. Der Code wird etwas einfacher sein, da wir nicht einmal eine Sitzung aufrufen müssen. Wir erhalten nur die aktive Sitzung. Wie bei der Pipeline-Datei werden wir dies in zwei Teilen tun: für die lokale Ausführung/Orchestrierung und für die Ausführung in Snowflake.
Die Bearbeitung der Ein- und Ausgaben im Berichts-Notebook wird wesentlich einfacher sein als dies bei der Pipeline war. Es erfolgt kein Lesen aus einer lokalen Datei oder Verschieben von Daten zwischen Dateien. Es wird einfach aus einer Tabelle in SQL Server gelesen, was nun ein Lesevorgang aus einer Tabelle in Snowflake ist. Da wir nicht auf SQL Server zugreifen werden, können wir alle Verweise auf die Eigenschaften von SQL Server weglassen. Die Leseanweisung kann in Snowflake durch eine Tabellenanweisung ersetzt werden. Das Vorher und Nachher für diese Zelle sollte wie folgt aussehen:
# Before
url = sql_server_url
properties = {'user' : sql_server_user, 'password' : sql_server_password}
# Spark dataframe.
#EWI: SPRKPY1002 => pyspark.sql.readwriter.DataFrameReader.jdbc is not supported
df = session.read.jdbc(url = url, table = 'dbo.DimCustomer', properties = properties)
print('Session successfully setup.')
# After
# New table call
# Snowpark Dataframe table.
df = session.table('ADVENTUREWORKS.DBO.DIMCUSTOMER')
print('Table loaded successfully.')
df.show()

Das ist es tatsächlich. Im Weiteren werden wir mit dem Teil „ Bereinigen und Testen“ der Notebook-Datei fortfahren.
Bereinigen und Testen¶
Lassen Sie uns einige Bereinigungen vornehmen (wie zuvor für die Pipeline-Datei). Wir haben uns unsere Importaufrufe nie angesehen und wir haben Konfigurationsdateien, die überhaupt nicht notwendig sind. Beginnen wir damit, die Verweise auf die Konfigurationsdateien zu entfernen. Dies wird jede der Zellen zwischen den Importanweisungen und dem Sitzungsaufruf sein.

Schauen wir uns nun unsere Importe an. Der Verweis auf das BS kann gelöscht werden. (Scheint so, als wurde dies auch nicht in der Originaldatei verwendet …) Es gibt eine pandas-Referenz. Es scheint, dass es in diesem Notebook keine Verwendung von pandas mehr gibt, da auf die Konfigurationsdateien verwiesen wird. Es gibt eine toPandas-Referenz als Teil der Snowpark-Datenframe-API im Berichtsbereich, aber das ist nicht Bestandteil der pandas-Bibliothek.
Sie können optional alle Importaufrufe von Pandas durch die modin pandas-Bibliothek ersetzen. Diese Bibliothek optimiert die pandas-Datenframes, um die Vorteile des Powerhouse Computing von Snowflake zu nutzen. Diese Änderung würde wie folgt aussehen:
# Old
import pandas as pd
# New
import modin.pandas as pd
import snowflake.snowpark.modin.plugin
Allerdings können wir diese auch löschen. Beachten Sie, dass der SMA alle Spark-spezifischen Importanweisungen durch solche ersetzt hat, die sich auf Snowpark beziehen. Die endgültige Importzelle würde wie folgt aussehen:

Und das war’s für unsere Bereinigung. Wir haben immer noch ein paar EWIs in den Berichts- und Visualisierungszellen, aber es sieht so aus, als sollten wir es schaffen. Lassen Sie uns diese ausführen und sehen, ob wir eine Ausgabe erhalten.

Und das haben wir getan. Die Berichte scheinen mit der Ausgabe des Spark Notebooks übereinzustimmen. Auch wenn die Berichtszellen komplex erscheinen, kann Snowpark mit ihnen arbeiten. Der SMA teilt uns mit, dass es ein Problem geben könnte, aber es scheint keine Probleme zu geben. Weitere Tests würden helfen, aber die erste Runde der einfachen Tests ist bestanden.
Schauen wir uns nun dieses Notebook in Snowsight an. Im Gegensatz zur Pipeline-Datei können wir dies vollständig in Snowsight tun.
Ausführen des Notebooks in Snowsight¶
Nehmen wir die Version des Notebooks, die wir gerade haben (nachdem wir die Probleme, die Sitzungsaufrufe und die Ein- und Ausgaben gelöst haben) und laden sie in Snowflake. Um dies zu tun, gehen Sie in SnowSight zum Abschnitt „Notebooks“:

Wählen Sie oben rechts neben der Schaltfläche „+Notebook“ den Pfeil nach unten, und wählen Sie „.ipynb-Datei importieren“ (siehe oben) aus.
Sobald diese importiert wurde, wählen Sie die Notebook-Datei aus, mit der wir in dem Ausgabeverzeichnis arbeiteten, das vom SMA in Ihrem Projektordner erstellt wurde.
Es öffnet sich ein Dialogfenster zum Erstellen eines Notebooks. Für diesen Upload wählen wir die folgenden Optionen:
Notebook-Speicherort:
Datenbank: ADVENTUREWORKS
Schema: DBO
Python-Umgebung: Auf Warehouse ausführen
Dies ist kein großes Notebook mit einer Menge von ML. Dies ist ein einfaches Berichts-Notebook. Wir können dies auf einem Warehouse ausführen.
Abfrage-Warehouse: DEFAULT_WH
Notebook-Warehouse: DEFAULT_WH (Sie können es als das vom System gewählte Warehouse belassen (wird ein Streamlit-Warehouse sein)… für dieses Notebook wird es keine Rolle spielen)
Sie können diese Auswahl unten sehen:

Dadurch sollte Ihr Notebook in Snowflake geladen werden und ungefähr so aussehen:

Es gibt ein paar schnelle Überprüfungen/Änderungen, die wir an der Version vornehmen müssen, die wir gerade lokal getestet haben, um sicherzustellen, dass das Notebook in Snowsight läuft:
Ändern der Sitzungsaufrufe, um die aktive Sitzung abzurufen
Sicherstellen dass alle abhängigen Bibliotheken, die wir installieren müssen, verfügbar sind
Beginnen wir mit dem ersten Punkt. Es erscheint vielleicht seltsam, den Aufruf der Sitzung erneut zu ändern, nachdem wir schon so viel Zeit damit verbracht haben, aber jetzt erfolgt die Ausführung innerhalb von Snowflake. Sie können alles, was mit dem Lesen des Sitzungsaufrufs verbunden ist, entfernen und durch den Aufruf „get_active_session“ ersetzen, der oben in den meisten Snowflake-Notebooks Standard ist:
//# Old for Jupyter
session = Session.builder.app_name("AdventureWorksSummary", True).getOrCreate()
# New for Snowsight
from snowflake.snowpark.context import get_active_session
session = get_active_session()
Wir müssen keine Verbindungsparameter angeben oder eine .toml-Datei aktualisieren, da wir bereits verbunden sind. Wir befinden uns in Snowflake.
Lassen Sie uns den alten Code in der Zelle durch den neuen Code ersetzen. Das sieht ungefähr so aus:

Lassen Sie uns nun die für diese Ausführung verfügbaren Pakete verwenden. Es liegt aber nicht an uns herauszufinden, was wir hinzufügen müssen. Das überlassen wir Snowflake. Einer der besten Aspekte der Verwendung eines Notebooks ist, dass wir einzelne Zellen ausführen und sehen können, wie die Ergebnisse aussehen. Lassen Sie uns die Zelle für die Importbibliothek ausführen.
Wenn Sie dies noch nicht getan haben, starten Sie die Sitzung, indem Sie in der rechten oberen Ecke des Bildschirms auf „Start“ klicken:

Wenn Sie die oberste Zelle im Notebook ausführen, werden Sie wahrscheinlich feststellen, dass „matplotlib“ nicht in die Sitzung geladen wurde:

Dies ist eine sehr wichtige Meldung für dieses Notebook. Sie können diese Bibliothek zu Ihrem Notebook/Ihrer Sitzung hinzufügen, indem Sie die Option „Pakete“ oben rechts im Notebook verwenden:

Suchen Sie nach matplotlib, und wählen Sie es aus. Dadurch wird dieses Paket in der Sitzung verfügbar gemacht.

Sobald Sie diese Bibliothek geladen haben, müssen Sie die Sitzung neu starten. Nachdem Sie die Sitzung neu gestartet haben, führen Sie diese erste Zelle erneut aus. Sie werden wahrscheinlich erfahren, dass es dieses Mal erfolgreich war.

Wenn die Pakete geladen, die Sitzung korrigiert und die restlichen Probleme im Code bereits behoben sind: Was können wir tun, um den Rest des Notebooks zu überprüfen? Führen Sie es aus! Sie können alle Zellen im Notebook ausführen, indem Sie in der oberen rechten Ecke des Bildschirms „Alle ausführen“ wählen, und sehen, ob wir einen Fehler erhalten.
Es sieht so aus, als wäre die Ausführung erfolgreich:

Wenn Sie die Ausführung der beiden Notebooks vergleichen, sieht es so aus, als ob der einzige Unterschied darin besteht, dass bei der Snowflake-Version alle Ausgabe-Datensets zuerst gesetzt werden, gefolgt von den Bildern, während sie im Spark Jupyter-Notebook vermischt werden:

Beachten Sie, dass dieser Unterschied kein API-Unterschied ist, sondern ein Unterschied, wie Notebooks in Snowflake dies orchestrieren. Dies ist wahrscheinlich ein Unterschied, den AdventureWorks bereit ist zu akzeptieren.
Schlussfolgerungen¶
Durch die Verwendung des SMA konnten wir die Migration sowohl einer Datenpipeline als auch eines Berichts-Notebooks beschleunigen. Je mehr von jedem Sie haben, desto mehr Wert ist ein Tool wie SMA.
Lassen Sie uns zum Ablauf Bewertung -> Konvertierung -> Validierung zurückkehren, auf den wir immer wieder zurückkommen. Bei dieser Migration tun wir Folgendes:
Einrichten unseres Projekts im SMA
Ausführen der SMA-Bewertungs- und Konvertierungs-Engine für die Codedateien
Überprüfen des Ausgabeberichts vom SMA, um besser zu verstehen, was wir haben
Überprüfen, was vom SMA nicht in VS Code konvertiert werden konnte
Beheben von Problemen und Fehlern
Auflösen von Sitzungsreferenzen
Auflösen von Eingabe-/Ausgabereferenzen
Lokales Ausführen des Codes
Ausführen des Codes in Snowflake
Ausführen der neu migrierten Skripte aus und Validieren des Erfolgs
Snowflake hat viel Zeit darauf verwendet, seine Datenaufnahme- und Data-Engineering-Fähigkeiten zu verbessern, und genauso viel Zeit aufgewendet, um Migrationstools wie SnowConvertund SnowConvert Migration Assistant sowie den Snowpark Migration Accelerator zu verbessern. Jedes dieser Tools wird sich weiter verbessern. Wenn Sie Vorschläge für ein Migrationstool haben, wenden Sie sich an uns. Diese Teams sind immer auf der Suche nach zusätzlichem Feedback, um die Tools zu verbessern.