YARN 上での Spark 実行

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

YARN (Hadoop NextGen) 上での実行のサポートは、Spark バージョン 0.6.0 で追加され、以降のリリースで改良されました。YARN (Hadoop NextGen)

セキュリティ

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

YARN 上での Spark の起動

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

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

マスターのアドレスが --master パラメータで指定される Spark がサポートする他のクラスタマネージャとは異なり、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

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

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

$ ./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 のバイナリ配布が必要です。バイナリ配布は、プロジェクト Web サイトのダウンロードページからダウンロードできます。ダウンロードできる 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 配布の場合、Spark は Hadoop ランタイムを取得するために、デフォルトで 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 ファイルを作成し、それを分散キャッシュにアップロードします。

設定

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

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

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 でも利用できます。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 でも利用でき、MapReduce history server の実行は必要ありません。

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

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

• spark-submit を使用してカスタム log4j.properties をアップロードし、アプリケーションと共にアップロードするファイルの --files リストに追加します。
• -Dlog4j.configuration=<設定ファイルの場所> を spark.driver.extraJavaOptions（ドライバの場合）または spark.executor.extraJavaOptions（エグゼキュータの場合）に追加します。ファイルを使用する場合は、file: プロトコルを明示的に指定する必要があり、ファイルはすべてのノードのローカルに存在する必要があります。
• $SPARK_CONF_DIR/log4j.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リンクをNodeManager 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固有の側面についてのみ説明しています。

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

YARNはユーザー定義のリソースタイプをサポートしていますが、GPU（`yarn.io/gpu`）とFPGA（`yarn.io/fpga`）の組み込みタイプがあります。そのため、これらのリソースのいずれかを使用している場合、SparkはSparkリソースのリクエストをYARNリソースに変換できるため、spark.{driver/executor}.resource.設定を指定するだけで済みます。YARNでGPUまたはFPGAにカスタムリソースタイプを使用している場合は、spark.yarn.resourceGpuDeviceNameとspark.yarn.resourceFpgaDeviceNameを使用してSparkのマッピングを変更できます。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文字列をSTDOUTに出力する必要があります。これには、リソース名と、そのエグゼキュータのみが使用できるリソースアドレスの配列が含まれています。

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

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

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

YARN固有の注意点として、各ResourceProfileには異なるYARNコンテナ優先度が必要であることが挙げられます。マッピングは単純にResourceProfile IDが優先度になり、YARNでは数値が小さいほど優先度が高くなります。つまり、先に作成されたプロファイルの方がYARNでの優先度が高くなります。通常、Sparkは1つのステージが完了する前に次のステージを開始するため、これは問題になりません。影響を与える可能性があるのはジョブサーバータイプのシナリオのみです。念頭に置いておいてください。カスタムリソースの処理方法は、基本のデフォルトプロファイルとカスタムResourceProfileで異なります。ユーザーがSparkでのスケジューリングを行わずに、追加リソースを持つYARNコンテナを要求できるようにするため、ユーザーはspark.yarn.executor.resource.設定を使用してリソースを指定できます。ただし、これらの設定は基本のデフォルトプロファイルでのみ使用され、他のカスタムResourceProfileには伝播されません。これは、ステージでそれらを使用しないようにする場合に削除する方法がないためです。その結果、デフォルトプロファイルにはspark.yarn.executor.resource.で定義されたカスタムリソースと、Sparkで定義されたGPUまたはFPGAのリソースが設定されます。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.）の両方の設定で指定する必要があります。YARNコンテナに追加リソースのみを必要とし、Sparkでそれらを使用してスケジューリングを行わない場合は、Sparkの設定をオフのままにしてください。カスタムResourceProfileの場合、現在、Sparkによるスケジューリングを行わずにYARNリソースのみを指定する方法はありません。つまり、カスタムResourceProfileでは、ResourceProfileで定義されているすべてのリソースがYARNに伝播されます。GPUとFPGAも同様にYARN組み込みタイプに変換されます。そのため、指定するカスタムリソースの名前は、YARNで定義されている名前と一致する必要があります。

重要な注意事項

• コア要求がスケジューリングの意思決定で考慮されるかどうかは、使用しているスケジューラとその設定によって異なります。
• clusterモードでは、Spark ExecutorとSpark Driverで使用されるローカルディレクトリは、YARN用に設定されたローカルディレクトリ（Hadoop YARN設定yarn.nodemanager.local-dirs）になります。ユーザーがspark.local.dirを指定した場合、それは無視されます。clientモードでは、Spark ExecutorはYARN用に設定されたローカルディレクトリを使用しますが、Spark Driverはspark.local.dirで定義されたローカルディレクトリを使用します。これは、clientモードではSpark DriverがYARNクラスタ上で実行されず、Spark Executorのみが実行されるためです。
• --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. SparkをYARNプロファイルでビルドします。事前にパッケージ化されたディストリビューションを使用している場合は、この手順をスキップしてください。
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の値と一致する必要があります。

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

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

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

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

Sparkアプリケーションの場合、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は履歴サーバーのURLをトラッキングURLとして使用します。
• Spark History Serverでは、spark.ui.filters設定のフィルタリストにorg.apache.spark.deploy.yarn.YarnProxyRedirectFilterを追加します。

履歴サーバーの情報は、アプリケーションの状態と最新ではない可能性があることに注意してください。

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

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

場合によっては、異なるバージョンのSparkを使用するSpark Shuffle Serviceの複数のインスタンスを実行することが望ましい場合があります。これは、たとえば、複数のSparkバージョンを実行するアプリケーションの混在ワークロードを持つYARNクラスタを実行する場合に役立ちます。特定のバージョンのシャッフルサービスは、他のバージョンのSparkと常に互換性があるとは限らないためです。YARNバージョン2.9.0以降は、分離されたクラスローダー内でシャッフルサービスを実行する機能をサポートしています（YARN-4577を参照）。つまり、単一ノードマネージャ内で複数の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を参照してください。個別のクラスパスの設定に加えて、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ディレクトリにはそれぞれ1つのファイル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>