Snowpark Migration Accelerator : Remarques sur la préparation du code¶

Types de fichiers¶

L’outil Snowpark Migration Accelerator (SMA) examine tous les fichiers de votre répertoire source, mais ne traite que les fichiers avec des extensions spécifiques qui peuvent contenir du code Spark API. Cela comprend à la fois les fichiers de code ordinaires et les notebooks de Jupyter.

Vous trouverez une liste des types de fichiers pris en charge par SMA dans la section Types de fichiers pris en charge de cette documentation.

Fichiers exportés¶

Si votre code est stocké dans une plateforme de contrôle source au lieu de fichiers locaux, vous devez l’exporter dans un format que SMA peut traiter. Voici comment vous pouvez exporter votre code :

Pour les utilisateurs de Databricks : Pour utiliser l’outil Snowpark Migration Accelerator (SMA), vous devez exporter vos notebooks au format .dbc. Vous trouverez des instructions détaillées sur l’exportation des notebooks dans la documentation Databricks sur l’exportation des notebooks.

Besoin d’aide pour exporter des fichiers ? Consultez les scripts d’exportation dans le référentiel Github de Snowflake Labs, où les services professionnels de Snowflake gèrent les scripts pour Databricks, Hive et d’autres plateformes.

• Si vous utilisez une plateforme différente, veuillez vous référer à la page Extraction de code pour les instructions spécifiques à votre plateforme. Si vous avez besoin d’aide pour convertir votre code dans un format compatible avec SMA, veuillez contacter sma-support@snowflake.com.

Taille¶

L’outil Snowpark Migration Accelerator (SMA) est conçu pour analyser le code source et non les données. Pour garantir des performances optimales et éviter l’épuisement des ressources du système, nous vous recommandons ce qui suit :

1. N’incluez que les fichiers de code spécifiques que vous souhaitez migrer

2. Évitez d’inclure des dépendances de bibliothèque inutiles

Bien que vous puissiez inclure les fichiers de code des bibliothèques dépendantes, cela augmentera considérablement le temps de traitement sans ajouter de valeur, car SMA se concentre spécifiquement sur l’identification du code Spark qui nécessite une migration.

Nous vous recommandons de rassembler tous les fichiers de code qui…

• S’exécutent automatiquement dans le cadre d’un processus planifié

• Ont été utilisés pour créer ou configurer ce processus (s’ils sont distincts)

• Sont des bibliothèques personnalisées créées par votre organisation qui sont utilisées dans l’un ou l’autre des scénarios ci-dessus

Vous n’avez pas besoin d’inclure le code des bibliothèques tierces courantes telles que Pandas ou Sci-Kit Learn. L’outil détectera et classera automatiquement les références de ces bibliothèques sans avoir besoin de leur code source.

Fonctionne t’il ?¶

L’outil Snowpark Migration Accelerator (SMA) ne peut traiter que des codes sources complets et syntaxiquement corrects. Votre code doit pouvoir être exécuté avec succès sur une plateforme source prise en charge. Si l’outil SMA signale plusieurs erreurs d’analyse, cela indique généralement que votre code source contient des erreurs de syntaxe. Pour obtenir les meilleurs résultats, veillez à ce que votre répertoire d’entrée ne contienne que du code valide pouvant être exécuté sur la plateforme source.

Cas d’utilisation¶

Il est essentiel de comprendre l’objectif de votre base de code lorsque vous examinez les résultats de l’analyse. Cela vous aidera :

1. À déterminer les applications ou les processus susceptibles de ne pas fonctionner correctement avec Snowpark

2. À comprendre et analyser plus efficacement les résultats de l’évaluation de la préparation

3. À vérifier si votre code et vos systèmes existants sont compatibles avec Snowflake

Lors de l’analyse d’un notebook qui utilise un dialecte SQL non pris en charge et un connecteur de base de données sans Spark, l’outil SMA n’affichera que les bibliothèques tierces importées. Bien que ces informations soient utiles, le notebook ne recevra pas de score de préparation Spark API. Comprendre comment vous prévoyez d’utiliser votre code vous aidera à mieux appréhender ces limites et à prendre de meilleures décisions lors de la migration.

Exportations à partir de notebooks Databricks¶

Les notebooks Databricks prennent en charge plusieurs langages de programmation telles que SQL, Scala, et PySpark dans un seul notebook. Lorsque vous exportez un notebook, l’extension du fichier reflète son langage principal :

• Notebooks Python : .ipynb ou .py

• Notebooks SQL : .sql

Tout code écrit dans un langage différent du langage principal du notebook sera automatiquement converti en commentaires lors de l’exportation. Par exemple, si vous incluez du code SQL dans un notebook Python, le code SQL apparaîtra sous forme de commentaires dans le fichier exporté.

Les commentaires de code sont exclus de l’analyse SMA. Pour que votre code soit correctement analysé, placez-le dans un fichier dont l’extension correspond au langage source. Par exemple :

• Le code Python doit se trouver dans des fichiers .py

• Le code SQL doit se trouver dans des fichiers .sql

Notez que même le code non commenté ne sera pas analysé s’il se trouve dans un fichier dont l’extension n’est pas la bonne (comme du code Python dans un fichier .sql).

Avant d’utiliser l’outil, veuillez lire la section Considérations sur le pré-traitement dans notre documentation. Cette section contient des informations essentielles que vous devez connaître avant de poursuivre.