Exécuter l'outil de qualification pour l'exécution de requêtes natives

Pour identifier les charges de travail par lot qui peuvent s'exécuter plus rapidement avec l'exécution de requêtes natives (NQE), vous pouvez utiliser l'outil de qualification. Cet outil analyse les journaux d'événements Spark pour estimer les économies de temps d'exécution potentielles et identifier les opérations non compatibles avec le moteur NQE.

Google Cloud propose deux méthodes pour exécuter l'analyse de qualification : le job de qualification et le script de qualification. L'approche recommandée pour la plupart des utilisateurs est le job de qualification, qui automatise la découverte et l'analyse des charges de travail par lot. Le script de qualification alternatif est disponible pour le cas d'utilisation spécifique de l'analyse d'un fichier journal d'événements connu. Choisissez la méthode qui correspond le mieux à votre cas d'utilisation :

• Job de qualification (recommandé) : il s'agit de la méthode principale et recommandée. Il s'agit d'un job PySpark qui découvre et analyse automatiquement les charges de travail par lot récentes dans un ou plusieurs Google Cloud projets et régions. Utilisez cette méthode lorsque vous souhaitez effectuer une analyse globale sans avoir à localiser manuellement des fichiers journaux d'événements individuels. Cette approche est idéale pour évaluer à grande échelle l'adéquation de la NQE.

• Script de qualification (alternatif) : il s'agit d'une méthode alternative pour les cas d'utilisation avancés ou spécifiques. Il s'agit d'un script shell qui analyse un seul fichier journal d'événements Spark ou tous les journaux d'événements d'un répertoire Cloud Storage spécifique. Utilisez cette méthode si vous disposez du chemin d'accès Cloud Storage aux journaux d'événements que vous souhaitez analyser.

Job de qualification

Le job de qualification simplifie l'analyse à grande échelle en recherchant par programmation les charges de travail par lot Serverless pour Apache Spark et en envoyant un job d'analyse distribué. L'outil évalue les jobs dans votre organisation, ce qui vous évite d'avoir à rechercher et à spécifier manuellement les chemins d'accès aux journaux d'événements.

Accorder des rôles IAM

Pour que le job de qualification puisse accéder aux métadonnées de la charge de travail par lot et lire les journaux d'événements Spark dans Cloud Logging, le compte de service qui exécute la charge de travail doit disposer des rôles IAM suivants dans tous les projets à analyser :

• Lecteur Dataproc (roles/dataproc.viewer)
• Lecteur de journaux (roles/logging.viewer)

Envoyer le job de qualification

Vous envoyez le job de qualification à l'aide de l'outil gcloud CLI. Le job inclut un script PySpark et un fichier JAR hébergés dans un bucket Cloud Storage public.

Vous pouvez exécuter le job dans l'un des environnements d'exécution suivants :

• En tant que charge de travail par lot Serverless pour Apache Spark. Il s'agit d'une exécution de job simple et autonome.

• En tant que job qui s'exécute sur un cluster Dataproc sur Compute Engine. Cette approche peut être utile pour intégrer le job dans un workflow.

Arguments de la tâche

Argument	Description	Obligatoire ?	Valeur par défaut
--project-ids	Un seul ID de projet ou une liste d'ID de projet Google Cloud séparés par une virgule pour rechercher des charges de travail par lot.	Non	Projet dans lequel le job de qualification est en cours d'exécution.
--regions	Une seule région ou une liste de régions séparées par une virgule à analyser dans les projets spécifiés.	Non	Toutes les régions des projets spécifiés.
--start-time	Date de début du filtrage des lots. Seuls les lots créés à cette date ou après (format : AAAA-MM-JJ) seront analysés.	Non	Aucun filtre de date de début n'est appliqué.
--end-time	Date de fin du filtrage des lots. Seuls les lots créés à cette date ou avant (format : AAAA-MM-JJ) seront analysés.	Non	Aucun filtre de date de fin n'est appliqué.
--limit	Nombre maximal de lots à analyser par région. Les lots les plus récents sont analysés en premier.	Non	Tous les lots correspondant aux autres critères de filtrage sont analysés.
--output-gcs-path	Chemin d'accès Cloud Storage (par exemple, gs://your-bucket/output/) où les fichiers de résultats seront écrits.	Oui	Aucune.
--input-file	Chemin d'accès Cloud Storage à un fichier texte pour l'analyse groupée. Si cet argument est fourni, il remplace tous les autres arguments de définition de champ d'application (--project-ids, --regions, --start-time, --end-time, --limit).	Non	Aucune.

Exemples de jobs de qualification

• Job par lot Serverless pour Apache Spark permettant d'effectuer une analyse ad hoc simple. Les arguments du job sont listés après le séparateur --.

  gcloud dataproc batches submit pyspark gs://qualification-tool/performance-boost-qualification.py \
      --project=PROJECT_ID \
      --region=REGION \
      --jars=gs://qualification-tool/dataproc-perfboost-qualification-1.2.jar \
      -- \
      --project-ids=COMMA_SEPARATED_PROJECT_IDS \
      --regions=COMMA_SEPARATED_REGIONS \
      --limit=MAX_BATCHES \
      --output-gcs-path=gs://BUCKET
  

• Job par lot Serverless pour Apache Spark permettant d'analyser jusqu'à 50 des lots les plus récents trouvés dans sample_project dans la région us-central1. Les résultats sont écrits dans un bucket dans Cloud Storage. Les arguments du job sont listés après le séparateur --.

  gcloud dataproc batches submit pyspark gs://qualification-tool/performance-boost-qualification.py \
      --project=PROJECT_ID \
      --region=US-CENTRAL1 \
      --jars=gs://qualification-tool/dataproc-perfboost-qualification-1.2.jar \
      -- \
      --project-ids=PROJECT_ID \
      --regions=US-CENTRAL1 \
      --limit=50 \
      --output-gcs-path=gs://BUCKET/
  

• Job Dataproc sur Compute Engine envoyé à un cluster Dataproc pour une analyse groupée dans un workflow d'analyse à grande échelle, répétable ou automatisé. Les arguments du job sont placés dans un INPUT_FILE importé dans un BUCKET dans Cloud Storage. Cette méthode est idéale pour analyser différentes plages de dates ou limites de lots dans différents projets et régions en une seule exécution.

  gcloud dataproc jobs submit pyspark gs://qualification-tool/performance-boost-qualification.py \
      --cluster=CLUSTER_NAME \
      --region=REGION \
      --jars=gs://qualification-tool/dataproc-perfboost-qualification-1.2.jar \
      -- \
      --input-file=gs://INPUT_FILE \
      --output-gcs-path=gs://BUCKET
  

  Remarques :

  INPUT_FILE : chaque ligne du fichier représente une requête d'analyse distincte et utilise un format de flags à une seule lettre suivis de leurs valeurs, par exemple -p PROJECT-ID -r REGION -s START_DATE -e END_DATE -l LIMITS.

  Exemple de contenu de fichier d'entrée :

  -p project1 -r us-central1 -s 2024-12-01 -e 2024-12-15 -l 100
  -p project2 -r europe-west1 -s 2024-11-15 -l 50
  

  Ces arguments indiquent à l'outil d'analyser les deux champs d'application suivants :

  • Jusqu'à 100 lots dans le projet1 de la us-central1 région créés entre le 1er décembre 2025 et le 15 décembre 2025.
  • Jusqu'à 50 lots dans le projet2 de la région europe-west1 créés le 15 novembre 2025 ou après.

Script de qualification

Utilisez cette méthode si vous disposez du chemin d'accès Cloud Storage direct à un journal d'événements Spark spécifique que vous souhaitez analyser. Cette approche nécessite de télécharger et d'exécuter un script shell, run_qualification_tool.sh, sur une machine locale ou une VM Compute Engine configurée avec un accès au fichier journal d'événements dans Cloud Storage.

Procédez comme suit pour exécuter le script sur les fichiers d’événements de charge de travail par lot Serverless pour Apache Spark.

1.Copiez les run_qualification_tool.sh dans un répertoire local contenant les fichiers d'événements Spark à analyser.

1. Exécutez le script de qualification pour analyser un fichier d’événements ou un ensemble de fichiers d’événements contenus dans le répertoire du script.

   ./run_qualification_tool.sh -f EVENT_FILE_PATH/EVENT_FILE_NAME \
       -o CUSTOM_OUTPUT_DIRECTORY_PATH \
       -k SERVICE_ACCOUNT_KEY  \
       -x MEMORY_ALLOCATEDg  \
       -t PARALLEL_THREADS_TO_RUN
   

   Flags et valeurs :

   -f (obligatoire) : consultez Emplacements des fichiers d'événements Spark pour localiser les fichiers d'événements de charge de travail Spark.

   • EVENT_FILE_PATH (obligatoire, sauf si EVENT_FILE_NAME est spécifié) : chemin d'accès au fichier d'événements à analyser. Si aucune valeur n'est fournie, le chemin d'accès au fichier d'événements est supposé être le répertoire actuel.

   • EVENT_FILE_NAME (obligatoire, sauf si EVENT_FILE_PATH est spécifié) : nom du fichier d'événements à analyser. Si aucune valeur n'est fournie, les fichiers d'événements trouvés de manière récursive dans le EVENT_FILE_PATH sont analysés.

   -o(facultatif) : si aucune valeur n'est fournie, l'outil crée ou utilise un répertoire output existant dans le répertoire actuel pour placer les fichiers de sortie.

   • CUSTOM_OUTPUT_DIRECTORY_PATH : chemin d'accès au répertoire de sortie des fichiers de sortie.

   -k (facultatif) :

   • SERVICE_ACCOUNT_KEY : clé du compte de service au format JSON si nécessaire pour accéder à EVENT_FILE_PATH.

   -x (facultatif) :

   • MEMORY_ALLOCATED : mémoire en gigaoctets à allouer à l'outil. Par défaut, l'outil utilise 80 % de la mémoire libre disponible dans le système et tous les cœurs de la machine disponibles.

   -t(facultatif) :

   • PARALLEL_THREADS_TO_RUN : nombre de threads parallèles à exécuter par l' outil. Par défaut, l'outil exécute tous les cœurs.

   Exemple d'utilisation de la commande :

   ./run_qualification_tool.sh -f gs://dataproc-temp-us-east1-9779/spark-job-history \
       -o perfboost-output -k /keys/event-file-key -x 34g -t 5
   

   Dans cet exemple, l'outil de qualification parcourt le répertoire gs://dataproc-temp-us-east1-9779/spark-job-history et analyse les fichiers d'événements Spark contenus dans ce répertoire et ses sous-répertoires. L'accès au répertoire est fourni par /keys/event-file-key. L'outil utilise 34 GB memory pour l'exécution et exécute 5 threads parallèles.

Emplacements des fichiers d'événements Spark

Effectuez l'une des étapes suivantes pour trouver les fichiers d'événements Spark pour les charges de travail par lot Serverless pour Apache Spark :

1. Dans Cloud Storage, recherchez le spark.eventLog.dir de la charge de travail, puis téléchargez-le.

   1. Si vous ne trouvez pas le spark.eventLog.dir, définissez le spark.eventLog.dir sur un emplacement Cloud Storage, puis réexécutez la charge de travail et téléchargez le spark.eventLog.dir.

2. Si vous avez configuré le serveur d'historique Spark pour le job par lot :

   1. Accédez au serveur d'historique Spark, puis sélectionnez la charge de travail.
   2. Cliquez sur Télécharger dans la colonne Journal d'événements.

Conseil : Analyse des jobs Spark Dataproc sur Compute Engine : pour exécuter l'outil de qualification sur les jobs Spark Dataproc sur Compute Engine :

• Recherchez le spark.eventLog.dir des jobs Spark Dataproc sur Compute Engine dans Cloud Storage, puis téléchargez-le.
• Exécutez l'outil sur les journaux d'événements. Si l'outil recommande d'utiliser l'exécution de requêtes natives, migrez les jobs vers des charges de travail par lot Serverless pour Apache Spark puis exécutez les charges de travail avec l'exécution de requêtes natives.

Fichiers de sortie de l'outil de qualification

Une fois l'analyse du job ou du script de qualification terminée, l'outil de qualification place les fichiers de sortie suivants dans un perfboost-output répertoire du répertoire actuel :

• AppsRecommendedForBoost.tsv : liste des applications recommandées pour une utilisation avec l'exécution de requêtes natives, séparées par des tabulations.

• UnsupportedOperators.tsv : liste des applications non recommandées pour une utilisation avec l'exécution de requêtes natives, séparées par des tabulations.

Le contenu des fichiers de sortie de l'outil de qualification est séparé par des tabulations. Vous pouvez afficher les fichiers avec un lecteur de fichiers CSV ou TSV, tel que Google Sheets.

Remarque : Lorsque l'outil de qualification tente d'enregistrer un fichier de sortie, si le fichier existe dans le répertoire de sortie, l'outil ajoute un suffixe incrémentiel au nom de fichier avant d'enregistrer le nouveau fichier.

Fichier de sortie AppsRecommendedForBoost.tsv

Le tableau suivant présente le contenu d'un exemple de fichier de sortie AppsRecommendedForBoost.tsv. Il contient une ligne pour chaque application analysée.

Exemple de fichier de sortie AppsRecommendedForBoost.tsv :

applicationId	applicationName	rddPercentage	unsupportedSqlPercentage	totalTaskTime	supportedTaskTime	supportedSqlPercentage	recommendedForBoost	expectedRuntimeReduction
app-2024081/batches/083f6196248043938-000	projects/example.com:dev/locations/us-central1 6b4d6cae140f883c0 11c8e	0 %	0 %	548924253	548924253	100 %	TRUE	30 %
app-2024081/batches/60381cab738021457-000	projects/example.com:dev/locations/us-central1 474113a1462b426bf b3aeb	0 %	0 %	514401703	514401703	100 %	TRUE	30 %

Descriptions des colonnes :

• applicationId : ApplicationID de l'application Spark. Utilisez-le pour identifier la charge de travail par lot correspondante.

• applicationName : nom de l'application Spark.

• rddPercentage : pourcentage d'opérations RDD dans l'application. Les opérations RDD ne sont pas compatibles avec l'exécution de requêtes natives.

• unsupportedSqlPercentage: pourcentage d'opérations SQL non compatibles avec l'exécution de requêtes natives.

• totalTaskTime : temps de tâche cumulé de toutes les tâches exécutées lors de l'exécution de l' application.

• supportedTaskTime : temps de tâche total compatible avec l'exécution de requêtes natives.

Les colonnes suivantes fournissent des informations importantes pour vous aider à déterminer si l'exécution de requêtes natives peut être bénéfique pour votre charge de travail par lot :

• supportedSqlPercentage: pourcentage d'opérations SQL compatibles avec l'exécution de requêtes natives. Plus le pourcentage est élevé, plus la réduction du temps d'exécution que peut être obtenue en exécutant l'application avec l'exécution de requêtes natives est importante.

• recommendedForBoost: si la valeur est TRUE, il est recommandé d'exécuter l'application avec l'exécution de requêtes natives. Si recommendedForBoost est FALSE, n'utilisez pas l'exécution de requêtes natives sur la charge de travail par lot.

• expectedRuntimeReduction: pourcentage de réduction attendu du temps d'exécution de l'application lorsque vous l'exécutez avec l'exécution de requêtes natives.

Fichier de sortie UnsupportedOperators.tsv

Le fichier de sortie UnsupportedOperators.tsv contient une liste des opérateurs utilisés dans les applications de charge de travail qui ne sont pas compatibles avec l'exécution de requêtes natives. Chaque ligne du fichier de sortie répertorie un opérateur non compatible.

Remarque : Si vous ouvrez un ticket d'assistance Google Cloud et incluez le fichier UnsupportedOperators.tsv, Dataproc peut évaluer la prise en charge d'opérateurs supplémentaires. Pour en savoir plus, consultez Obtenir de l'aide.

Descriptions des colonnes :

• unsupportedOperator : nom de l'opérateur non compatible avec l'exécution de requêtes natives.

• cumulativeCpuMs : nombre de millisecondes de processeur consommées lors de l' exécution de l'opérateur. Cette valeur reflète l'importance relative de l' opérateur dans l'application.

• count : nombre de fois où l'opérateur est utilisé dans l'application.