Snowpark Migration Accelerator: Überlegungen zur Vorverarbeitung¶

Größe¶

Das SMA-Tool analysiert Quellcode und Textdateien, keine Datendateien. Beim Scannen großer Codebasen oder zahlreicher Dateien kann das Tool an Speichergrenzen auf Ihrem lokalen Rechner stoßen. Wenn Sie beispielsweise exportierten Code aus allen abhängigen Bibliotheken als Eingabedateien einbeziehen, dauert die Analyse deutlich länger. Beachten Sie, dass SMA nur Spark-spezifische Code-Referenzen identifiziert, unabhängig davon, wie viel Code Sie in den Scan einbeziehen.

Wir empfehlen, alle Codedateien zu sammeln, die:

• Regelmäßig als Teil eines automatisierten Prozesses ausgeführt werden

• Die zur Erstellung des Prozesses verwendet wurden (falls getrennt von der regulären Ausführung)

• Die benutzerdefinierte Bibliotheken sind, die von Ihrem Unternehmen entwickelt wurden und auf die entweder der Prozess oder seine Erstellungsskripte verweisen

Sie müssen keinen Code einfügen, der etablierte Bibliotheken von Drittanbietern (wie Pandas, Scikit-Learn oder andere) erstellt. Das Tool katalogisiert diese Referenzen automatisch, ohne dass Sie deren Definitionscode benötigen.

So wird es funktionieren¶

Der Snowpark Migration Accelerator (SMA) benötigt vollständigen und gültigen Quellcode, um ordnungsgemäß zu funktionieren. Er kann keine unvollständigen Codefragmente oder Snippets verarbeiten, die nicht unabhängig in Scala oder Python ausgeführt werden. Wenn Sie bei der Ausführung von SMA auf zahlreiche Parsing-Fehler stoßen, bedeutet dies wahrscheinlich, dass der Quellcode unvollständig ist oder Syntaxfehler enthält. Um eine erfolgreiche Analyse zu gewährleisten, stellen Sie sicher, dass Ihr Verzeichnis nur funktionierenden, syntaktisch korrekten Code von Ihrer Quellplattform enthält.

Anwendungsfall¶

Die SMA-Ausgabe zu verstehen, geht über das Tool selbst hinaus. Während SMA Ihre Codebasis analysiert, ist es wichtig, Ihren speziellen Anwendungsfall zu verstehen, um mögliche Herausforderungen bei der Migration zu erkennen. Wenn Sie beispielsweise ein Notebook haben, das SQL und einen Datenbank-Connector ohne Spark-Referenzen verwendet, wird SMA nur die in diesem Notebook verwendeten Bibliotheken von Drittanbietern melden. Diese Informationen sind nützlich, aber das Tool liefert keine Bereitschaftsbewertung für solche Dateien. Wenn Sie den Kontext Ihrer Anwendung kennen, können Sie diese Ergebnisse besser interpretieren.

Code aus Databricks Notebooks¶

Databricks Notebooks ermöglichen es Ihnen, Code in mehreren Programmiersprachen (SQL, Scala und PySpark) innerhalb desselben Notebooks zu schreiben. Wenn Sie ein Notebook exportieren, entspricht die Dateierweiterung der primären Sprachkategorie (.ipynb oder .py für Python-Notebooks, .sql für SQL-Notebooks). Jeder Code, der in einer anderen Sprache als der Hauptsprache des Notebooks geschrieben ist, wird beim Export automatisch auskommentiert. Wenn Sie z. B. SQL-Code in ein Python-Notebook schreiben, wird dieser SQL-Code auskommentiert, wenn Sie das Notebook exportieren.


Kommentare, die Code enthalten, werden von dem SMA-Tool nicht analysiert. Wenn Sie möchten, dass der Code innerhalb von Kommentaren analysiert wird, müssen Sie ihn zunächst vorverarbeiten, um den Code in einem Dateiformat darzustellen, das das Tool erkennen kann.

Bei der Arbeit mit Notebooks kann SMA-Code analysieren und erkennen, der in anderen Sprachen als der Dateierweiterung des Notebooks geschrieben wurde. Wenn Sie zum Beispiel SQL-Code in einem Jupyter-Notebook (.ipynb-Datei) haben, wird SMA diesen erkennen und verarbeiten, auch wenn der Code nicht kommentiert ist.

Achten Sie bei Dateien, die nicht in einem Notebook gespeichert sind, darauf, dass Ihr Code mit der richtigen Dateierweiterung gespeichert wird, die zur Quellsprache passt (speichern Sie beispielsweise Python-Code mit der Erweiterung .py). Dadurch wird sichergestellt, dass der Code ordnungsgemäß analysiert werden kann.