Snowpark Migration Accelerator: Praktische Übungen für Pipeline – Bewertung¶
Wie bei SnowConvert führen wir den Code über den SMA aus, werten das Ergebnis aus, beheben alle Probleme und führen den Code auf der neuen Plattform aus. Im Gegensatz zu SnowConvert stellt der SMA NOTKEINE Verbindung zu einer Quellplattform her, und es wird auch keine Verbindung zu Snowflake hergestellt. Es handelt sich um eine lokale Anwendung, die vollständig offline ausgeführt werden kann. Die Leistungsfähigkeit liegt aber in der entsprechenden Bewertung. Der meiste Aufwand hinsichtlich der Konvertierung wurde für die Erstellung der Kompatibilität zwischen der Spark API und der Snowpark API betrieben.
Verfügbarkeit von Extraktion/Code¶
Die Dateien, die wir für die praktischen AdventureWorks-Übungen verwenden werden, sind hier:
end_to_end_lab_source_code.zip
Für die Zwecke dieser praktischen Übungen gehen wir davon aus, dass das Notebook und die Skriptdatei, die wir konvertieren, bereits als Dateien zugänglich sind. Im Allgemeinen nimmt der SMA Dateien als Eingabe entgegen und stellt keine Verbindung zu einer Quellplattform her. Wenn die Dateien von einem bestimmten -Tool orchestriert werden, müssen Sie sie möglicherweise exportieren. Wenn Sie Notebooks als Teil von Databricks oder EMR verwenden, können Sie diese als .ipynb-Dateien exportieren, genau wie das Jupyter-Notebook, das wir heute über den SMA ausführen werden.
Diese praktischen Übungen enthalten nur wenige Dateien, aber bei einer großen Migration ist es üblich, dass Sie Hunderte oder Tausende von Dateien haben. Extrahieren Sie, was Sie können, und führen Sie diese Dateien über den SMA aus. Das Besondere an der Verwendung eines Tools wie diesem ist, dass es Ihnen sagen kann, was Ihnen möglicherweise fehlt.
Beachten Sie, dass es auch eine Datendatei gibt: „customer_update.csv“. Dies ist ein Beispiel für die Datei, die lokal vom Point of Sale (POS)-System generiert wird, das Adventure Works derzeit verwendet. Während dieses System ebenfalls aktualisiert wird, konzentriert sich dieser Proof of Concept (POC) darauf, dass die bestehende Pipeline mit Snowpark statt mit Spark funktioniert.
Nehmen wir jede dieser Dateien und legen sie in einem einzigen Verzeichnis auf unserem lokalen Computer ab:
Es wird empfohlen, ein Projektverzeichnis zu erstellen. Dies kann genannt werden, wie Sie möchten, aber als Empfehlung für diese praktischen Übungen verwenden wir spark_adw_lab. Das bedeutet, dass wir einen Ordner mit dem Namen „spark_adw_lab“ erstellen und dann in diesem Verzeichnis einen weiteren Ordner mit dem Namen „source_files“ erstellen (der Pfad ist etwa /your/accessable/directory/spark_adw_lab/source\ _files). Dies ist nicht erforderlich, hilft aber, die Organisation aufrechtzuerhalten. Der SMA durchsucht auch alle Unterverzeichnisse, sodass Sie bestimmte Pipelines in einem Ordner und Notebooks in einem anderen hinzufügen können.
Zugriff ¶
Da wir nun unsere Quelldateien in einem zugänglichen Verzeichnis haben, ist es an der Zeit, den SMA auszuführen.
Wenn Sie diesen noch nicht heruntergeladen haben, finden Sie den SMA über die Snowflake-Website. Er ist auch über die Seite „Migrationen“ in SnowSight in Ihrem Snowflake-Konto zugänglich:
Sobald Sie das Tool heruntergeladen haben, installieren Sie es. Es gibt weitere Informationen zur Installation des SMA in der SMA-Dokumentation.
Verwenden des Snowpark Migration Accelerators¶
Sobald Sie das Tool installiert haben, öffnen Sie es. Wenn Sie den SMA starten, wird dieser seinem Partnertool SnowConvert sehr ähnlich aussehen. Beide Tools basieren auf einem ähnlichen Konzept, bei dem Sie Codedateien in das Tool eingeben und es ausgeführt wird. Zur Erinnerung: Wir haben gesehen, dass SnowConvert die DDL und die Daten direkt aus der Quelle aufnehmen und diese direkt in Snowflake eingeben kann. Der SMA tut dies nicht. Er nimmt nur Codedateien als Quelle auf und gibt diese Dateien an etwas aus, das mit Snowflake kompatibel ist. Dies liegt in erster Linie daran, dass das Tool nicht weiß, wie ein Benutzender den Spark-Code orchestrieren wird, aber auch, um die Verwendung sicherer zu machen.
Sobald Sie das Tool gestartet haben, werden Sie gefragt, ob Sie ein neues Projekt erstellen oder ein bereits bestehendes Projekt öffnen möchten:
So gelangen Sie zum Bildschirm für die Projekterstellung:
Auf diesem Bildschirm geben Sie die relevanten Details für Ihr Projekt ein. Beachten Sie, dass alle Felder erforderlich sind. Für dieses Projekt könnten Sie in etwa Folgendes eingeben:
Projektname: Praktische Spark ADW-Übungen
Pfad des Eingabeordners: /your/accessable/directory/spark_adw_lab/source_files
Pfad des Ausgabeordners (der SMA generiert automatisch ein Verzeichnis für die Ausgabe, aber Sie können dies ändern: /your/accessable/directory/spark_adw_lab/source_files_output
E-Mail-Adresse: your.name@your_domain.com
Firma der Kundschaft: Ihre Organisation
Ein paar Hinweise zu diesem Projekterstellungsbildschirm:
Die Felder für E-Mail und Firma sollen Ihnen helfen, bestehende Projekte zu verfolgen. Zum Beispiel kann es bei jeder großen SI mehrere E-Mail-Adressen und mehrere Organisationen geben, in deren Namen ein einzelner Benutzender den SMA ausführen kann. Diese Informationen werden in der Projektdatei gespeichert, die vom SMA erstellt wird.
Es gibt ein verdecktes Feld für SQL. Beachten Sie, dass der SMA SQL scannen/analysieren kann, aber keine SQL konvertiert. Er kann auch nur SQL unter den folgenden Umständen identifizieren:
SQL, die sich in .sql-Dateien befindet
SQL, die sich in SQL-Zellen in einem Jupyter Notebook befindet
SQL, die als einzelne Zeichenfolge an eine „spark.sql“-Anweisung übergeben wird.
Während diese SQL-Funktion hilfreich sein kann, um festzustellen, wo inkompatible SQL mit Snowflake vorhanden ist, ist es nicht die primäre Verwendung für den SMA. Weitere Unterstützung für Spark SQL und HiveQL ist demnächst verfügbar.
Sobald Sie alle Projektinformationen eingegeben haben, überspringen wir für diese HoL die Bewertungsphase. (Was? Wir erstellen keine Bewertung?) Wenn Sie keinen Code konvertieren möchten, kann das Ausführen einer Bewertung hilfreich sein, da Sie so alle vom SMA generierten Berichte erhalten. Sie können dann durch diese navigieren oder sie für andere in Ihrer Organisation freigeben, ohne zusätzliche Kopien des konvertierten Codes zu erstellen. Alle diese Bewertungsberichte werden jedoch auch während einer Konvertierung erstellt. Wir werden also den Bewertungsmodus vorerst überspringen und mit der Konvertierung fortfahren.
Wählen Sie „SAVE & SKIP ASSESSMENT“ in der rechten unteren Ecke der Anwendung.
Beachten Sie, dass Sie eine lokale Projektdatei „speichern“. Alle Informationen, die Sie auf dem Projekterstellungsbildschirm eingegeben haben, werden in dieser lokalen Textdatei mit der Erweiterung „.snowma“ in dem gerade oben angegebenen Verzeichnis gespeichert.
Auf diese Weise gelangen Sie zum Konvertierungsbildschirm. Auf diesem Bildschirm sehen Sie wieder die Felder für das Eingabe- und Ausgabeverzeichnis, aber diese sind bereits mit dem ausgefüllt, was Sie auf der Seite für die Projekterstellung eingegeben haben. Das einzige neue Feld wird hier die Eingabe eines Zugangscodes sein. Zugangscodes sind frei verfügbar, verfallen aber. Auch wenn Sie bereits einen Zugangscode zur Verwendung des Snowpark Migration Accelerators (SMA) angefragt haben, müssen Sie möglicherweise erneut einen Zugangscode anfordern. (Während der Mechanismus zur Generierung dieser Zugangscodes ähnlich ist wie SnowConvert, funktioniert der Zugangscode für SnowConvert nicht beim SMA. Sie müssen einen anderen Zugangscode anfordern und verwenden.)
Sie können einen Zugangscode anfordern, indem Sie neben dem Feld „Zugangscode eingeben …“ die Option „Anfrage für Zugangscode“ auswählen:
Wenn Sie diese Option auswählen, wird ein Popup-Menü angezeigt, in dem Sie gefragt werden, wer Sie sind, sodass ein Zugangscode generiert werden kann:
Füllen Sie alle oben gezeigten Felder aus, und stellen Sie sicher, dass Sie eine gültige E-Mail-Adresse eingeben. Im obigen Projekterstellungsbildschirm haben Sie eine E-Mail-Adresse eingegeben, um sie mit dem von Ihnen erstellten Projekt zu verknüpfen. Es wurde jedoch tatsächlich nichts an diese E-Mail-Adresse gesendet. Dies diente nur dazu, Ihr Projekt lokal zu verfolgen. Dieses Formular löst einen Zugangscode aus, der an die von Ihnen eingegebene E-Mail-Adresse gesendet wird.
Sobald Sie das Formular gesendet haben, sollten Sie in Kürze eine E-Mail mit einem Zugangscode erhalten. Die E-Mail stammt von sma-notifications@snowflake.com und sieht ungefähr so aus:
In der obigen Abbildung, wo <your access code here> steht, sollten Sie eine Reihe von Zahlen, Buchstaben und Bindestrichen sehen. Kopieren Sie diese Zeichenfolge, und fügen Sie sie in das Zugangscode-Feld für den SMA ein:
Wenn Sie den Wert in das Feld einfügen, validiert der SMA den Zugangscode. Nach einer erfolgreichen Validierung werden die Details des Zugangscodes unter dem Dialogfeld für den Zugangscode angezeigt:
Um den Zugriffscode zu validieren, ruft der SMA die Snowflake-Lizenz-API auf. Wenn Sie nicht mit dem Internet verbunden sind, kann das Tool den Zugangscode nicht validieren, und Sie erhalten eine Fehlermeldung. Wenn Sie das Tool in einer vollständigen Offline-Umgebung ausführen müssen, wenden Sie sich an sma-support@snowflake.com für Unterstützung bei der Validierung eines Zugangscodes.
Da der Zugangscode nun validiert wurde, können Sie einen Blick auf die Konvertierungseinstellungen werfen:
Es gibt eine Einstellung, die die Ausgabe dieser praktischen Übungen vereinfacht, indem die versuchte Konvertierung von pandas-Datenframes in die Snowpark API deaktiviert wird:
Diese Einstellung wird gerade aktualisiert, sodass viele zusätzliche Warnungen hinzugefügt werden, wenn diese Option nicht deaktiviert wird. Die meisten pandas-Datenframes können als Teil der modin-Implementierung von pandas verwendet werden, sodass eine einfache Änderung des Importaufrufs vorerst ausreichen sollte. Suchen Sie nach einer Lösung für dieses Problem bis Ende Juni 2025. Sie können sich die anderen Einstellungen ansehen, aber wir lassen sie unverändert. Es ist wichtig zu beachten, dass es eine Testbibliothek gibt, deren Ausgabecode mit aufgerufenen Snowpark Checkpoints kompatibel ist. Es gibt Einstellungen, die sich darauf beziehen, aber wir werden diese in diesen praktischen Übungen nicht ändern.
Wählen Sie „CLOSE“, um Ihre Einstellungen zu speichern und zu schließen.
Die Option „START CONVERSION“ ist in der rechten unteren Ecke der Anwendung verfügbar. Beginnen wir die Konvertierung, indem wir diese Option auswählen.
Auf dem nächsten Bildschirm wird der Fortschritt der Konvertierung angezeigt:
Genau wie SnowConvert erstellt der SMA ein semantisches Modell der gesamten Codebasis im Eingabeverzeichnis. Er baut Beziehungen zwischen Codeelementen, SQL-Objekten und anderen referenzierten Artefakten auf und erzeugt eine Ausgabe, die einem funktionalen Äquivalent für Snowflake am nächsten kommt. Dies bedeutet in erster Linie die Konvertierung von Referenzen aus der Spark API in die Snowpark API. Das SMA-Engineering-Team ist Teil des Snowpark-Engineering-Teams, sodass die meisten stattfindenden Transformationen in die Snowpark API integriert wurden. Die Änderungen erscheinen folglich unbedeutend. Die Vielzahl an Bewertungsinformationen, die vom SMA generiert werden, ermöglicht es, dass ein Migrationsprojekt wirklich vorangebracht wird. Eine eingehende Prüfung aller generierten Bewertungsinformationen muss an anderer Stelle erfolgen, da der SMA diese Konvertierung wahrscheinlich in der Zeit abgeschlossen hat, die zum Lesen dieses Absatzes benötigt wurde.
Wenn der SMA fertig ist, ist die Option „VIEW RESULTS“ in der rechten unteren Ecke verfügbar:
Auf der Ergebnisseite werden die Ergebnisse angezeigt.
Die Ergebnisseite enthält einige „Bereitschaftsbewertungen“, die sehr vereinfachte Kennzahlen darüber sind, wie „bereit“ diese Codebasis für Snowflake ist. Wir werden die Ergebnisse als Nächstes überprüfen, aber beachten Sie, dass die Ausführung des Snowpark Migration Accelerators der einfache Teil ist. Beachten Sie, dass dies nur ein „Beschleuniger“ ist. Es handelt sich nicht um eine Patentlösung oder ein praktisches Automatisierungstool. Pipelines, die sich mit einer Datenquelle verbinden und mit einer anderen die Ausgabe darstellen, werden von diesem Tool nicht vollständig migriert und benötigen immer mehr Aufmerksamkeit als eine einfache SQL-zu-SQL-Migration von DDL wie von SnowConvert ausgeführt. Snowflake arbeitet jedoch kontinuierlich daran, dies so einfach wie möglich zu gestalten.
Interpretation der Ausgabe¶
Der SMA, sogar mehr als SnowConvert, generiert eine große Menge an Bewertungsinformationen. Es kann schwierig sein, die Ergebnisse zu analysieren. Es gibt viele verschiedene Richtungen, in die Sie gehen können, je nachdem, was Sie erreichen möchten.
Beachten Sie, dass es sich hierbei um ein äußerst einfaches Szenario handelt, sodass einige der Schritte, die wir ausführen werden, überflüssig erscheinen. (Müssen wir wirklich die in diesem Projekt vorhandenen Abhängigkeiten analysieren, wenn es nur zwei Dateien gibt?) Das Ziel ist es, das durchzuführen, was wir normalerweise auch in diesem kleinen POC empfehlen. Lassen Sie uns aber festhalten, dass der Geltungsbereich eindeutig ist und es nur zwei Dateien gibt. Es ist nur nötig, dass beide so funktionieren, wie sie es in der Quelle tun.
Bereitschaftsbewertungen¶
Vor diesem Hintergrund werfen wir einen Blick auf den ersten Teil der Ausgabe, den Sie in der Anwendung sehen werden: die Bereitschaftsbewertungen. Es wird mehrere Bereitschaftsbewertungen geben, und Sie können jede einzelne von ihnen erweitern, um besser zu verstehen, was von dieser Bereitschaftsbewertung erfasst wird.
Jede Bereitschaftsbewertung ist eine sehr einfache Berechnung der Anzahl der Funktionen oder Elemente in einer API, die in Snowpark/Snowflake unterstützt werden, geteilt durch die Anzahl aller Funktionen oder Elemente, die sich auf diese API für diese Ausführung beziehen. Die Berechnung, die Ihnen die Berechnung des Wertes zeigt, wird angezeigt, wenn Sie das Fenster erweitern. Sie können auch mehr darüber erfahren, wie Sie die Bereitschaftsbewertungen interpretieren können, indem Sie in der linken oberen Ecke dieses Fensters „How to read through the scores“ auswählen.
Diese Ausführung hat eine Spark API-Bereitschaftsbewertung von 97,92 %. (Bitte beachten Sie, dass Ihre Bewertung anders sein kann. Diese Tools werden alle zwei Wochen aktualisiert, und es kann eine Änderung geben, da sich die Kompatibilität zwischen den beiden Plattformen ständig weiterentwickelt.) Dies bedeutet, dass 97,92 % der Referenzen auf die Spark API, die das Tool identifiziert hat, in Snowflake unterstützt werden. „Unterstützt“ bedeutet in diesem Fall, dass es eine ähnliche Funktion geben könnte, die bereits existiert, oder dass der SMA eine funktional äquivalente Ausgabe erstellt hat. Je höher diese Punktzahl ist, desto wahrscheinlicher kann dieser Code in Snowflake schnell ausgeführt werden.
(Beachten Sie, dass diese 97,92 % der Referenzen entweder direkt von der Snowpark API unterstützt werden oder sie vom SMA konvertiert werden. Die meisten von ihnen werden wahrscheinlich direkt unterstützt, aber Sie können genau herausfinden, was konvertiert wurde und was weitergegeben wurde, indem Sie den SparkUsageInventory.csv-Bericht im Ordner „Ausgabeberichte“ überprüfen, der vom SMA generiert wird. Wir werden das in diesen praktischen Übungen nicht genauer untersuchen, da wir sehen werden, was NOT in der Datei issues.csv unterstützt wird. Sie können aber diese Informationen als Referenz verwenden).
Es gibt weitere Bereitschaftsbewertungen, und Sie können mehr sehen als in den praktischen Übungen angezeigt wird, da sich die Bereitschaftsbewertungen im Laufe der Zeit ändern. In diesen praktischen Übungen wird nicht jede einzelne von ihnen untersucht, aber beachten Sie, dass ein niedriger Wert immer eine Untersuchung wert ist.
Code analysiert¶
Direkt unter jeder Bereitschaftsbewertung befindet sich ein kleiner Indikator, der Sie darüber informiert, ob es Code gibt, der nicht verarbeitet werden konnte:
Diese Zahl stellt den Prozentsatz der Dateien dar, die vollständig analysiert wurden. Wenn diese Zahl weniger als 100 % ist, dann gibt es einen Code, der vom SMA nicht analysiert oder verarbeitet werden konnte. Dies ist die erste Stelle, an der Sie suchen sollten, um Probleme zu lösen. Wenn der Wert weniger als 100 % ist, sollten Sie in der Problemzusammenfassung sehen, wo die Fehler beim Parsen aufgetreten sind. Dies ist die erste Stelle, an der Sie suchen sollten, wenn Sie die SMA-Ausgabe überprüfen, da dies die einzige Stelle ist, bei der es sinnvoll sein könnte, das Tool erneut auszuführen, wenn eine große Menge an Code nicht gescannt werden konnte.
In diesem Fall haben wir nur 50 % unseres Workloads erfolgreich geparst. Tragisch. Das erscheint uns vielleicht wie etwas, das uns in Panik versetzen sollte, aber lassen Sie uns nicht zu voreilig sein. Wir haben nur 2 Dateien und wissen noch nicht, wie viele Parsing-Fehler wir haben.
Unabhängig vom Ergebnis dieser Zahl werden wir auf dieser Seite als Letztes die Problemzusammenfassung aufrufen. Scrollen Sie in der Anwendung nach unten, bis Sie diese Zusammenfassung sehen:
Problemzusammenfassung¶
Probleme sind eines der Schlüsselelemente in SnowConvert und im SMA. Jedes Tool versucht, eine funktional gleichwertige Ausgabe zu erstellen, die auf den Eingaben basiert, die es erhält. Allerdings ist keine Konvertierung zu 100 % automatisiert. Diese Tools wissen dies und markieren alles, was nicht konvertiert werden kann, oder erfordert sogar zusätzliche Aufmerksamkeit bei einem Problem. Diese Probleme werden in einer Tabellenkalkulation zusammengefasst, aber auch als Kommentare direkt in den Ausgabecode geschrieben.
Die Zusammenfassung des Problems in der UI hebt die Probleme vor, die bei dieser Ausführung des Tools festgestellt wurden. Diese Probleme werden oft mit dem Akronym EWI (Fehler, Warnung und Problem) bezeichnet. Ähnlich, aber nicht identisch mit SnowConvert, erzeugt der SMA drei Arten von Problemen:
Analysefehler – Diese Art von Problem gilt als kritisch und muss von Ihnen sofort behoben werden. Aufgrund der Art und Weise, wie der SMA funktioniert, könnte nicht analysierter Code darauf hinweisen, dass Informationen in den Berichten fehlen und auch ein Teil der Konvertierung fehlt.
Konvertierungsfehler – Dies ist etwas, das der SMA erkennt (oder zumindest denkt, dass er es erkennt), was aber aus dem einen oder anderen Grund nicht konvertiert werden kann. Diese Fehler haben in der Regel sehr spezifische Problemcodes und sollten als Nächstes behandelt werden.
Warnung – Diese Fehlercodes identifizieren Code, den der SMA nicht konvertiert hat, oder es handelt sich um etwas, das eine Entsprechung in Snowpark/Snowflake hat. Allerdings kann es Probleme geben, wenn Sie das Testen durchführen. Möglicherweise besteht keine 100 %-ige Funktionsübereinstimmung.
Weitere Informationen zu den Problemtypen auf der SMA-Dokumentationsseite stehen zur Verfügung, aber die Problemzusammenfassung für unsere Ausführung wird hier angezeigt:
In dieser Zusammenfassung finden Sie den Code, die Anzahl, den Grad und die Beschreibung für die einzelnen Probleme. Auch wenn viele Probleme vorhanden sind, gilt Folgendes: Je weniger eindeutige Probleme es gibt, desto wahrscheinlicher ist es, dass sie programmgesteuert behandelt werden. Für weitere Informationen zu jedem eindeutigen Problemcode können Sie in der UI auf den Code klicken. Auf diese Weise gelangen Sie zur SMA-Dokumentationsseite für dieses spezielle Problem.
Es sieht so aus, als ob wir einige Konvertierungsfehler, Warnungen und 1 Parsing-Fehler haben. Das bedeutet, dass es eine Sache gab, die das Tool nicht lesen konnte. (Beachten Sie, dass, wenn viele Fehlercodes angezeigt werden, die mit PND beginnen, Sie diese Option in den Konvertierungseinstellungen möglicherweise nicht deaktiviert haben. Keine Sorge, wenn Sie diese sehen. Sie können sie ignorieren.)
Unabhängig davon, wie viele Probleme vorhanden sind, wird immer empfohlen, die detaillierte Problemdatei zu überprüfen, wenn Sie bereit sind, mit der Migration zu beginnen. Dies ist eine CSV-Datei, die lokal auf dem Computer gespeichert wird, auf dem Sie den SMA ausgeführt haben. Sie können diese Datei finden, indem Sie die Option „VIEW REPORTS“ unten rechts im SMA auswählen:
Auf diese Weise gelangen Sie in das lokale Verzeichnis, das alle Berichte enthält. Zum Zeitpunkt der Erstellung dieses Dokuments wurden viele Berichte vom SMA generiert:
Jeder dieser Berichte enthält einige wertvolle Informationen, je nachdem, wie Sie den SMA verwenden. Im Moment werden wir uns nur die Datei „issues.csv“ ansehen, aber beachten Sie, dass es weitere Informationen zu EVERY Bericht und Inventar gibt, der bzw. das vom SMA in der SMA-Dokumentation generiert wurde.
Wenn Sie die Problemdatei öffnen, sieht sie ungefähr so aus:
Beachten Sie das Schema dieses Berichts. Es enthält den Problemcode, eine Beschreibung des Problems, den Typ des Problems (Kategorie), die Datei, in der sich jedes Problem befindet, die Zeilennummer der Datei, in der sich jedes Problem befindet, und bietet darüber hinaus einen Link zur Dokumentationsseite dieses spezifischen Problems. All dies sind hilfreiche Informationen beim Navigieren durch die Probleme.
Sie können dies anhand der Datei pivotieren, um zu sehen, welchen Problemtyp Sie pro Datei haben:
Es sieht so aus, dass wir nur wenige Probleme haben und sich unser Parsing-Fehler im Pipeline-Python-Skript befindet. Hier wollen wir beginnen.
Normalerweise würden wir uns einen anderen Bericht in unserem Berichtsverzeichnis ansehen, die Datei ArtifactDependencyInventory.csv. Aber dies ist eine so kleine Ausführung. Schauen wir uns jetzt an, was tatsächlich in diesen Ausgabedateien steht, und sehen wir, ob wir sie in (oder mit) Snowflake ausführen können.