ネイティブ クエリ実行（NQE）で実行時間を短縮できるバッチ ワークロードを特定するには、適格性評価ツールを使用します。 このツールは、Spark イベントログを分析して、潜在的な実行時間の短縮を見積もり、 NQE エンジンでサポートされていないオペレーションを特定します。
Google Cloud では、適格性評価ジョブと適格性評価スクリプトの 2 つの方法で適格性評価分析を実行できます。ほとんどの ユーザーにおすすめの方法は適格性評価ジョブです。このジョブでは、バッチ ワークロードの検出と分析が自動化されます。代替の適格性評価スクリプトは、既知のイベントログ ファイルを分析する特定の ユースケースで使用できます。ユースケースに最適な方法を選択してください。
適格性評価ジョブ（推奨）: これは、推奨される主要な方法です。 これは、1 つ以上の Google Cloud プロジェクトとリージョンにわたって最近のバッチ ワークロードを自動的に検出して分析する PySpark ジョブです。個々のイベントログ ファイルを手動で 特定する必要なく、広範な分析を行う場合にこの 方法を使用します。この方法は、NQE の適合性を大規模に 評価する場合に最適です。
適格性評価スクリプト（代替）: これは、 高度なユースケースや特定のユースケース向けの代替方法です。これは、単一の Spark イベントログ ファイルまたは特定の Cloud Storage ディレクトリ内のすべてのイベントログを分析するシェル スクリプトです。分析するイベント ログの Cloud Storage パスがある場合は、この方法を使用します。
適格性評価ジョブ
適格性評価ジョブでは、Apache Spark 向け Serverless バッチ ワークロードをプログラムで スキャンし、分散 分析ジョブを送信することで、大規模な分析を簡素化します。このツールは組織全体のジョブを評価するため、 イベントログ パスを手動で検索して指定する必要はありません。
IAM ロールを付与する
適格性評価ジョブがバッチ ワークロード メタデータ にアクセスし、Cloud Logging で Spark イベントログを読み取るには、ワークロードを実行するサービス アカウントに、分析対象のすべてのプロジェクトで次の IAM ロールが付与されている必要があります。
適格性評価ジョブを送信する
適格性評価ジョブは、gcloud CLI ツールを使用して送信します。 このジョブには、一般公開されている Cloud Storage バケットでホストされている PySpark スクリプトと JAR ファイルが含まれています。
ジョブは、次のいずれかの実行環境で実行できます。
Apache Spark 向け Serverless バッチ ワークロードとして。これは、シンプルなスタンドアロン ジョブの実行です。
Dataproc on Compute Engine クラスタで実行されるジョブとして。この方法は、ジョブをワークフローに統合する場合に便利です。
ジョブの引数
| 引数 | 説明 | 必須かどうか | デフォルト値 |
|---|---|---|---|
--project-ids |
バッチ ワークロードをスキャンする単一のプロジェクト ID または Google Cloud プロジェクト ID のカンマ区切りリスト。 | いいえ | 適格性評価ジョブが実行されているプロジェクト。 |
--regions |
指定したプロジェクト内でスキャンする単一のリージョンまたはリージョンのカンマ区切りリスト。 | いいえ | 指定したプロジェクト内のすべてのリージョン。 |
--start-time |
バッチをフィルタする開始日。この日以降に作成されたバッチのみが分析されます（形式: YYYY-MM-DD）。 | いいえ | 開始日のフィルタは適用されません。 |
--end-time |
バッチをフィルタする終了日。この日以前に作成されたバッチのみが分析されます（形式: YYYY-MM-DD）。 | いいえ | 終了日のフィルタは適用されません。 |
--limit |
リージョンごとに分析するバッチの最大数。最新のバッチが最初に分析されます。 | いいえ | 他のフィルタ条件に一致するすべてのバッチが分析されます。 |
--output-gcs-path |
結果ファイルが書き込まれる Cloud Storage パス（gs://your-bucket/output/ など）。 |
はい | なし。 |
--input-file |
一括分析用のテキスト ファイルの Cloud Storage パス。指定した場合、この引数は他のすべてのスコープ定義引数（--project-ids、--regions、--start-time、--end-time、--limit）をオーバーライドします。 |
いいえ | なし。 |
適格性評価ジョブの例
シンプルなアドホック分析を実行する Apache Spark 向け Serverless バッチジョブ。ジョブ の引数は、
--区切り文字の後に一覧表示されます。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
us-central1リージョンのsample_projectで見つかった最新のバッチを最大 50 個分析する Apache Spark 向け Serverless バッチジョブ 。結果 は Cloud Storage のバケットに書き込まれます。ジョブ の引数は、--区切り文字の後に一覧表示されます。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/
大規模で反復可能な自動化された分析ワークフローで一括分析を行うために、Dataproc クラスタに送信された Dataproc on Compute Engine ジョブ 。 ジョブの引数は、INPUT_FILE にアップロードされる BUCKET に Cloud Storage に配置されます。この方法は、1 回の実行でさまざまなプロジェクトとリージョンにわたって異なる日付範囲または バッチ上限をスキャンする場合に最適です。
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
注:
INPUT_FILE: ファイル内の各行は個別の分析 リクエストを表し、1 文字のフラグとその値（
-p PROJECT-ID -r REGION -s START_DATE -e END_DATE -l LIMITSなど）の形式を使用します。入力ファイルの内容の例:
-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
これらの引数は、次の 2 つのスコープを分析するようにツールに指示します。
- 2025 年 12 月 1 日から 2025 年 12 月 15 日の間に作成された
us-central1リージョンの project1 のバッチを最大 100 個。 - 2025 年 11 月 15 日以降に作成された
europe-west1リージョンの project2 のバッチを最大 50 個。
- 2025 年 12 月 1 日から 2025 年 12 月 15 日の間に作成された
適格性評価スクリプト
分析する特定の
Spark イベントログへの直接 Cloud Storage パスがある場合は、この方法を使用します。この方法では、Cloud Storage のイベントログ ファイルへのアクセス権が構成されたローカルマシンまたは
Compute Engine VM にシェル スクリプト run_qualification_tool.sh をダウンロードして実行する必要があります。
Apache Spark 向け Serverless バッチ ワークロード イベント ファイルに対してスクリプトを実行するには、次の手順を行います。
1.分析する Spark イベント ファイルを含むローカル ディレクトリに
run_qualification_tool.sh
をコピーします。
適格性評価スクリプトを実行して、1 つのイベント ファイルまたはスクリプト ディレクトリに含まれる一連のイベント ファイル を分析します。
./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
フラグと値:
-f（必須）: Spark ワークロード イベント ファイルを見つけるには、Spark イベント ファイルの場所 をご覧ください。EVENT_FILE_PATH（EVENT_FILE_NAME が指定されていない限り必須）: 分析するイベント ファイルのパス。指定しない場合、イベント ファイルのパスは 現在のディレクトリとみなされます。
EVENT_FILE_NAME（EVENT_FILE_PATH が指定されていない限り必須）: 分析するイベント ファイルの名前。指定しない場合、
EVENT_FILE_PATHで 再帰的に検出されたイベント ファイルが分析されます。
-o（省略可）: 指定しない場合、ツールは現在のディレクトリの下にoutputディレクトリを作成するか、既存のディレクトリを使用して出力ファイルを配置します。- CUSTOM_OUTPUT_DIRECTORY_PATH: 出力ファイルを配置する出力ディレクトリのパス。
-k（省略可）:- SERVICE_ACCOUNT_KEY: EVENT_FILE_PATH にアクセスするために必要な場合は、JSON 形式の サービス アカウント キー。
-x（省略可）:- MEMORY_ALLOCATED: ツールに割り当てるメモリ（ギガバイト単位）。 デフォルトでは、システムで使用可能な空きメモリの 80% と 使用可能なすべてのマシンコアが使用されます。
-t（省略可）:- PARALLEL_THREADS_TO_RUN: ツールが実行する並列スレッドの数。デフォルトでは、すべてのコアが実行されます。
コマンドの使用例:
./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
この例では、適格性評価ツールは
gs://dataproc-temp-us-east1-9779/spark-job-historyディレクトリを走査し、このディレクトリとそのサブディレクトリに含まれる Spark イベント ファイルを分析します。ディレクトリへのアクセス権は/keys/event-file-keyに付与されます。このツールは実行に34 GB memoryを使用し、5個の並列スレッドを実行します。
Spark イベント ファイルの場所
Apache Spark 向け Serverless バッチ ワークロードの Spark イベント ファイルを見つけるには、次のいずれかの操作を行います。
Cloud Storage で、ワークロードの
spark.eventLog.dirを見つけて ダウンロードします。spark.eventLog.dirが見つからない場合は、spark.eventLog.dirを Cloud Storage の場所に設定し、 ワークロードを再実行してspark.eventLog.dirをダウンロードします。
バッチジョブに Spark History Server を構成している場合:
- Spark History Server に移動し、ワークロードを選択します。
- [イベントログ] 列の [ダウンロード] をクリックします。
適格性評価ツールの出力ファイル
適格性評価ジョブまたはスクリプトの分析が完了すると、適格性評価ツール
は現在のディレクトリの
perfboost-output ディレクトリに次の出力ファイルを配置します。
AppsRecommendedForBoost.tsv:ネイティブ クエリ実行での使用が推奨されるアプリケーションのタブ区切りリスト。UnsupportedOperators.tsv:ネイティブ クエリ実行での使用が推奨されないアプリケーションのタブ区切りリスト。
AppsRecommendedForBoost.tsv 出力ファイル
次の表に、AppsRecommendedForBoost.tsv
出力ファイルのサンプルを示します。分析されたアプリケーションごとに 1 行が含まれています。
出力ファイルのサンプル: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.00% | 0.00% | 548924253 | 548924253 | 100.00% | TRUE | 30.00% |
| app-2024081/batches/60381cab738021457-000 | projects/example.com:dev/locations/us-central1 474113a1462b426bf b3aeb |
0.00% | 0.00% | 514401703 | 514401703 | 100.00% | TRUE | 30.00% |
列の説明:
applicationId: Spark アプリケーションのApplicationID。これを使用して、対応するバッチ ワークロードを特定します。applicationName: Spark アプリケーションの名前。rddPercentage：アプリケーション内の RDD オペレーションの割合。 RDD オペレーションはネイティブ クエリ実行ではサポートされていません。unsupportedSqlPercentage:ネイティブ クエリ実行でサポートされていない SQL オペレーションの割合。totalTaskTime: アプリケーションの実行中に実行されたすべてのタスクの累積タスク時間。supportedTaskTime: ネイティブ クエリ実行でサポートされる合計タスク時間。
次の列は、ネイティブ クエリ実行がバッチ ワークロードにメリットをもたらすかどうかを判断するのに役立つ重要な情報を提供します:
supportedSqlPercentage: ネイティブ クエリ実行でサポートされる SQL オペレーションの割合。割合が高いほど、ネイティブ クエリ実行でアプリケーションを実行することで実現できる実行時間の短縮が 大きくなります。recommendedForBoost:TRUEの場合、ネイティブ クエリ実行でアプリケーションを実行することをおすすめします。recommendedForBoostがFALSEの場合、バッチ ワークロードでネイティブ クエリ実行を使用しないでください。expectedRuntimeReduction: ネイティブ クエリ実行でアプリケーションを実行した場合のアプリケーション 実行時間の短縮率。
UnsupportedOperators.tsv 出力ファイル。
UnsupportedOperators.tsv 出力ファイルには、ネイティブ クエリ実行でサポートされていない
ワークロード アプリケーションで使用されるオペレータのリストが含まれています。
出力ファイルの各行には、サポートされていないオペレータが一覧表示されます。
列の説明:
unsupportedOperator: ネイティブ クエリ実行でサポートされていないオペレータの名前。cumulativeCpuMs: オペレータの 実行中に消費された CPU ミリ秒数。この値は、アプリケーション内の オペレータの相対的な重要度を反映しています。count：アプリケーションでオペレータが使用される回数。