Snowpark Migration Accelerator : Atelier Pipeline - Évaluation¶
Comme avec SnowConvert, nous exécuterons le code dans SMA, évaluerons le résultat, résoudrons les problèmes et l’exécuterons sur la nouvelle plateforme. Cependant, contrairement à SnowConvert, SMA ne se connecte pas à une plateforme source, et ne se connecte pas non plus à Snowflake. Il s’agit d’une application locale qui peut être exécutée entièrement hors ligne. Mais sa puissance réside dans son évaluation. La plupart du travail important sur la conversion a été effectué en créant une compatibilité entre l’API Spark et l’API Snowpark.#x20;
Extraction/Disponibilité du code¶
Les fichiers que nous utiliserons pour l’atelier AdventureWorks sont ici :
end_to_end_lab_source_code.zip
Dans le cadre de cet atelier, nous supposons que le notebook et le fichier de script que nous convertissons sont déjà accessibles en tant que fichiers. En général, SMA prend des fichiers comme entrée et ne se connecte à aucune plateforme source. Si les fichiers sont orchestrés par un outil spécifique, vous devrez peut-être les exporter. Si vous utilisez des notebooks dans le cadre de Databricks ou de EMR, vous pouvez les exporter sous forme de fichiers .ipynb tout comme le notebook jupyter que nous allons exécuter dans SMA aujourd’hui.#x20;
Cet atelier n’a que quelques fichiers, mais dans une grande migration il est courant d’avoir des centaines ou des milliers de fichiers. Extrayez ce que vous pouvez et exécutez ces fichiers via SMA. Le point positif de l’utilisation d’un outil comme celui-ci est qu’il peut vous indiquer ce qui pourrait vous manquer.#x20;
Notez qu’il existe également un fichier de données : “customer_update.csv”. Il s’agit d’un échantillon du fichier généré localement par le système Point de vente (POS) qu’Adoption Works utilise actuellement. Alors que ce système est également en cours de mise à jour, cette preuve de concept (POC) consiste à faire fonctionner le pipeline existant avec Snowpark plutôt qu’avec Spark.#x20;
Prenons chacun de ces fichiers et déposons-les dans un seul répertoire sur notre machine locale :#x20;

Il serait recommandé de créer un répertoire de projet. Vous pouvez l’appeler comme vous le souhaitez, mais pour cet atelier, utilisons spark_adw_lab. Cela signifie que nous allons créer un dossier portant le nom spark_adw_lab, puis créer un autre dossier dans ce répertoire appelé source_files (le chemin ressemblant à /your/accessible/directory/spark_adw_lab/source_files). Cela n’est pas obligatoire, mais aidera à organiser les choses. SMA analysera également tout ensemble de sous-répertoires, afin que vous puissiez ajouter des pipelines spécifiques dans un dossier et des notebooks dans un autre.
Accès#20;¶
Maintenant que nous avons nos fichiers sources dans un répertoire accessible, il est temps d’exécuter SMA.
Si vous ne l’avez pas encore téléchargé, SMA est accessible à partir du site Web de Snowflake. Il est également accessible depuis la page Migrations de SnowSight dans votre compte Snowflake :

Une fois l’outil téléchargé, installez-le ! Vous trouverez plus d’informations sur l’installation de SMA dans la documentation SMA.#x20;
Utilisation du Snowpark Migration Accelerator¶
Une fois l’outil installé, ouvrez-le ! Lorsque vous lancerez SMA, il ressemblera beaucoup à son outil partenaire, SnowConvert. Ces deux outils sont conçus sur un concept similaire, où vous entrez des fichiers de code dans l’outil et ceux-ci s’exécutent. Rappel : nous avons vu que SnowConvert peut prendre le DDL et les données directement dans la source et les entrer directement dans Snowflake. SMA ne fait pas cela. Il prend uniquement en compte les fichiers de code comme sources et les génère dans un cadre compatible avec Snowflake. Cela s’explique principalement par le fait que l’outil ne sait pas comment un utilisateur orchestrera son code spark, mais aussi pour le rendre plus sûr à utiliser.#x20;
Une fois que vous avez lancé l’outil, il vous demandera si vous souhaitez créer un nouveau projet ou ouvrir un projet existant :

Cela vous amènera à l’écran de création du projet :

Sur cet écran, vous saisirez les détails de votre projet. Notez que tous les champs sont obligatoires. Pour ce projet, vous pouvez saisir quelque chose de similaire à :
Nom du projet : Spark ADW Lab
Chemin du dossier d’entrée : /your/accessible/directory/spark_adw_lab/source_files
Chemin du dossier de sortie (SMA générera automatiquement un répertoire pour la sortie, mais vous pouvez le modifier : /your/accessible/directory/spark_adw_lab/source_files_output
Adresse e-mail : votre.nom@your_domain.com#x20;
Entreprise du client : votre organisation
Quelques remarques sur cet écran de création de projets :
Les champs Adresse e-mail et Entreprise sont destinés à vous aider à suivre les projets en cours. Par exemple, pour tout grand SI, il peut y avoir plusieurs adresses e-mail et plusieurs organisations au nom desquelles un seul utilisateur peut exécuter SMA. Ces informations sont stockées dans le fichier de projet créé par SMA.
Il y a un champ masqué pour SQL. Notez que SMA peut scanner/analyser le SQL, mais il ne convertit aucun SQL. Il ne peut également identifier que le SQL dans les circonstances suivantes :
SQL qui se trouve dans les fichiers .sql
SQL qui se trouve dans les cellules SQL dans un notebook Jupyter
SQL qui est transmis sous forme de chaîne unique à une instruction spark.sql.#x20;
Bien que cette fonctionnalité SQL puisse être utile pour déterminer où se trouve un SQL non compatible avec Snowflake, il ne s’agit pas de l’utilisation principale de SMA. Nous vous proposerons bientôt une assistance supplémentaire pour Spark SQL et HiveQL.
Une fois que vous avez saisi toutes les informations de votre projet, pour ce HoL, nous allons ignorer la phase d’évaluation. (Comment ça ?… est-ce que nous ne créons pas une évaluation ?) Si vous ne souhaitez convertir aucun code, l’exécution d’une évaluation peut être utile, car elle vous permettra d’obtenir l’ensemble complet des rapports générés par SMA. Vous pouvez ensuite parcourir ces rapports ou les partager avec d’autres personnes au sein de votre organisation tout en ne créant pas de copies supplémentaires du code converti. Cependant, tous ces mêmes rapports d’évaluation sont également générés lors d’une conversion. Nous allons donc ignorer le mode d’évaluation pour le moment et passer à la conversion.#x20;
Sélectionnez « SAVE et SKIP ASSESSMENT » dans le coin inférieur droit de l’application.

Notez que ce que vous « enregistrez » est un fichier de projet local. Toutes les informations que vous avez saisies sur l’écran de création du projet seront enregistrées dans ce fichier texte local portant l’extension « .snowma » dans le répertoire que vous venez de spécifier ci-dessus.

Cela vous amènera à l’écran de conversion. Sur cet écran, vous verrez à nouveau les champs d’entrée et de sortie du répertoire, mais ceux-ci auront déjà été remplis par ce que vous avez saisi sur la page de création du projet. Le seul nouveau champ ici sera pour saisir un code d’accès. Les codes d’accès sont disponibles gratuitement, mais ils ont une date d’expiration. Ainsi, même si vous avez déjà demandé un code d’accès pour utiliser Snowpark Migration Accelerator (SMA), vous devrez peut-être en redemander un nouveau. (Et alors que le mécanisme de génération de ces codes d’accès est similaire à SnowConvert, les codes d’accès pour SnowConvert ne fonctionneront pas avec SMA. Vous devrez en demander et en utiliser un autre).
Vous pouvez demander un code d’accès en sélectionnant « Demander un code d’accès » à côté du champ « Saisir un code d’accès… » : #x20;

Lorsque vous sélectionnez cette option, un menu contextuel apparaît, vous demandant qui vous êtes afin qu’un code d’accès puisse être généré :

Remplissez tous les champs indiqués ci-dessus et assurez-vous de saisir une adresse e-mail valide. Auparavant, dans l’écran de création du projet, vous avez saisi une adresse e-mail à associer au projet que vous créez. Cependant, rien n’a été envoyé à cette adresse e-mail. Elle servait uniquement à suivre votre projet localement. Ce formulaire déclenchera l’envoi d’un code d’accès à l’adresse e-mail que vous avez saisie.
Une fois que vous avez soumis le formulaire, vous devriez recevoir rapidement un e-mail avec un code d’accès. L’e-mail proviendra de sma-notifications@snowflake.com, et ressemblera à ceci :

Dans l’image ci-dessus, où il est écrit <your access code here>, vous devriez voir une série de chiffres, de lettres et de tirets. Copiez cette chaîne et collez-la dans le champ du code d’accès pour SMA:#20;

Lorsque vous collez la valeur dans la case, SMA valide le code d’accès. Une validation réussie affichera les détails du code d’accès sous la boîte de dialogue du code d’accès :

Pour valider le code d’accès, SMA appellera l’API de licence Snowflake. Si vous n’êtes pas connecté à Internet, l’outil ne sera pas en mesure de valider le code d’accès et vous obtiendrez un message d’erreur. Si vous devez exécuter l’outil dans un environnement entièrement hors ligne, veuillez contacter sma-support@snowflake.com pour obtenir de l’aide sur la validation d’un code d’accès.
Maintenant que le code d’accès a été validé, vous pouvez jeter un œil aux paramètres de conversion :

Il y a un paramètre qui simplifiera la sortie de cet atelier, à savoir désactiver la tentative de conversion des dataframes pandas vers l’API Snowpark :

Ce paramètre est actuellement en cours de mise à jour, de sorte que de nombreux avertissements supplémentaires seront ajoutés si cette option n’est pas désélectionnée. La plupart des dataframes pandas peuvent être utilisés dans le cadre de l’implémentation modin de pandas, par conséquent, un simple changement d’appel d’importation devrait suffire pour le moment. Vous devriez trouver une solution à ce problème d’ici la fin du mois de juin 2025. Vous pouvez consulter les autres paramètres, mais nous les laisserons tels quels. Il est important de noter qu’il existe une bibliothèque de tests dont le code de sortie est compatible avec les points de contrôle Snowpark appelés. Il existe des paramètres liés à cela, mais nous ne les modifierons pas dans cet atelier.
Sélectionnez « CLOSE » pour enregistrer et fermer vos paramètres.#x20;

L’option « START CONVERSION » est disponible dans le coin inférieur droit de l’application. Commençons la conversion en sélectionnant cette option.
L’écran suivant montrera la progression de la conversion :#x20;

Comme SnowConvert, SMA est en train de construire un modèle sémantique de l’intégralité de la base de code dans le répertoire d’entrée. Il s’agit d’établir des relations entre les éléments de code, les objets SQL et d’autres artefacts référencés, et de créer la sortie la plus proche possible d’un équivalent fonctionnel pour Snowflake. Cela signifie principalement la conversion des références de l’API Spark vers l’API Snowpark. L’équipe d’ingénierie de SMA fait partie de l’équipe d’ingénierie de Snowpark. Par conséquent, la plupart des transformations qui ont lieu ont été intégrées à l’API Snowpark, les changements peuvent donc sembler mineurs. Mais la masse d’informations d’évaluation générées par SMA permet à un projet de migration de vraiment avancer. Un examen approfondi de toutes les informations d’évaluation générées devra avoir lieu ailleurs, car SMA a probablement terminé cette conversion pendant la lecture de ce paragraphe.#x20;
Lorsque SMA a terminé, l’option « VIEW RESULTS » est disponible dans le coin inférieur droit :

La page des résultats affichera les… résultats.#x20;

La page des résultats possède quelques « scores de préparation » qui sont des métriques très simplifiées du niveau de « préparation » de cette base de code pour Snowflake. Nous examinerons les résultats ensuite, mais notez que l’exécution de Snowpark Migration Accelerator est la partie facile. Remarquez qu’il ne s’agit que d’un « accélérateur ». Il ne s’agit pas d’une solution optimale ou d’un outil d’automatisation automatique. Les pipelines qui se connectent à une source de données et génèrent une sortie à une autre ne sont pas entièrement migrés par cet outil et auront toujours besoin de plus d’attention qu’une simple migration de DDL de SQL-à-SQL comme le fait SnowConvert. Mais Snowflake travaille continuellement à rendre cette migration aussi simple que possible.
Interprétation de la sortie¶
SMA, encore plus que SnowConvert, génère une grande quantité d’informations d’évaluation. Il peut être difficile d’analyser les résultats. Il existe de nombreuses directions différentes, en fonction de ce que vous voulez réaliser.#x20;
Notez qu’il s’agit d’un scénario extrêmement simple, de sorte que certaines des étapes que nous allons suivre vous sembleront excessives. (En d’autres termes, est-ce que nous avons réellement besoin d’analyser les dépendances présentes dans ce projet alors qu’il n’y a que deux fichiers et que nous pouvons simplement… regarder ?) L’objectif est d’effectuer ce que nous recommandons normalement, même dans ce petit POC. Mais soyons clairs… la portée est claire, et il n’y a que deux fichiers. Nous avons simplement besoin que les deux fonctionnent comme ils le font dans la source.#x20;
Scores de préparation¶
En gardant cela à l’esprit, jetons un coup d’œil à la première partie de la sortie que vous verrez dans l’application : les scores de préparation. Il y aura plusieurs scores de préparation et vous pourrez développer chacun d’entre eux pour mieux comprendre ce qu’il contient.#x20;

Chaque score de préparation est un calcul très basique du nombre de fonctions ou d’éléments dans une API qui sont pris en charge dans Snowpark/Snowflake divisé par le nombre de toutes les fonctions ou éléments liés à cette API pour cette exécution. Le calcul vous montrant comment le score est calculé est affiché lorsque vous développez la fenêtre. Vous pouvez également en savoir plus sur la manière d’interpréter les scores de préparation en sélectionnant « Comment lire les scores » dans le coin supérieur gauche de cette fenêtre.#x20;
Cette exécution a un score de préparation API Spark de 97,92 %. (Notez que le vôtre peut être différent ! Ces outils sont mis à jour sur une base bimensuelle et un changement est possible, car la compatibilité entre les deux plateformes est en constante évolution.) Cela signifie que 97,92 % des références à l’API Spark que les outils ont identifiés sont pris en charge dans Snowflake. « Prise en charge » dans ce cas signifie qu’il pourrait y avoir une fonction similaire qui existe déjà ou que SMA a créé une sortie fonctionnellement équivalente. Plus ce score est élevé, plus ce code a de chances de s’exécuter rapidement dans Snowflake.#x20;
(Notez que 97,92 % des références sont prises en charge directement par l’API Snowpark ou qu’ils sont convertis par SMA. La plupart d’entre elles sont probablement prises en charge directement, mais vous pouvez savoir exactement ce qui a été converti et ce qui a été transmis en consultant le rapport SparkUsageInventory.csv dans le dossier de rapports de sortie généré par SMA. Nous ne passerons pas ce point en revue dans cet atelier car nous verrons ce qui n’est pas pris en charge dans le fichier issues.csv, mais vous pouvez utiliser ces informations à titre de référence).
Il existe d’autres scores de préparation et vous pouvez en voir plus que ce qui est indiqué dans l’atelier, car les scores de préparation changent avec le temps. Cet atelier ne présente pas chacun d’entre eux, mais notez qu’un score faible sera toujours intéressant à comprendre. #x20;
Code analysé¶
Juste en dessous de chacun des scores de préparation se trouve un petit indicateur qui vous permet de savoir s’il y avait un code qui n’a pas pu être traité :

Ce nombre représente le pourcentage de fichiers qui ont été entièrement analysés. Si ce nombre est inférieur à 100 %, cela signifie que du code n’a pas été analysé ou traité par SMA. C’est le premier endroit où vous devriez commencer à chercher pour résoudre les problèmes. Si le taux est inférieur à 100 %, vous devriez voir où les erreurs d’analyse se sont produites en consultant le résumé du problème. C’est le premier endroit où vous devez chercher lorsque vous travaillez avec la sortie de SMA car c’est le seul endroit où il peut être utile d’exécuter à nouveau l’outil si une grande quantité de code n’a pas pu être analysée.
Dans ce cas, nous n’avons que 50 % de notre charge de travail analysée correctement. Terrible. Maintenant, cela peut ressembler à quelque chose qui pourrait nous faire paniquer, mais ne jugeons pas trop vite. Nous n’avons que 2 fichiers, et nous ne savons pas encore combien d’erreurs d’analyse nous avons.
Indépendamment du résultat, le dernier endroit que nous visiterons sur cette page sera le résumé du problème. Faites défiler l’application jusqu’à ce que vous voyiez ce résumé :

Résumé des problèmes¶
Les problèmes sont l’un des éléments clés de SnowConvert et de SMA. Chaque outil tente de créer un résultat équivalent fonctionnel basé sur les entrées qu’il reçoit, mais aucune conversion n’est automatisée à 100 %. Ces outils le savent et marquent tout ce qui ne peut pas être converti ou qui pourrait même nécessiter une attention particulière comme un problème. Ces problèmes sont résumés dans une feuille de calcul, mais sont également écrits sous forme de commentaires directement dans le code de sortie.
Le résumé du problème dans l’UI présente les problèmes qui ont été trouvés lors de cette exécution de l’outil. Ces problèmes sont souvent désignés par l’acronyme EWI (erreur, avertissement et problème). De façon semblable, mais pas identique à SnowConvert, SMA génère trois types de problèmes :
Erreur d’analyse - Ce type de problème est considéré comme critique et vous devrez le traiter immédiatement. En raison de la façon dont SMA fonctionne, avoir du code qui n’est pas analysé peut signifier des informations manquantes dans les rapports et un élément de conversion manquant également.#x20;
Erreur de conversion - C’est quelque chose que SMA reconnaît (ou au moins pense qu’il reconnaît), mais qu’il ne peut pas convertir pour une raison ou une autre. Ces erreurs ont généralement des codes de problème très spécifiques et doivent être traitées en deuxième.
Avertissement - Ces codes d’erreur identifient le code que SMA n’a pas converti ou sont quelque chose avec un équivalent dans Snowpark/Snowflake, mais avec des problèmes possibles lorsque vous effectuez des tests. Il peut ne pas y avoir 100 % d’équivalence fonctionnelle.#x20;
Il existe plus d’informations sur les types de problèmes sur la page de la documentation SMA, mais le résumé des problèmes pour notre exécution est indiqué ici :#x20;

Dans ce résumé, vous pouvez trouver le code, le nombre, le niveau et la description des problèmes uniques présents. Même s’il existe un grand nombre de problèmes, moins il y a de problèmes uniques, plus il est probable qu’ils puissent être traités par programmation. Pour plus d’informations sur chaque code de problème unique, vous pouvez cliquer sur le code dans l’UI. Cela vous amènera à la page de la documentation SMA pour ce problème spécifique. #x20;
Il semble y avoir des erreurs de conversion, des avertissements et une erreur d’analyse. Cela signifie qu’il y avait une chose que l’outil n’a pas pu lire. (Notez que si vous obtenez un grand nombre de codes d’erreur qui commencent par PND, vous n’avez peut-être pas désélectionné cette option dans les paramètres de conversion. Aucun problème cependant : si vous en voyez, vous pouvez les ignorer.)
Quel que soit le nombre de problèmes que vous avez, il est toujours recommandé d’explorer le fichier des problèmes détaillé si vous êtes prêt à commencer la migration. Il s’agit d’un fichier csv qui est stocké localement sur la machine où vous avez exécuté SMA. Vous pouvez trouver ce fichier en sélectionnant l’option « VIEW REPORTS » en bas à droite de SMA :

Cela vous amènera au répertoire local qui contient tous les rapports… et au moment de la rédaction de ce chapitre, un grand nombre de rapports sont générés par SMA :

Chacun de ces rapports contient des informations précieuses en fonction de la manière dont vous utilisez SMA. Pour le moment, nous examinerons uniquement le fichier issues.csv, mais notez qu’il existe plus d’informations sur EVERY rapport et inventaire générés par SMA dans la documentation SMA.
Lorsque vous ouvrez le fichier des problèmes, il se présente comme suit :

Notez le schéma de ce rapport. Il vous indique le code du problème, une description du problème, le type de problème (catégorie), le fichier dans lequel se trouve chaque problème, le numéro de ligne du fichier dans lequel se trouve chaque problème, et fournit un lien vers la page de documentation pour ce problème spécifique. Toutes ces informations sont utiles pour parcourir les problèmes.#x20;
Vous pouvez aussi faire une recherche par fichier pour voir quel type de problème il contient :

Apparemment, nous n’avons que quelques problèmes, et notre erreur d’analyse se trouve dans le script du pipeline python. C’est par là que nous allons commencer.#x20;
Normalement, nous jetterions un œil à un autre rapport dans notre répertoire de rapports, à savoir le fichier ArtifactDependencyInventory.csv. Mais cette exécution est si petite qu’il est préférable de jeter un œil à ce que contiennent réellement ces fichiers de sortie, et voir si nous ne pouvons pas les utiliser dans (ou avec) Snowflake.