YARN 上での Spark の実行

• セキュリティ
• YARN 上での Spark の起動
  • その他の JAR の追加
• 準備
• 設定
• アプリケーションのデバッグ
  • Spark プロパティ
  • SHS カスタムエグゼキュータログ URL の利用可能なパターン
• リソース割り当てと設定の概要
• ステージレベルのスケジューリング概要
• 重要な注意事項
• Kerberos
  • YARN 固有の Kerberos 設定
  • Kerberos のトラブルシューティング
• 外部シャフルサービスの構成
• Apache Oozie を使用したアプリケーションの起動
• Spark Web UI の代わりとなる Spark History Server の使用
• Spark シャフルサービスの複数バージョンの実行
• Spark アプリケーション用の異なる JDK の構成

Spark 0.6.0 で YARN (Hadoop NextGen) 上での実行サポートが追加され、その後のリリースで改善されました。 YARN (Hadoop NextGen) 上での実行サポートが Spark 0.6.0 で追加され、その後のリリースで改善されました。

セキュリティ

認証のようなセキュリティ機能はデフォルトでは有効になっていません。インターネットまたは信頼されていないネットワークに公開されているクラスターをデプロイする場合、不正なアプリケーションがクラスター上で実行されるのを防ぐために、クラスターへのアクセスを保護することが重要です。Spark を実行する前に、Spark セキュリティ およびこのドキュメントの特定のセキュリティセクションを参照してください。

YARN 上での Spark の起動

Apache Hadoop 3.4.1 時点では Java 17 をサポートしておらず、Apache Spark 4.0.0 以降では最低 Java 17 が必要となるため、Spark アプリケーションには異なる JDK を構成する必要があります。詳細は Spark アプリケーション用の異なる JDK の構成 を参照してください。

HADOOP_CONF_DIR または YARN_CONF_DIR が、Hadoop クラスターの (クライアント側の) 設定ファイルが含まれるディレクトリを指していることを確認してください。これらの設定は HDFS への書き込みや YARN ResourceManager への接続に使用されます。このディレクトリに含まれる設定は YARN クラスターに配布され、アプリケーションが使用するすべてのコンテナが同じ設定を使用するようにします。設定が YARN によって管理されていない Java システムプロパティまたは環境変数を参照する場合、それらは Spark アプリケーションの設定 (ドライバー、エグゼキュータ、およびクライアントモードで実行する場合の AM) にも設定する必要があります。

YARN 上で Spark アプリケーションを起動するには、2 つのデプロイモードがあります。cluster モードでは、Spark ドライバーは YARN によってクラスター上で管理されるアプリケーションマスタープロセス内で実行され、クライアントはアプリケーションの起動後に離れることができます。client モードでは、ドライバーはクライアントプロセス内で実行され、アプリケーションマスターは YARN からリソースを要求するためのみに使用されます。

Spark がサポートする他のクラスターマネージャーとは異なり、マスターのアドレスを --master パラメーターで指定するのに対し、YARN モードでは ResourceManager のアドレスは Hadoop 設定から取得されます。したがって、--master パラメーターは yarn です。

cluster モードで Spark アプリケーションを起動するには

$ ./bin/spark-submit --class path.to.your.Class --master yarn --deploy-mode cluster [options] <app jar> [app options]

例

$ ./bin/spark-submit --class org.apache.spark.examples.SparkPi \
    --master yarn \
    --deploy-mode cluster \
    --driver-memory 4g \
    --executor-memory 2g \
    --executor-cores 1 \
    --queue thequeue \
    examples/jars/spark-examples*.jar \
    10

上記は、デフォルトの Application Master を起動する YARN クライアントプログラムを開始します。次に SparkPi が Application Master の子スレッドとして実行されます。クライアントはステータス更新のために Application Master を定期的にポーリングし、コンソールに表示します。アプリケーションが実行を終了すると、クライアントは終了します。ドライバーおよびエグゼキュータのログを確認する方法については、下の アプリケーションのデバッグ セクションを参照してください。

client モードで Spark アプリケーションを起動するには、同様に行いますが、cluster を client に置き換えます。以下は、spark-shell を client モードで実行する方法を示しています。

$ ./bin/spark-shell --master yarn --deploy-mode client

その他の JAR の追加

cluster モードでは、ドライバーはクライアントとは異なるマシンで実行されるため、クライアントにローカルなファイルに対して SparkContext.addJar はそのままでは機能しません。クライアント上のファイルを SparkContext.addJar で利用可能にするには、起動コマンドの --jars オプションに含めてください。

$ ./bin/spark-submit --class my.main.Class \
    --master yarn \
    --deploy-mode cluster \
    --jars my-other-jar.jar,my-other-other-jar.jar \
    my-main-jar.jar \
    app_arg1 app_arg2

準備

YARN 上での Spark の実行には、YARN サポートでビルドされた Spark のバイナリディストリビューションが必要です。バイナリディストリビューションは、プロジェクトウェブサイトの ダウンロードページ からダウンロードできます。ダウンロードできる Spark バイナリディストリビューションには 2 つのバリアントがあります。1 つは特定のバージョンの Apache Hadoop で事前にビルドされたものです。この Spark ディストリビューションには Hadoop ランタイムが組み込まれているため、with-hadoop Spark ディストリビューションと呼びます。もう 1 つはユーザー提供の Hadoop で事前にビルドされたものです。この Spark ディストリビューションには Hadoop ランタイムが組み込まれていないため、サイズは小さいですが、ユーザーは別途 Hadoop インストールを提供する必要があります。このバリアントを no-hadoop Spark ディストリビューションと呼びます。with-hadoop Spark ディストリビューションの場合、Hadoop ランタイムが既に組み込まれているため、デフォルトでは、ジョブが Hadoop Yarn クラスターにサブミットされる際に、JAR の競合を防ぐために、Yarn のクラスパスは Spark には設定されません。この動作を上書きするには、spark.yarn.populateHadoopClasspath=true を設定できます。no-hadoop Spark ディストリビューションの場合、Hadoop ランタイムを取得するために Spark はデフォルトで Yarn のクラスパスを設定します。with-hadoop Spark ディストリビューションの場合、アプリケーションがクラスターにのみ存在する特定のライブラリに依存している場合は、上記の設定を試して Yarn クラスパスを設定できます。これにより JAR 競合の問題が発生した場合は、それを無効にして、このライブラリをアプリケーション JAR に含める必要があります。

Spark を自分でビルドするには、Spark のビルド を参照してください。

YARN 側から Spark ランタイム JAR にアクセスできるようにするには、spark.yarn.archive または spark.yarn.jars を指定できます。詳細については、Spark プロパティ を参照してください。spark.yarn.archive も spark.yarn.jars も指定しない場合、Spark は $SPARK_HOME/jars のすべての JAR を含む zip ファイルを作成し、分散キャッシュにアップロードします。

設定

ほとんどの設定は、Spark on YARN の場合、他のデプロイモードと同じです。詳細については、設定ページ を参照してください。これらは Spark on YARN 固有の設定です。

アプリケーションのデバッグ

YARN 用語では、エグゼキュータとアプリケーションマスターは「コンテナ」内で実行されます。YARN には、アプリケーション完了後にコンテナログを処理するための 2 つのモードがあります。ログ集約が有効になっている場合 (yarn.log-aggregation-enable 設定)、コンテナログは HDFS にコピーされ、ローカルマシンから削除されます。これらのログは、yarn logs コマンドを使用してクラスター上のどこからでも表示できます。

yarn logs -applicationId <app ID>

指定されたアプリケーションのすべてのコンテナからのすべてのログファイルの内容を出力します。HDFS シェルまたは API を使用して、HDFS 上のコンテナログファイルを直接表示することもできます。それらが配置されているディレクトリは、YARN 設定 (yarn.nodemanager.remote-app-log-dir および yarn.nodemanager.remote-app-log-dir-suffix) を確認することで見つけることができます。ログは Spark Web UI の Executor タブでも利用できます。Spark History Server と MapReduce History Server の両方が実行されており、yarn-site.xml で yarn.log.server.url が正しく設定されている必要があります。Spark History Server UI のログ URL は、集約されたログを表示するために MapReduce History Server にリダイレクトされます。

ログ集約が有効になっていない場合、ログは各マシンの YARN_APP_LOGS_DIR の下にローカルに保持されます。これは通常、Hadoop のバージョンとインストール方法に応じて、/tmp/logs または $HADOOP_HOME/logs/userlogs に設定されます。コンテナのログを表示するには、それらが含まれるホストに移動し、このディレクトリを確認する必要があります。サブディレクトリは、アプリケーション ID とコンテナ ID によってログファイルを整理します。ログは Spark Web UI の Executor タブでも利用でき、MapReduce History Server を実行する必要はありません。

コンテナごとの起動環境を確認するには、yarn.nodemanager.delete.debug-delay-sec を大きな値 (例: 36000) に増やし、コンテナが起動されるノードの yarn.nodemanager.local-dirs を介してアプリケーションキャッシュにアクセスします。このディレクトリには、起動スクリプト、JAR、および各コンテナの起動に使用されるすべての環境変数が含まれています。このプロセスは、特にクラスパスの問題をデバッグするのに役立ちます。(これを有効にするにはクラスター設定で管理者権限が必要であり、すべてのノードマネージャーの再起動が必要であることに注意してください。したがって、ホストされているクラスターには適用できません)。

アプリケーションマスターまたはエグゼキュータ用のカスタム log4j2 設定を使用するには、以下のオプションがあります。

• spark-submit でカスタム log4j2.properties をアップロードします。これは、アプリケーションと一緒にアップロードされるファイルの --files リストに追加することで行います。
• -Dlog4j.configurationFile=<設定ファイルの場所> を spark.driver.extraJavaOptions (ドライバーの場合) または spark.executor.extraJavaOptions (エグゼキュータの場合) に追加します。ファイルを使用する場合、file: プロトコルを明示的に指定する必要があり、ファイルはすべてのノードでローカルに存在する必要があることに注意してください。
• $SPARK_CONF_DIR/log4j2.properties ファイルを更新すると、他の設定と一緒に自動的にアップロードされます。複数のオプションが指定された場合、他の 2 つのオプションがこのオプションよりも優先されることに注意してください。

最初のオプションの場合、エグゼキュータとアプリケーションマスターは同じ log4j 設定を共有し、同じノードで実行される場合 (例: 同じログファイルに書き込もうとする場合) に問題が発生する可能性があることに注意してください。

YARN 上のログファイルに適切な場所への参照が必要で、YARN がそれらを正しく表示および集約できるようにするには、log4j2.properties で spark.yarn.app.container.log.dir を使用します。たとえば、appender.file_appender.fileName=${sys:spark.yarn.app.container.log.dir}/spark.log のようになります。ストリーミングアプリケーションの場合、RollingFileAppender を構成し、ファイル場所を YARN のログディレクトリに設定すると、大きなログファイルによるディスクオーバーフローを回避でき、YARN のログユーティリティを使用してログにアクセスできます。

アプリケーションマスターおよびエグゼキュータ用のカスタム metrics.properties を使用するには、$SPARK_CONF_DIR/metrics.properties ファイルを更新します。他の設定と一緒に自動的にアップロードされるため、--files で手動で指定する必要はありません。

Spark プロパティ

SHS カスタムエグゼキュータログ URL の利用可能なパターン

たとえば、ジョブ履歴サーバーに直接ログ URL リンクをポイントさせたい場合、ノードマネージャーの HTTP サーバーがリダイレクトするのではなく、以下のように spark.history.custom.executor.log.url を設定できます。

{{HTTP_SCHEME}}<JHS_HOST>:<JHS_PORT>/jobhistory/logs/{{NM_HOST}}:{{NM_PORT}}/{{CONTAINER_ID}}/{{CONTAINER_ID}}/{{USER}}/{{FILE_NAME}}?start=-4096

注: <JHS_HOST> および <JHS_PORT> は実際の値に置き換える必要があります。

リソース割り当てと設定の概要

カスタムリソーススケジューリングと構成の概要セクションを 設定ページ で必ずお読みください。このセクションでは、リソーススケジューリングの YARN 固有の側面のみについて説明します。

YARN は、ユーザーが Spark で使用したいリソースをサポートするように構成する必要があります。YARN でのリソーススケジューリングは YARN 3.1.0 で追加されました。リソースの構成と適切な分離設定の詳細については、YARN のドキュメントを参照してください。理想的には、リソースは分離されているため、エグゼキュータは割り当てられたリソースのみを確認できます。分離が有効になっていない場合、ユーザーはリソースがエグゼキュータ間で共有されないことを保証する検出スクリプトを作成する責任があります。

YARN はユーザー定義のリソースタイプをサポートしていますが、GPU (yarn.io/gpu) および FPGA (yarn.io/fpga) の組み込みタイプがあります。そのため、これらのリソースのいずれかを使用している場合、Spark は Spark リソースの要求を YARN リソースに変換でき、spark.{driver/executor}.resource. 設定を指定するだけで済みます。GPU または FPGA 用にカスタムリソースタイプを使用している場合、Spark マッピングは spark.yarn.resourceGpuDeviceName および spark.yarn.resourceFpgaDeviceName を使用して変更できることに注意してください。FPGA または GPU 以外のリソースを使用している場合、ユーザーは YARN (spark.yarn.{driver/executor}.resource.) および Spark (spark.{driver/executor}.resource.) の両方の設定を指定する責任があります。

たとえば、ユーザーが各エグゼキュータに 2 つの GPU を要求したいとします。ユーザーは spark.executor.resource.gpu.amount=2 を指定するだけで、Spark は YARN から yarn.io/gpu リソースタイプを要求することを処理します。

ユーザー定義の YARN リソース（ここでは acceleratorX と呼びます）がある場合、ユーザーは spark.yarn.executor.resource.acceleratorX.amount=2 と spark.executor.resource.acceleratorX.amount=2 を指定する必要があります。

YARN は Spark に各コンテナに割り当てられたリソースのアドレスを通知しません。そのため、ユーザーはエグゼキュータが起動時に実行され、そのエグゼキュータが利用可能なリソースを検出するための検出スクリプトを指定する必要があります。スクリプトの例は examples/src/main/scripts/getGpusResources.sh で見つけることができます。スクリプトには実行権限を設定する必要があり、ユーザーは悪意のあるユーザーがそれを変更できないように権限を設定する必要があります。スクリプトは、ResourceInformation クラスの形式で JSON 文字列を標準出力に書き出す必要があります。これには、リソース名と、そのエグゼキュータのみが利用可能なリソースアドレスの配列が含まれます。

ステージレベルのスケジューリング概要

ステージレベルのスケジューリングは YARN でサポートされています。

• 動的割り当てが無効な場合: ユーザーはステージレベルで異なるタスクリソース要件を指定でき、起動時に要求されたのと同じ Executor を使用します。
• 動的割り当てが有効な場合: ユーザーはステージレベルでタスクおよびエグゼキュータのリソース要件を指定でき、追加のエグゼキュータを要求します。

YARN 固有のこととして、各 ResourceProfile は YARN で異なるコンテナ優先度を必要とします。マッピングは単純に ResourceProfile ID が優先度になり、YARN では数値が小さいほど優先度が高くなります。これは、先に作成されたプロファイルが YARN でより高い優先度を持つことを意味します。通常、Spark は 1 つのステージを完了してから次のステージを開始するため、これは問題になりませんが、ジョブサーバータイプのシナリオでは影響がある可能性があり、注意が必要です。カスタムリソースの処理方法において、ベースのデフォルトプロファイルとカスタム ResourceProfiles の間に違いがあることに注意してください。ユーザーが Spark スケジューリングしない追加リソースを持つ YARN コンテナを要求できるようにするには、ユーザーは spark.yarn.executor.resource. 設定でリソースを指定できます。これらの設定はベースのデフォルトプロファイルでのみ使用され、他のカスタム ResourceProfiles には伝播されません。これは、ステージにそれらを持たたくない場合、それらを削除する方法がないためです。その結果、デフォルトプロファイルには、spark.yarn.executor.resource. で定義されたカスタムリソースと、GPU または FPGA の Spark 定義リソースが含まれます。Spark は GPU および FPGA リソースを YARN の組み込みタイプ (yarn.io/gpu) および yarn.io/fpga に変換しますが、他のリソースのマッピングは認識しません。他の Spark カスタムリソースは、デフォルトプロファイルには YARN に伝播されません。したがって、Spark がカスタムリソースに基づいてスケジューリングし、それを YARN に要求したい場合は、YARN (spark.yarn.{driver/executor}.resource.) と Spark (spark.{driver/executor}.resource.) の両方の設定で指定する必要があります。Spark がそれらを使用せずに YARN コンテナのみを要求したい場合は、Spark 設定を省略してください。カスタム ResourceProfiles の場合、Spark がスケジューリングしないリソースを YARN で要求しながら、カスタムリソースのみを指定する方法は現在ありません。これは、カスタム ResourceProfiles では、ResourceProfile で定義されたすべてのリソースが YARN に伝播されることを意味します。GPU および FPGA も YARN の組み込みタイプに変換されます。これは、指定するカスタムリソースの名前が YARN で定義されているものと一致する必要があることを意味します。

重要な注意事項

• コア要求がスケジューリング決定で尊重されるかどうかは、使用されているスケジューラとその構成方法によって異なります。
• cluster モードでは、Spark エグゼキュータおよび Spark ドライバーが使用するローカルディレクトリは、YARN (Hadoop YARN 設定 yarn.nodemanager.local-dirs) 用に構成されたローカルディレクトリになります。ユーザーが spark.local.dir を指定しても、無視されます。client モードでは、Spark エグゼキュータは YARN 用に構成されたローカルディレクトリを使用しますが、Spark ドライバーは spark.local.dir で定義されたものを使用します。これは、Spark ドライバーが client モードでは YARN クラスター上で実行されず、Spark エグゼキュータのみが実行されるためです。
• --files および --archives オプションは、Hadoop と同様に # を使用してファイル名を指定できます。たとえば、--files localtest.txt#appSees.txt を指定すると、ローカルで localtest.txt という名前のファイルが HDFS にアップロードされますが、これは appSees.txt という名前でリンクされ、アプリケーションは YARN 上で実行する際に appSees.txt という名前で参照する必要があります。
• --jars オプションは、cluster モードでローカルファイルを使用して SparkContext.addJar 関数を動作させることができます。HDFS、HTTP、HTTPS、または FTP ファイルを使用する場合は、使用する必要はありません。

Kerberos

Spark の標準 Kerberos サポートについては、セキュリティ ページで説明されています。

YARN モードでは、Hadoop ファイルシステムにアクセスする際に、Hadoop 設定のデフォルトファイルシステムに加えて、Spark は Spark アプリケーションのステージングディレクトリをホストするサービス用のデリゲーショントークンも自動的に取得します。

YARN 固有の Kerberos 設定

Kerberos のトラブルシューティング

Hadoop/Kerberos の問題をデバッグするのは「難しい」場合があります。有用なテクニックの 1 つは、HADOOP_JAAS_DEBUG 環境変数を設定して、Hadoop で Kerberos 操作の追加ログを有効にすることです。

export HADOOP_JAAS_DEBUG=true

JDK クラスは、システムプロパティ sun.security.krb5.debug および sun.security.spnego.debug=true を介して、Kerberos および SPNEGO/REST 認証の追加ログを有効にするように構成できます。

-Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true

これらすべてのオプションは Application Master で有効にできます。

spark.yarn.appMasterEnv.HADOOP_JAAS_DEBUG true
spark.yarn.am.extraJavaOptions -Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true

最後に、org.apache.spark.deploy.yarn.Client のログレベルが DEBUG に設定されている場合、ログには取得されたすべてのトークンとその有効期限の詳細のリストが含まれます。

外部シャフルサービスの構成

YARN クラスターの各 NodeManager で Spark Shuffle Service を起動するには、以下の手順に従ってください。

1. YARN プロファイル で Spark をビルドします。事前パッケージ化されたディストリビューションを使用している場合は、この手順をスキップしてください。
2. spark-<version>-yarn-shuffle.jar を見つけます。Spark を自分でビルドしている場合は $SPARK_HOME/common/network-yarn/target/scala-<version> の下に、ディストリビューションを使用している場合は yarn の下にあります。
3. この JAR をクラスターのすべての NodeManager のクラスパスに追加します。
4. 各ノードの yarn-site.xml で、yarn.nodemanager.aux-services に spark_shuffle を追加し、次に yarn.nodemanager.aux-services.spark_shuffle.class を org.apache.spark.network.yarn.YarnShuffleService に設定します。
5. etc/hadoop/yarn-env.sh で YARN_HEAPSIZE (デフォルト 1000) を設定して NodeManager のヒープサイズを増やし、シャフルの間のガベージコレクションの問題を回避します。
6. クラスターのすべての NodeManager を再起動します。

シャフルサービスが YARN で実行されている場合、次の追加設定オプションが利用可能です。

上記の指示は、デフォルトのシャフルサービス名 spark_shuffle が使用されていることを前提としていることに注意してください。ここでは任意の名前を使用できますが、YARN NodeManager 設定で使用される値は、Spark アプリケーションの spark.shuffle.service.name の値と一致する必要があります。

デフォルトでは、シャフルサービスは Hadoop 設定 (例: yarn-site.xml) からすべての設定を取得します。ただし、spark-shuffle-site.xml という名前のファイルを使用してシャフルサービスを個別に構成することも可能です。このファイルはシャフルサービスのクラスパスに配置する必要があり (デフォルトでは NodeManager のクラスパスと共有されています)。シャフルサービスは、これを標準の Hadoop 設定リソースとして扱い、NodeManager の設定の上に重ね合わせます。

Apache Oozie を使用したアプリケーションの起動

Apache Oozie は、ワークフローの一部として Spark アプリケーションを起動できます。セキュアなクラスターでは、起動されたアプリケーションはクラスターのサービスにアクセスするために関連するトークンを必要とします。Spark がキータブで起動される場合、これは自動的です。しかし、Spark がキータブなしで起動される場合、セキュリティ設定の責任は Oozie に委ねられる必要があります。

セキュアなクラスター用の Oozie の構成とジョブの認証情報の取得の詳細については、Oozie ウェブサイト の特定のリリースドキュメントの「認証」セクションを参照してください。

Spark アプリケーションの場合、Oozie ワークフローは、アプリケーションが必要とするすべてのトークンを Oozie が要求するように設定する必要があります。これには以下が含まれます。

• YARN リソースマネージャー。
• ローカル Hadoop ファイルシステム。
• I/O のソースまたは宛先として使用されるリモート Hadoop ファイルシステム。
• Hive — 使用する場合。
• HBase — 使用する場合。
• YARN タイムラインサーバー — アプリケーションがこれとやり取りする場合。

Spark が Hive、HBase、およびリモート HDFS トークンを取得しようとして失敗するのを避けるために、Spark 設定でこれらのサービスに対するトークン収集を無効にする必要があります。

Spark 設定には、以下の行を含める必要があります。

spark.security.credentials.hive.enabled   false
spark.security.credentials.hbase.enabled  false

設定オプション spark.kerberos.access.hadoopFileSystems は未設定である必要があります。

Spark Web UI の代わりとなる Spark History Server の使用

アプリケーション UI が無効になっている実行中のアプリケーションのトラッキング URL として Spark History Server アプリケーションページを使用することが可能です。これはセキュアなクラスターでは望ましい場合があり、Spark ドライバーのメモリ使用量を削減できます。Spark History Server を介したトラッキングを設定するには、次の手順を実行します。

• アプリケーション側で、Spark の設定で spark.yarn.historyServer.allowTracking=true を設定します。これにより、アプリケーション UI が無効になっている場合、Spark は History Server の URL をトラッキング URL として使用するようになります。
• Spark History Server 側で、spark.ui.filters 設定のフィルタリストに org.apache.spark.deploy.yarn.YarnProxyRedirectFilter を追加します。

History Server の情報がアプリケーションのステータスと最新でない場合があることに注意してください。

Spark シャフルサービスの複数バージョンの実行

このセクションは YARN バージョン >= 2.9.0 で実行する場合にのみ適用されることに注意してください。

場合によっては、異なる Spark バージョンを使用する Spark Shuffle Service の複数のインスタンスを実行することが望ましい場合があります。これは、たとえば、複数の Spark バージョンを実行するアプリケーションの混合ワークロードを持つ YARN クラスターを実行する場合に役立ちます。なぜなら、特定のバージョンのシャフルサービスは、他の Spark バージョンと常に互換性があるわけではないからです。YARN 2.9.0 以降では、シャフルサービスを分離されたクラスローダー内で実行する機能がサポートされています (YARN-4577 YARN-4577 を参照)。これにより、単一の NodeManager 内で複数の Spark バージョンが共存できます。yarn.nodemanager.aux-services.<service-name>.classpath および YARN 2.10.2/3.1.1/3.2.0 以降では、yarn.nodemanager.aux-services.<service-name>.remote-classpath オプションを使用してこれを構成できます。YARN 3.3.0/3.3.1 には、回避策として yarn.nodemanager.aux-services.<service-name>.system-classes を設定する必要がある問題があることに注意してください。詳細は YARN-11053 YARN-11053 を参照してください。個別のクラスパスを設定することに加えて、2 つのサービスが異なるポートでアドバタイズされるようにする必要があります。これは、上記で説明した spark-shuffle-site.xml ファイルを使用して達成できます。たとえば、次のような構成がある場合があります。

  yarn.nodemanager.aux-services = spark_shuffle_x,spark_shuffle_y
  yarn.nodemanager.aux-services.spark_shuffle_x.classpath = /path/to/spark-x-path/fat.jar:/path/to/spark-x-config
  yarn.nodemanager.aux-services.spark_shuffle_y.classpath = /path/to/spark-y-path/fat.jar:/path/to/spark-y-config

または

  yarn.nodemanager.aux-services = spark_shuffle_x,spark_shuffle_y
  yarn.nodemanager.aux-services.spark_shuffle_x.classpath = /path/to/spark-x-path/*:/path/to/spark-x-config
  yarn.nodemanager.aux-services.spark_shuffle_y.classpath = /path/to/spark-y-path/*:/path/to/spark-y-config

2 つの spark-*-config ディレクトリには、それぞれ spark-shuffle-site.xml という名前のファイルが含まれています。これらは Hadoop Configuration フォーマット の XML ファイルであり、それぞれポート番号と使用されるメトリクス名プレフィックスを調整するためのいくつかの設定が含まれています。

<configuration>
  <property>
    <name>spark.shuffle.service.port</name>
    <value>7001</value>
  </property>
  <property>
    <name>spark.yarn.shuffle.service.metrics.namespace</name>
    <value>sparkShuffleServiceX</value>
  </property>
</configuration>

値は、2 つの異なるサービスでそれぞれ異なる必要があります。

次に、Spark アプリケーションの設定で、一方を次のように構成します。

  spark.shuffle.service.name = spark_shuffle_x
  spark.shuffle.service.port = 7001

もう一方は次のように構成します。

  spark.shuffle.service.name = spark_shuffle_y
  spark.shuffle.service.port = <other value>

Spark アプリケーション用の異なる JDK の構成

場合によっては、YARN ノードマネージャーとは異なる JDK を Spark アプリケーションの実行に使用することが望ましい場合があります。これは、YARN コンテナおよび spark-submit プロセスに JAVA_HOME 環境変数を設定することで実現できます。

Spark は、1 つのアプリケーションで実行されるすべての JVM プロセスが同じ JDK バージョンを使用すると想定していることに注意してください。そうでない場合、JDK シリアライゼーションの問題が発生する可能性があります。

すべてのノードに /opt/openjdk-17 に事前にインストールされている JDK を使用するように Spark アプリケーションを構成するには

$ export JAVA_HOME=/opt/openjdk-17
$ ./bin/spark-submit --class path.to.your.Class \
    --master yarn \
    --conf spark.yarn.appMasterEnv.JAVA_HOME=/opt/openjdk-17 \
    --conf spark.executorEnv.JAVA_HOME=/opt/openjdk-17 \
    <app jar> [app options]

オプションとして、ユーザーは YARN クラスターノードに別の JDK をインストールすることを避けたい場合があります。そのような場合、YARN の分散キャッシュを使用して JDK を配布することも可能です。たとえば、Java 21 を Spark アプリケーションの実行に使用するには、JDK 21 tarball openjdk-21.tar.gz を準備し、ローカルノードの /opt に解凍してから、Spark アプリケーションをサブミットします。

$ export JAVA_HOME=/opt/openjdk-21
$ ./bin/spark-submit --class path.to.your.Class \
    --master yarn \
    --archives path/to/openjdk-21.tar.gz \
    --conf spark.yarn.appMasterEnv.JAVA_HOME=./openjdk-21.tar.gz/openjdk-21 \
    --conf spark.executorEnv.JAVA_HOME=./openjdk-21.tar.gz/openjdk-21 \
    <app jar> [app options]