Show Menu
SUJETS×

Guides de migration des recettes et des blocs-notes

Les ordinateurs portables et les recettes utilisant Python/R restent inchangés. La migration s'applique uniquement aux recettes et cahiers PySpark/Spark existants.
Les guides suivants décrivent les étapes et les informations requises pour migrer des recettes et des cahiers de notes existants.

Guide de migration Spark

L'artefact de recette généré par les étapes de création est désormais une image Docker qui contient votre fichier binaire .jar. De plus, la syntaxe utilisée pour lire et écrire des jeux de données à l'aide du SDK de plate-forme a changé et vous oblige à modifier votre code de recette.
La vidéo suivante est conçue pour aider à mieux comprendre les modifications requises pour les recettes Spark :

Lecture et écriture de jeux de données (Spark)

Avant de créer l'image Docker, consultez les exemples de lecture et d'écriture de jeux de données dans le SDK de la plate-forme, fournis dans les sections ci-dessous. Si vous convertissez des recettes existantes, votre code SDK de plateforme doit être mis à jour.

Lecture d’un jeu de données

Cette section décrit les modifications nécessaires à la lecture d’un jeu de données et utilise l’exemple helper.scala fourni par Adobe.
Ancienne manière de lire un jeu de données
 var df = sparkSession.read.format("com.adobe.platform.dataset")
    .option(DataSetOptions.orgId, orgId)
    .option(DataSetOptions.serviceToken, serviceToken)
    .option(DataSetOptions.userToken, userToken)
    .option(DataSetOptions.serviceApiKey, apiKey)
    .load(dataSetId)

Nouvelle façon de lire un jeu de données
Avec les mises à jour des recettes Spark, plusieurs valeurs doivent être ajoutées et modifiées. Tout d'abord, DataSetOptions n'est plus utilisé. Replace DataSetOptions with QSOption . En outre, de nouveaux option paramètres sont requis. Les deux QSOption.mode et QSOption.datasetId sont nécessaires. Enfin, orgId et serviceApiKey doit être remplacé par imsOrg et apiKey . Examinez l'exemple suivant pour comparer la lecture des jeux de données :
import com.adobe.platform.query.QSOption
var df = sparkSession.read.format("com.adobe.platform.query")
  .option(QSOption.userToken", {userToken})
  .option(QSOption.serviceToken, {serviceToken})
  .option(QSOption.imsOrg, {orgId})
  .option(QSOption.apiKey, {apiKey})
  .option(QSOption.mode, "interactive")
  .option(QSOption.datasetId, {dataSetId})
  .load()

Le mode interactif expire si les requêtes durent plus de 10 minutes. Si vous ingérez plus de quelques gigaoctets de données, il est recommandé de passer en mode "batch". Le mode de traitement par lots prend plus de temps à début, mais il peut gérer des ensembles de données plus volumineux.

Écrire dans un jeu de données

Cette section décrit les modifications nécessaires à la création d’un jeu de données à l’aide de l’exemple ScoringDataSaver.scala fourni par Adobe.
Ancienne méthode d'écriture d'un jeu de données
df.write.format("com.adobe.platform.dataset")
    .option(DataSetOptions.orgId, orgId)
    .option(DataSetOptions.serviceToken, serviceToken)
    .option(DataSetOptions.userToken, userToken)
    .option(DataSetOptions.serviceApiKey, apiKey)
    .save(scoringResultsDataSetId)

Nouvelle méthode d'écriture d'un jeu de données
Avec les mises à jour des recettes Spark, plusieurs valeurs doivent être ajoutées et modifiées. Tout d'abord, DataSetOptions n'est plus utilisé. Replace DataSetOptions with QSOption . En outre, de nouveaux option paramètres sont requis. QSOption.datasetId est nécessaire et remplace la nécessité de charger le {dataSetId} dans .save() . Enfin, orgId et serviceApiKey doit être remplacé par imsOrg et apiKey . Consultez l'exemple suivant pour obtenir une comparaison sur l'écriture de jeux de données :
import com.adobe.platform.query.QSOption
df.write.format("com.adobe.platform.query")
  .option(QSOption.userToken", {userToken})
  .option(QSOption.serviceToken, {serviceToken})
  .option(QSOption.imsOrg, {orgId})
  .option(QSOption.apiKey, {apiKey})
  .option(QSOption.datasetId, {dataSetId})
  .save()

Fichiers source basés sur le dossier d’assemblage (Spark)

Début en accédant au répertoire où se trouve votre recette.
Les sections suivantes utilisent la nouvelle recette Ventes au détail de Scala qui se trouve dans le référentiel public Github de Data Science Workspace.

Télécharger l'exemple de recette (Spark)

L'exemple de recette contient des fichiers qui doivent être copiés vers votre recette existante. Pour cloner le Github public qui contient tous les exemples de recettes, entrez ce qui suit en terminal :
git clone https://github.com/adobe/experience-platform-dsw-reference.git

La recette Scala se trouve dans le répertoire suivant experience-platform-dsw-reference/recipes/scala/retail .

Ajouter le fichier Dockerfile (Spark)

Un nouveau fichier est nécessaire dans votre dossier de recette pour utiliser le flux de travail basé sur le docker. Copiez et collez le fichier Dockerfile du dossier des recettes situé dans experience-platform-dsw-reference/recipes/scala/Dockerfile . Vous pouvez également copier et coller le code ci-dessous dans un nouveau fichier appelé Dockerfile .
L'exemple de fichier jar illustré ci-dessous ml-retail-sample-spark-*-jar-with-dependencies.jar doit être remplacé par le nom du fichier jar de votre recette.
FROM adobe/acp-dsw-ml-runtime-spark:0.0.1

COPY target/ml-retail-sample-spark-*-jar-with-dependencies.jar /application.jar

Modifier les dépendances (Spark)

Si vous utilisez une recette existante, des modifications sont requises dans le fichier pom.xml pour les dépendances. Remplacez la version de dépendance model-authoring-sdk par 2.0.0. Ensuite, mettez à jour la version Spark du fichier pom vers 2.4.3 et la version Scala vers 2.11.12.
<groupId>com.adobe.platform.ml</groupId>
<artifactId>authoring-sdk_2.11</artifactId>
<version>2.0.0</version>
<classifier>jar-with-dependencies</classifier>

Préparation de vos scripts Docker (Spark)

Les recettes Spark n'utilisent plus d'artefacts binaires et nécessitent à la place la création d'une image Docker. Si vous ne l'avez pas fait, téléchargez et installez Docker .
Dans l'exemple de recette Scala fourni, vous pouvez trouver les scripts login.sh et build.sh se trouver dans experience-platform-dsw-reference/recipes/scala/ . Copiez et collez ces fichiers dans votre recette existante.
Votre structure de dossiers doit maintenant ressembler à l’exemple suivant (les fichiers récemment ajoutés sont mis en surbrillance) :
L'étape suivante consiste à suivre les fichiers source du package dans un didacticiel de recette . Ce didacticiel comporte une section qui décrit la création d'une image de docker pour une recette Scala (Spark). Une fois l'opération terminée, vous recevez l'image du Docker dans un Registre de Conteneur Azure avec l'URL de l'image correspondante.

Créer une recette (Spark)

Pour créer une recette, vous devez d'abord compléter le didacticiel sur les fichiers source du package et disposer de l'URL de l'image du dossier. Vous pouvez créer une recette à l'aide de l'interface utilisateur ou de l'API.
Pour créer votre recette à l'aide de l'interface utilisateur, suivez le didacticiel d'importation d'une recette emballée (IU) pour Scala.
Pour créer votre recette à l'aide de l'API, suivez le didacticiel d'importation de recette (API) emballée pour Scala.

Guide de migration PySpark

L'artefact de recette généré par les étapes de création est maintenant une image Docker qui contient votre fichier binaire .egg. De plus, la syntaxe utilisée pour lire et écrire des jeux de données à l'aide du SDK de plate-forme a changé et vous oblige à modifier votre code de recette.
La vidéo suivante est conçue pour aider à mieux comprendre les modifications requises pour les recettes PySpark :

Lecture et écriture de jeux de données (PySpark)

Avant de créer l'image Docker, consultez les exemples de lecture et d'écriture de jeux de données dans le SDK de la plate-forme, fournis dans les sections ci-dessous. Si vous convertissez des recettes existantes, votre code SDK de plateforme doit être mis à jour.

Lecture d’un jeu de données

Cette section décrit les modifications nécessaires à la lecture d’un jeu de données à l’aide de l’exemple helper.py fourni par Adobe.
Ancienne manière de lire un jeu de données
dataset_options = get_dataset_options(spark.sparkContext)
pd = spark.read.format("com.adobe.platform.dataset") 
  .option(dataset_options.serviceToken(), service_token) 
  .option(dataset_options.userToken(), user_token) 
  .option(dataset_options.orgId(), org_id) 
  .option(dataset_options.serviceApiKey(), api_key)
  .load(dataset_id)

Nouvelle façon de lire un jeu de données
Avec les mises à jour des recettes Spark, plusieurs valeurs doivent être ajoutées et modifiées. Tout d'abord, DataSetOptions n'est plus utilisé. Replace DataSetOptions with qs_option . En outre, de nouveaux option paramètres sont requis. Les deux qs_option.mode et qs_option.datasetId sont nécessaires. Enfin, orgId et serviceApiKey doit être remplacé par imsOrg et apiKey . Examinez l'exemple suivant pour comparer la lecture des jeux de données :
qs_option = spark_context._jvm.com.adobe.platform.query.QSOption
pd = sparkSession.read.format("com.adobe.platform.query") 
  .option(qs_option.userToken, {userToken}) 
  .option(qs_option.serviceToken, {serviceToken}) 
  .option(qs_option.imsOrg, {orgId}) 
  .option(qs_option.apiKey, {apiKey}) 
  .option(qs_option.mode, "interactive") 
  .option(qs_option.datasetId, {dataSetId}) 
  .load()

Le mode interactif expire si les requêtes durent plus de 10 minutes. Si vous ingérez plus de quelques gigaoctets de données, il est recommandé de passer en mode "batch". Le mode de traitement par lots prend plus de temps à début, mais il peut gérer des ensembles de données plus volumineux.

Écrire dans un jeu de données

Cette section décrit les modifications nécessaires à la création d’un jeu de données à l’aide de l’exemple data_saver.py fourni par Adobe.
Ancienne méthode d'écriture d'un jeu de données
df.write.format("com.adobe.platform.dataset")
  .option(DataSetOptions.orgId, orgId)
  .option(DataSetOptions.serviceToken, serviceToken)
  .option(DataSetOptions.userToken, userToken)
  .option(DataSetOptions.serviceApiKey, apiKey)
  .save(scoringResultsDataSetId)

Nouvelle méthode d'écriture d'un jeu de données
Avec les mises à jour des recettes PySpark, un certain nombre de valeurs doivent être ajoutées et modifiées. Tout d'abord, DataSetOptions n'est plus utilisé. Replace DataSetOptions with qs_option . En outre, de nouveaux option paramètres sont requis. qs_option.datasetId est nécessaire et remplace la nécessité de charger le {dataSetId} dans .save() . Enfin, orgId et serviceApiKey doit être remplacé par imsOrg et apiKey . Examinez l'exemple suivant pour comparer la lecture des jeux de données :
qs_option = spark_context._jvm.com.adobe.platform.query.QSOption
scored_df.write.format("com.adobe.platform.query") 
  .option(qs_option.userToken, {userToken}) 
  .option(qs_option.serviceToken, {serviceToken}) 
  .option(qs_option.imsOrg, {orgId}) 
  .option(qs_option.apiKey, {apiKey}) 
  .option(qs_option.datasetId, {dataSetId}) 
  .save()

Fichiers source basés sur le dossier d’assemblage (PySpark)

Début en accédant au répertoire où se trouve votre recette.
Pour cet exemple, la nouvelle recette Ventes au détail de PySpark est utilisée et se trouve dans le référentiel Github public de Data Science Workspace.

Télécharger l'exemple de recette (PySpark)

L'exemple de recette contient des fichiers qui doivent être copiés vers votre recette existante. Pour cloner le Github public qui contient tous les exemples de recettes, entrez ce qui suit en terminal.
git clone https://github.com/adobe/experience-platform-dsw-reference.git

La recette PySpark se trouve dans le répertoire suivant experience-platform-dsw-reference/recipes/pyspark .

Ajouter le fichier Dockerfile (PySpark)

Un nouveau fichier est nécessaire dans votre dossier de recette pour utiliser le flux de travail basé sur le docker. Copiez et collez le fichier Dockerfile du dossier des recettes situé dans experience-platform-dsw-reference/recipes/pyspark/Dockerfile . Vous pouvez également copier et coller le code ci-dessous et créer un nouveau fichier appelé Dockerfile .
L'exemple de fichier d'oeufs illustré ci-dessous pysparkretailapp-*.egg doit être remplacé par le nom du fichier d'oeufs de votre recette.
FROM adobe/acp-dsw-ml-runtime-pyspark:0.0.1
RUN mkdir /recipe

COPY . /recipe

RUN cd /recipe && \
    ${PYTHON} setup.py clean install && \
    rm -rf /recipe

RUN cp /databricks/conda/envs/${DEFAULT_DATABRICKS_ROOT_CONDA_ENV}/lib/python3.6/site-packages/pysparkretailapp-*.egg /application.egg

Préparation de vos scripts Docker (PySpark)

Les recettes PySpark n'utilisent plus d'artefacts binaires et nécessitent à la place la création d'une image Docker. Si vous ne l'avez pas fait, téléchargez et installez Docker .
Dans l'exemple de recette fournie par PySpark, vous pouvez trouver les scripts login.sh et les build.sh trouver dans experience-platform-dsw-reference/recipes/pyspark . Copiez et collez ces fichiers dans votre recette existante.
Votre structure de dossiers doit maintenant ressembler à l’exemple suivant (les fichiers récemment ajoutés sont mis en surbrillance) :
Votre recette est maintenant prête à être créée à l'aide d'une image Docker. L'étape suivante consiste à suivre les fichiers source du package dans un didacticiel de recette . Ce didacticiel comporte une section qui décrit la création d'une image de docker pour une recette PySpark (Spark 2.4). Une fois l'opération terminée, vous recevez l'image du Docker dans un Registre de Conteneur Azure avec l'URL de l'image correspondante.

Créer une recette (PySpark)

Pour créer une recette, vous devez d'abord compléter le didacticiel sur les fichiers source du package et disposer de l'URL de l'image du dossier. Vous pouvez créer une recette à l'aide de l'interface utilisateur ou de l'API.
Pour créer votre recette à l'aide de l'interface utilisateur, suivez le didacticiel d'importation d'une recette emballée (IU) pour PySpark.
Pour créer votre recette à l'aide de l'API, suivez le didacticiel d'importation de recette (API) emballée pour PySpark.

Guides de migration vers les ordinateurs portables

Les dernières modifications apportées aux portables JupyterLab exigent que vous mettiez à jour vos portables PySpark et Spark 2.3 en 2.4. Grâce à cette modification, JupyterLab Launcher a été mis à jour avec de nouveaux portables de démarrage. Pour obtenir un guide détaillé sur la conversion de vos blocs-notes, sélectionnez l'un des guides suivants :
La vidéo suivante est conçue pour aider à mieux comprendre les modifications requises pour les portables JupyterLab :

Guide de migration des ordinateurs portables PySpark 2.3 à 2.4

Avec l'introduction de PySpark 2.4 sur les portables JupyterLab, les nouveaux portables Python avec PySpark 2.4 utilisent maintenant le noyau Python 3 au lieu du noyau PySpark 3. Cela signifie que le code existant s’exécutant sur PySpark 2.3 n’est pas pris en charge dans PySpark 2.4.
PySpark 2.3 est obsolète et doit être supprimé dans une version ultérieure. Tous les exemples existants sont définis pour être remplacés par des exemples PySpark 2.4.
Pour convertir vos blocs-notes PySpark 3 (Spark 2.3) existants en Spark 2.4, suivez les exemples décrits ci-dessous :

Noyau

Les portables PySpark 3 (Spark 2.4) utilisent le noyau Python 3 plutôt que le noyau PySpark déconseillé utilisé dans les portables PySpark 3 (Spark 2.3 - désapprouvé).
Pour confirmer ou modifier le noyau dans l'interface utilisateur de JupyterLab, sélectionnez le bouton du noyau situé dans la barre de navigation supérieure droite de votre bloc-notes. Si vous utilisez l'un des portables de lanceur prédéfinis, le noyau est présélectionné. L'exemple ci-dessous utilise le démarrage du bloc-notes Agrégation PySpark 3 (Spark 2.4).
La sélection du menu déroulant ouvre une liste de noyaux disponibles.
Pour les blocs-notes PySpark 3 (Spark 2.4), sélectionnez le noyau Python 3 et confirmez en cliquant sur le bouton Sélectionner .

Initialisation de sparkSession

Tous les ordinateurs portables Spark 2.4 nécessitent que vous initialisiez la session avec le nouveau code standard.
Ordinateur portable PySpark 3 (Spark 2.3 - désapprouvée) PySpark 3 (Spark 2.4)
Noyau PySpark 3 Python 3
Code
  étincelle


à partir de pyspark.sql, importez SparkSessionspark = SparkSession.builder.getOrCreate()


Les images suivantes mettent en évidence les différences de configuration pour PySpark 2.3 et PySpark 2.4. Cet exemple utilise les blocs-notes de démarrage Aggregation fournis dans JupyterLab Launcher.
Exemple de configuration pour la version 2.3 (obsolète)
Exemple de configuration pour la version 2.4

Utilisation de la magie %dataset

Avec l'introduction de Spark 2.4, la magie %dataset personnalisée est fournie pour les nouveaux portables PySpark 3 (Spark 2.4) (noyau Python 3).
Utilisation
%dataset {action} --datasetId {id} --dataFrame {df}
Description
Commande magique Data Science Workspace personnalisée pour lire ou écrire un jeu de données à partir d'un bloc-notes Python (noyau Python 3).
  • : Type d’action à exécuter sur le jeu de données. Deux actions sont disponibles "read" ou "write".
  • —datasetId : Utilisé pour fournir l'identifiant du jeu de données à lire ou à écrire. Il s'agit d'un argument obligatoire.
  • —dataFrame : La base de données des pandas. Il s'agit d'un argument obligatoire.
    • Lorsque l'action est "read", est la variable où les résultats de l'opération de lecture du jeu de données sont disponibles.
    • Lorsque l'action est "write", ce dataframe est écrit dans le dataset.
  • —mode (facultatif) : Les paramètres autorisés sont "batch" et "interactive". Par défaut, le mode est défini sur "interactif". Il est recommandé d’utiliser le mode "batch" lors de la lecture de grandes quantités de données.
Exemples
  • Exemple de lecture : %dataset read --datasetId 5e68141134492718af974841 --dataFrame pd0
  • Exemple d'écriture : %dataset write --datasetId 5e68141134492718af974842 --dataFrame pd0

Charger dans un cadre de données dans LocalContext

Avec l'introduction de Spark 2.4, la magie %dataset personnalisée est fournie. L’exemple suivant illustre les principales différences de chargement de la base de données dans les blocs-notes PySpark (Spark 2.3) et PySpark (Spark 2.4) :
Utilisation de PySpark 3 (Spark 2.3 - désapprouvée) - Noyau PySpark 3
dataset_options = sc._jvm.com.adobe.platform.dataset.DataSetOptions
pd0 = spark.read.format("com.adobe.platform.dataset")
  .option(dataset_options.orgId(), "310C6D375BA5248F0A494212@AdobeOrg")
  .load("5e68141134492718af974844")

Utilisation de PySpark 3 (Spark 2.4) - noyau Python 3
%dataset read --datasetId 5e68141134492718af974844 --dataFrame pd0

Élément
Description
pd0
Nom de l’objet de dataframe pandas à utiliser ou à créer.
Magie personnalisée pour l'accès aux données dans le noyau Python3.
Les images suivantes mettent en évidence les principales différences de chargement des données pour PySpark 2.3 et PySpark 2.4. Cet exemple utilise les blocs-notes de démarrage Agrégation fournis par JupyterLab Launcher.
Chargement de données dans PySpark 2.3 (jeu de données Luma) - obsolète
Chargement de données dans PySpark 2.4 (jeu de données Luma)
Avec PySpark 3 (Spark 2.4) sc = spark.sparkContext est défini lors du chargement.
Chargement des données de la plate-forme Experience Cloud dans PySpark 2.3 - obsolète
Chargement des données de la plate-forme Experience Cloud dans PySpark 2.4
Avec PySpark 3 (Spark 2.4), il org_id n'est plus nécessaire de définir la variable dataset_id et non plus. De plus, df = spark.read.format a été remplacé par une magie personnalisée %dataset pour faciliter la lecture et l'écriture des jeux de données.
Élément
description
Magie personnalisée pour l'accès aux données dans le noyau Python3.
—mode peut être défini sur interactive ou batch . La valeur par défaut de —mode est interactive . Il est recommandé d’utiliser batch le mode lors de la lecture de grandes quantités de données.

Création d’un cadre de données local

Avec PySpark 3 (Spark 2.4) %% sparkmagn'est plus pris en charge. Les opérations suivantes ne peuvent plus être utilisées :
  • %%help
  • %%info
  • %%cleanup
  • %%delete
  • %%configure
  • %%local
Le tableau suivant présente les modifications nécessaires à la conversion des requêtes %%sql sparkmiracle :
Ordinateur portable PySpark 3 (Spark 2.3 - désapprouvée) PySpark 3 (Spark 2.4)
Noyau PySpark 3 Python 3
Code
%%sql -o dfselect * from sparkdf


 %%sql -o df -n limitselect * from sparkdf


%%sql -o df -qselect * from sparkdf


 %%sql -o df -r fractionselect * from sparkdf


df = spark.sql(''' SELECT * FROM sparkdf''')


df = spark.sql(''' SELECT * FROM sparkdf LIMIT limit'')


df = spark.sql(''' SELECT * FROM sparkdf LIMIT limit'')


sample_df = df.sample(fraction)


Vous pouvez également spécifier un échantillon de semences facultatif, tel qu’un booléen avec remplacement, une fraction de doublon ou une graine longue.
Les images suivantes mettent en évidence les principales différences de création d'une base de données locale dans PySpark 2.3 et PySpark 2.4. Cet exemple utilise les blocs-notes de démarrage Agrégation fournis dans JupyterLab Launcher.
Création d'une base de données locale PySpark 2.3 - obsolète
Création d’une base de données locale PySpark 2.4
Avec PySpark 3 (Spark 2.4) %%sql SparkMagic n’est plus pris en charge et a été remplacé par le texte suivant :

Écrire dans un jeu de données

Avec l'introduction de Spark 2.4, la magie %dataset personnalisée est fournie ce qui rend l'écriture des jeux de données plus propre. Pour écrire dans un jeu de données, utilisez l’exemple Spark 2.4 suivant :
Utilisation de PySpark 3 (Spark 2.3 - désapprouvée) - Noyau PySpark 3
userToken = spark.sparkContext.getConf().get("spark.yarn.appMasterEnv.USER_TOKEN")
serviceToken = spark.sparkContext.getConf().get("spark.yarn.appMasterEnv.SERVICE_TOKEN")
serviceApiKey = spark.sparkContext.getConf().get("spark.yarn.appMasterEnv.SERVICE_API_KEY")

dataset_options = sc._jvm.com.adobe.platform.dataset.DataSetOptions

pd0.write.format("com.adobe.platform.dataset")
  .option(dataset_options.orgId(), "310C6D375BA5248F0A494212@AdobeOrg")
  .option(dataset_options.userToken(), userToken)
  .option(dataset_options.serviceToken(), serviceToken)
  .option(dataset_options.serviceApiKey(), serviceApiKey)
  .save("5e68141134492718af974844")

Utilisation de PySpark 3 (Spark 2.4) - noyau Python 3
%dataset write --datasetId 5e68141134492718af974844 --dataFrame pd0
pd0.describe()
pd0.show(10, False)

Élément
description
pd0
Nom de l’objet de dataframe pandas à utiliser ou à créer.
Magie personnalisée pour l'accès aux données dans le noyau Python3.
—mode peut être défini sur interactive ou batch . La valeur par défaut de —mode est interactive . Il est recommandé d’utiliser batch le mode lors de la lecture de grandes quantités de données.
Les illustrations suivantes mettent en évidence les principales différences d'écriture des données sur la plateforme dans PySpark 2.3 et PySpark 2.4. Cet exemple utilise les blocs-notes de démarrage Agrégation fournis dans JupyterLab Launcher.
Rédaction de données vers Platform PySpark 2.3 - obsolète
dataframe 1
Rédaction de données vers Platform PySpark 2.4
Avec PySpark 3 (Spark 2.4), la magie %dataset personnalisée élimine la nécessité de définir des valeurs telles que userToken , serviceToken , serviceApiKey et .option . En outre, orgId il n'est plus nécessaire de définir ce qui suit.

Guide de migration des ordinateurs portables Spark 2.3 vers Spark 2.4 (Scala)

Avec l'introduction de Spark 2.4 sur les portables JupyterLab, les portables Spark (Spark 2.3) existants utilisent maintenant le noyau Scala au lieu du noyau Spark. Cela signifie que le code existant s’exécutant sur Spark (Spark 2.3) n’est pas pris en charge dans Scala (Spark 2.4). De plus, tous les nouveaux portables Spark doivent utiliser Scala (Spark 2.4) dans le lanceur JupyterLab.
Spark (Spark 2.3) est obsolète et doit être supprimé dans une version ultérieure. Tous les exemples existants sont définis pour être remplacés par des exemples Scala (Spark 2.4).
Pour convertir vos blocs-notes Spark (Spark 2.3) existants en Scala (Spark 2.4), suivez les exemples décrits ci-dessous :

Noyau

Les ordinateurs portables Scala (Spark 2.4) utilisent le noyau Scala au lieu du noyau Spark obsolète utilisé dans les ordinateurs portables Spark (Spark 2.3 - désapprouvé).
Pour confirmer ou modifier le noyau dans l'interface utilisateur de JupyterLab, sélectionnez le bouton du noyau situé dans la barre de navigation supérieure droite de votre bloc-notes. La fenêtre contextuelle Sélectionner le noyau s'affiche. Si vous utilisez l'un des portables de lanceur prédéfinis, le noyau est présélectionné. L'exemple ci-dessous utilise le bloc-notes Scala Clustering dans JupyterLab Launcher.
La sélection du menu déroulant ouvre une liste de noyaux disponibles.
Pour les blocs-notes Scala (Spark 2.4), sélectionnez le noyau Scala et confirmez en cliquant sur le bouton Sélectionner .

Initialisation de SparkSession

Tous les ordinateurs portables Scala (Spark 2.4) exigent que vous initialisiez la session avec le code standard suivant :
Ordinateur portable Spark (Spark 2.3 - désapprouvée) Scala (Spark 2.4)
Noyau Spark Scala
code aucun code requis
import org.apache.spark.sql.{ SparkSession}val spark = SparkSession.builder() .master("local") .getOrCreate()


L'image Scala (Spark 2.4) ci-dessous illustre la différence fondamentale dans l'initialisation de sparkSession avec le noyau Spark 2.3 Spark et le noyau Spark 2.4 Scala. Cet exemple utilise les blocs-notes de démarrage Mise en grappe fournis par JupyterLab Launcher.
Spark (Spark 2.3 - désapprouvée)
Spark (Spark 2.3 - désapprouvée) utilise le noyau Spark, et par conséquent, vous n'étiez pas obligé de définir Spark.
Scala (Spark 2.4)
L'utilisation de Spark 2.4 avec le noyau Scala requiert que vous définissiez val spark et importez SparkSesson pour pouvoir lire ou écrire :

Données de Requête

Avec Scala (Spark 2.4) %% sparkmagic n'est plus pris en charge. Les opérations suivantes ne peuvent plus être utilisées :
  • %%help
  • %%info
  • %%cleanup
  • %%delete
  • %%configure
  • %%local
Le tableau suivant présente les modifications nécessaires à la conversion des requêtes %%sql sparkmiracle :
Ordinateur portable Spark (Spark 2.3 - désapprouvée) Scala (Spark 2.4)
Noyau Spark Scala
code
%%sql -o dfselect * from sparkdf


%%sql -o df -n limitselect * from sparkdf


%%sql -o df -qselect * from sparkdf


%%sql -o df -r fractionselect * from sparkdf


val df = spark.sql('''' SELECT * FROM sparkdf''')


val df = spark.sql('''' SELECT * FROM sparkdf LIMIT limit'')


val df = spark.sql('''' SELECT * FROM sparkdf LIMIT limit'')


val sample_df = df.sample(fraction) 

L'image Scala (Spark 2.4) ci-dessous illustre les principales différences de création de requêtes avec le noyau Spark 2.3 Spark et le noyau Spark 2.4 Scala. Cet exemple utilise les blocs-notes de démarrage Mise en grappe fournis par JupyterLab Launcher.
Spark (Spark 2.3 - désapprouvée)
Le bloc-notes Spark (Spark 2.3 - désapprouvée) utilise le noyau Spark. Le noyau Spark prend en charge et utilise %%sql sparkmiracle.
Scala (Spark 2.4)
Le noyau Scala ne prend plus en charge %%sql sparkmiracle. Le code sparkmagic existant doit être converti.

Lecture d’un jeu de données

Dans Spark 2.3, vous deviez définir des variables pour option les valeurs utilisées pour lire les données ou utiliser les valeurs brutes dans la cellule de code. Dans Scala, vous pouvez utiliser sys.env("PYDASDK_IMS_USER_TOKEN") pour déclarer et renvoyer une valeur, ce qui élimine la nécessité de définir des variables telles que var userToken . Dans l’exemple Scala (Spark 2.4) ci-dessous, sys.env est utilisé pour définir et renvoyer toutes les valeurs requises pour lire un jeu de données.
Utilisation de Spark (Spark 2.3 - désapprouvée) - Noyau Spark
import com.adobe.platform.dataset.DataSetOptions
var df1 = spark.read.format("com.adobe.platform.dataset")
  .option(DataSetOptions.orgId, "310C6D375BA5248F0A494212@AdobeOrg")
  .option(DataSetOptions.batchId, "dbe154d3-197a-4e6c-80f8-9b7025eea2b9")
  .load("5e68141134492718af974844")

Utilisation de Scala (Spark 2.4) - Noyau Scala
import org.apache.spark.sql.{Dataset, SparkSession}
val spark = SparkSession.builder().master("local").getOrCreate()
val df1 = spark.read.format("com.adobe.platform.query")
  .option("user-token", sys.env("PYDASDK_IMS_USER_TOKEN"))
  .option("ims-org", sys.env("IMS_ORG_ID"))
  .option("api-key", sys.env("PYDASDK_IMS_CLIENT_ID"))
  .option("service-token", sys.env("PYDASDK_IMS_SERVICE_TOKEN"))
  .option("mode", "interactive")
  .option("dataset-id", "5e68141134492718af974844")
  .load()

element
description
df1
Variable qui représente la base de données Pandas utilisée pour lire et écrire des données.
user-token
Votre jeton utilisateur qui est automatiquement récupéré à l’aide de sys.env("PYDASDK_IMS_USER_TOKEN") .
service-token
Votre jeton de service automatiquement récupéré à l’aide de sys.env("PYDASDK_IMS_SERVICE_TOKEN") .
ims-org
Votre identifiant ims-org automatiquement récupéré à l’aide de sys.env("IMS_ORG_ID") .
api-key
Votre clé api automatiquement récupérée à l’aide de sys.env("PYDASDK_IMS_CLIENT_ID") .
Les images ci-dessous mettent en évidence les principales différences de chargement des données avec Spark 2.3 et Spark 2.4. Cet exemple utilise les blocs-notes de démarrage Clustering fournis dans JupyterLab Launcher.
Spark (Spark 2.3 - désapprouvée)
Le bloc-notes Spark (Spark 2.3 - désapprouvée) utilise le noyau Spark. Les deux cellules suivantes présentent un exemple de chargement du jeu de données avec un ID de jeu de données spécifié dans la plage de dates (3-21/2019-3-29).
Scala (Spark 2.4)
Le bloc-notes Scala (Spark 2.4) utilise le noyau Scala qui nécessite plus de valeurs lors de la configuration, comme indiqué dans la première cellule de code. En outre, var mdata il faut option remplir davantage de valeurs. Dans ce bloc-notes, le code mentionné précédemment pour initialiser SparkSession est inclus dans la cellule de var mdata code.
Dans Scala, vous pouvez utiliser sys.env() pour déclarer et renvoyer une valeur de l’intérieur option . Cela évite de définir des variables si vous savez qu’elles ne seront utilisées qu’une seule fois. L’exemple suivant illustre val userToken l’exemple ci-dessus et le déclare en ligne dans option :
.option("user-token", sys.env("PYDASDK_IMS_USER_TOKEN"))

Écrire dans un jeu de données

Comme pour lire un jeu de données , l’écriture dans un jeu de données nécessite des option valeurs supplémentaires décrites dans l’exemple ci-dessous. Dans Scala, vous pouvez utiliser sys.env("PYDASDK_IMS_USER_TOKEN") pour déclarer et renvoyer une valeur, ce qui élimine la nécessité de définir des variables telles que var userToken . Dans l'exemple Scala ci-dessous, sys.env est utilisé pour définir et renvoyer toutes les valeurs requises pour écrire dans un jeu de données.
Utilisation de Spark (Spark 2.3 - désapprouvée) - Noyau Spark
import com.adobe.platform.dataset.DataSetOptions

var userToken = spark.sparkContext.getConf.getOption("spark.yarn.appMasterEnv.USER_TOKEN").get
var serviceToken = spark.sparkContext.getConf.getOption("spark.yarn.appMasterEnv.SERVICE_TOKEN").get
var serviceApiKey = spark.sparkContext.getConf.getOption("spark.yarn.appMasterEnv.SERVICE_API_KEY").get

df1.write.format("com.adobe.platform.dataset")
  .option(DataSetOptions.orgId, "310C6D375BA5248F0A494212@AdobeOrg")
  .option(DataSetOptions.userToken, userToken)
  .option(DataSetOptions.serviceToken, serviceToken)
  .option(DataSetOptions.serviceApiKey, serviceApiKey)
  .save("5e68141134492718af974844")

Utilisation de Scala (Spark 2.4) - Noyau Scala
import org.apache.spark.sql.{Dataset, SparkSession}

val spark = SparkSession.builder().master("local").getOrCreate()

df1.write.format("com.adobe.platform.query")
  .option("user-token", sys.env("PYDASDK_IMS_USER_TOKEN"))
  .option("service-token", sys.env("PYDASDK_IMS_SERVICE_TOKEN"))
  .option("ims-org", sys.env("IMS_ORG_ID"))
  .option("api-key", sys.env("PYDASDK_IMS_CLIENT_ID"))
  .option("mode", "interactive")
  .option("dataset-id", "5e68141134492718af974844")
  .save()

element
description
df1
Variable qui représente la base de données Pandas utilisée pour lire et écrire des données.
user-token
Votre jeton utilisateur qui est automatiquement récupéré à l’aide de sys.env("PYDASDK_IMS_USER_TOKEN") .
service-token
Votre jeton de service automatiquement récupéré à l’aide de sys.env("PYDASDK_IMS_SERVICE_TOKEN") .
ims-org
Votre identifiant ims-org automatiquement récupéré à l’aide de sys.env("IMS_ORG_ID") .
api-key
Votre clé api automatiquement récupérée à l’aide de sys.env("PYDASDK_IMS_CLIENT_ID") .