ネイティブ クエリ実行（NQE）で実行時間を短縮できるバッチ ワークロードを特定するには、認定ツールを使用します。このツールは、Spark イベントログを分析して、潜在的なランタイムの節約量を推定し、NQE エンジンでサポートされていないオペレーションを特定します。
Google Cloud には、認定分析を実行する 2 つの方法（認定ジョブと認定スクリプト）があります。ほとんどのユーザーにおすすめの方法は、バッチ ワークロードの検出と分析を自動化する認定ジョブです。代替の限定条件スクリプトは、既知のイベント ログファイルの分析という特定のユースケースで使用できます。ユースケースに最適な方法を選択します。
Qualification Job（推奨）: これは、推奨される主な方法です。これは、1 つ以上の Google Cloud プロジェクトとリージョンにわたって最近のバッチ ワークロードを自動的に検出して分析する PySpark ジョブです。このメソッドは、個々のイベント ログファイルを自分で探す必要なく、広範な分析を実行する場合に使用します。このアプローチは、NQE の適合性を大規模に評価する場合に最適です。
Qualification Script（代替）: 高度なユースケースや特定のユースケース向けの代替方法です。これは、単一の 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 用サーバーレス バッチジョブ。結果は 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 ジョブ。ジョブ引数は、Cloud Storage の BUCKET にアップロードされる INPUT_FILE に配置されます。この方法は、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 をダウンロードして実行する必要があります。
次の手順で、Serverless for Apache Spark バッチ ワークロード イベント ファイルに対してスクリプトを実行します。
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: ツールに割り当てるメモリ（GB）。デフォルトでは、このツールはシステムで使用可能な空きメモリの 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 に移動し、ワークロードを選択します。
- [イベントログ] 列の [ダウンロード] をクリックします。
Qualification ツールの出力ファイル
認定ジョブまたはスクリプト分析が完了すると、認定ツールは次の出力ファイルを現在のディレクトリの 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: アプリケーションでオペレータが使用される回数。