Show Menu
SUJETS×

Guides de migration des recettes et des blocs-notes

Les ordinateurs portables et les recettes utilisant Python/R ne sont pas concernés. La migration ne s'applique qu'aux recettes et cahiers PySpark/Spark (2.3).
Les guides suivants décrivent les étapes et les informations requises pour migrer des recettes et des cahiers de notes existants.

Spark guide de migration

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 Platform SDK a été modifiée et nécessite la modification du code de la recette.
La vidéo suivante est conçue pour aider à mieux comprendre les changements nécessaires pour Spark les recettes :

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 Platform SDK, fournis dans les sections ci-dessous. Si vous convertissez des recettes existantes, votre code Platform SDK 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 Spark recettes, un certain nombre de 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 Spark recettes, un certain nombre de 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()

compresser les fichiers source basés sur le dossier (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 Spark version 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)

Spark les recettes 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éation d’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 Platform SDK a été modifiée et nécessite la modification du code de la 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 Platform SDK, fournis dans les sections ci-dessous. Si vous convertissez des recettes existantes, votre code Platform SDK 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 Spark recettes, 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. 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 public Github 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 JupyterLab portables nécessitent la mise à jour de vos PC portables PySpark et Spark 2.3 vers la version 2.4. Grâce à cette modification, JupyterLab Launcher a été mis à jour avec de nouveaux PC 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 JupyterLab Notebooks:

Guide de migration des ordinateurs portables PySpark 2.3 à 2.4

Avec l'introduction de PySpark 2.4 à JupyterLab Notebooks, de nouveaux Python portables 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 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' JupyterLab interface utilisateur, 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-notesSpark Agrégation PySpark 3 ( 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 Spark ordinateurs portables 2.4 nécessitent que vous initialisiez la session avec le nouveau code standard.
Ordinateur portable PySpark 3 ([!DNL Spark] 2.3 - désapprouvée) PySpark 3 ([!DNL Spark] 2.4)
Noyau PySpark 3 Python 3
Code
  [!DNL é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 la Spark 2.4, %dataset la magie personnalisée est fournie pour l'utilisation dans les nouveaux portables PySpark 3 (Spark 2.4) (noyauPython 3).
Utilisation
%dataset {action} --datasetId {id} --dataFrame {df}
Description
Commande Data Science Workspace magique personnalisée pour lire ou écrire un jeu de données à partir d'un Python bloc-notes (noyauPython 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 la 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 (Spark2.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 (Spark2.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 Python 3.
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 Aggregation fournis dans 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.
ChargementExperience Cloud Platformde données dans PySpark 2.3 - obsolète
ChargementExperience Cloud Platformdes données dans PySpark 2.4
Avec PySpark 3 (Spark 2.4), il n' org_id 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 Python 3.
—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), %% 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 PySpark 3 ([!DNL Spark] 2.3 - désapprouvée) PySpark 3 ([!DNL Spark] 2.4)
Noyau PySpark 3 [!DNL 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 la 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 2.4 Spark :
Utilisation de PySpark 3 (Spark2.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 (Spark2.4) -Python3 noyau
%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 Python 3.
—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 dans Platform 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 dansPlatformPySpark 2.3 - obsolète
dataframe 1
Rédaction de données dansPlatformPySpark 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.

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

Avec l'introduction de Spark 2.4 à JupyterLab Notebooks, les portables Spark existants (Spark 2.3) 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 Spark portables doivent utiliser Scala (Spark 2.4) dans le JupyterLab Launcher.
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 ci-dessous :

Noyau

Les portables Scala (Spark 2.4) utilisent le noyau Scala plutôt que le Spark noyau obsolète utilisé dans les Spark portables (Spark 2.3 - désapprouvé).
Pour confirmer ou modifier le noyau dans l' JupyterLab interface utilisateur, 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) nécessitent que vous initialisiez la session avec le code standard suivant :
Ordinateur portable Spark ([!DNL Spark] 2.3 - désapprouvée) Scala ([!DNL Spark] 2.4)
Noyau [!DNL 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 clé 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 dans JupyterLab Launcher.
Spark (Spark2.3 - obsolète)
Spark (Spark 2.3 - désapprouvée) utilise le Spark noyau, et par conséquent, vous n'étiez pas obligé de définir Spark.
Scala (Spark2.4)
L'utilisation de Spark la version 2.4 avec le noyau Scala requiert que vous définissiez val spark et importiez SparkSesson pour 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 [!DNL Spark] ([!DNL Spark] 2.3 - désapprouvée) Scala ([!DNL Spark] 2.4)
Noyau [!DNL 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 différences clés dans la 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 dans JupyterLab Launcher.
Spark (Spark2.3 - obsolète)
Le Spark bloc-notes (Spark 2.3 - désapprouvé) utilise le Spark noyau. Le Spark noyau prend en charge et utilise %%sql sparkmiracle.
Scala (Spark2.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 la Spark version 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.
UtilisationSpark (Spark2.3 - obsolète) -SparkNoyau
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 (Spark2.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 les versions Spark .3 et Spark 2.4. Cet exemple utilise les blocs-notes de démarrage Clustering fournis dans JupyterLab Launcher.
Spark (Spark2.3 - obsolète)
Le Spark bloc-notes (Spark 2.3 - désapprouvé) utilise le Spark noyau. 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 (Spark2.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.
UtilisationSpark (Spark2.3 - obsolète) -SparkNoyau
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 (Spark2.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") .