Cette page a été traduite par l'API Cloud Translation.

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

Pour identifier les charges de travail par lot qui peuvent atteindre des durées d'exécution plus rapides avec l'exécution de requêtes natives (NQE), vous pouvez utiliser l'outil de qualification. L'outil analyse les journaux d'événements Spark pour estimer les économies de temps d'exécution potentielles et identifier les opérations qui ne sont pas 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 :

Qualification Job (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 projets et régions Google Cloud . Utilisez cette méthode lorsque vous souhaitez effectuer une analyse globale sans avoir à localiser manuellement les fichiers journaux d'événements individuels. Cette approche est idéale pour évaluer à grande échelle l'adéquation de l'évaluation de la qualité des requêtes naturelles.
Script de qualification (autre méthode) : il s'agit d'une autre méthode 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.

Tâche de qualification

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

Attribuer des rôles IAM

Pour que le job de qualification puisse accéder aux métadonnées de 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 :

Envoyer le job de qualification

Vous envoyez la tâche 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 simple et autonome du job.
En tant que job exécuté 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`	ID d'un seul projet ou liste d'ID de projets Google Cloud séparés par une virgule à analyser pour les charges de travail par lot.	Non	Projet dans lequel la tâche de qualification est exécutée.
`--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 pour filtrer les lots. Seuls les lots créés à partir de cette date (format : AAAA-MM-JJ) seront analysés.	Non	Aucun filtre de date de début n'est appliqué.
`--end-time`	Date de fin pour filtrer les 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	Aucun
`--input-file`	Chemin d'accès Cloud Storage vers un fichier texte pour l'analyse groupée. Si cet argument est fourni, il remplace tous les autres arguments définissant le champ d'application (`--project-ids`, `--regions`, `--start-time`, `--end-time`, `--limit`).	Non	Aucun

Exemples de tâches de qualification

Un job par lot Serverless pour Apache Spark permettant d'effectuer une analyse simple et ponctuelle. 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

Un job par lot Serverless pour Apache Spark permettant d'analyser jusqu'à 50 des derniers lots trouvés dans sample_project dans la région us-central1. Les résultats sont écrits dans un bucket 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 de la tâche sont placés dans un fichier INPUT_FILE qui est 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 demande d'analyse distincte et utilise un format de drapeaux d'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 du 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 portées suivantes :
- Jusqu'à 100 lots dans le projet 1 de la région us-central1 créés entre le 1er et le 15 décembre 2025.
- Jusqu'à 50 lots dans le projet 2 dans la région europe-west1 créés à partir du 15 novembre 2025.

Script de qualification

Utilisez cette méthode si vous disposez du chemin d'accès Cloud Storage direct vers 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 des é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 run_qualification_tool.sh dans un répertoire local contenant les fichiers d'événements Spark à analyser.

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
```
Options 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 aucun chemin n'est fourni, 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 aucun n'est fourni, les fichiers d'événements trouvés de manière récursive dans 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 sous 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é de 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 machine disponibles.
-t(facultatif) :
- PARALLEL_THREADS_TO_RUN : nombre de threads parallèles pour l'exécution de 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

Pour trouver les fichiers d'événements Spark pour les charges de travail par lot Serverless pour Apache Spark, procédez comme suit :

Dans Cloud Storage, recherchez le fichier 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.
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 des événements.

Fichiers de sortie de l'outil de qualification

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

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

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,00 %
app-2024081/batches/60381cab738021457-000	projects/example.com:dev/locations/us-central1 474113a1462b426bf b3aeb	0 %	0 %	514401703	514401703	100 %	TRUE	30,00 %

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 : durée totale de la tâche prise en charge par 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 pouvant ê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 défini sur 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 liste un opérateur non compatible.