YARN上でSparkを実行する

• セキュリティ
• YARN上でSparkを起動
  • 他のJARを追加
• 準備
• 設定
• アプリケーションのデバッグ
  • Sparkのプロパティ
  • SHS カスタム executor ログ URL で利用可能なパターン
• リソース割り当てと設定の概要
• ステージレベルのスケジューリングの概要
• 重要事項
• Kerberos
  • YARN固有のKerberos設定
  • Kerberosのトラブルシューティング
• 外部シャッフルサービスの設定
• Apache Oozieを使ってアプリケーションを起動
• Spark Web UIを置き換えるためのSpark履歴サーバの使用
• 複数のバージョンのSparkシャッフルサービスの実行

YARN (Hadoop NextGen)上での実行はバージョン0.6.0でSparkに追加され、続くリリースで改良されました。

セキュリティ

認証のようなセキュリティ機能はデフォルトでは有効にされていません。インターネットや信頼できないネットワークに開かれたクラスタを配備する場合、認証されていないアプリケーションをクラスタ上で実行することを防ぐためにクラスタへのアクセスを安全にすることが重要です。Sparkを実行する前にSpark セキュリティとこのドキュメントの特定のセキュリティの章を見てください。

YARN上でSparkを起動

HADOOP_CONF_DIR あるいはYARN_CONF_DIR がHadoopクラスタのための(クライアントサイドの)設定ファイルを含むディレクトリを指すようにします。これらの設定はHDFSに書き込み、YARNリソースマネージャーに接続するために使用されます。このディレクトリに含まれる設定はYARNクラスタに分配され、アプリケーションに使用される全てのコンテナは同じ設定を使用します。設定がJavaシステムプロパティを参照あるいは環境変数がYARNによって管理されていない場合は、それらはSparkアプリケーション設定(ドライバー、executor、およびクライアントモードで実行している場合はAM)にも設定されていなければなりません。

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

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

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

$ ./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はアプリケーションマスターの子スレッドとして実行されるでしょう。クライアントはステータスの更新とそれらをコンソールに表示するために定期的にアプリケーションマスターをポーリングします。一旦アプリケーションの実行が終了するとクライアントは終了するでしょう。ドライバーおよびexecutorのログをどうやって見るかについては以下の Debugging your Applicationセクションを参照してください。

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のバイナリ配布物が必要です。バイナリ配布物はプロジェクトのwebサイトのダウンロードページ</a>からダウンロードすることができます。ダウンロードできるSparkのバイナリ配布には、2つの種類があります。1つは特定のバージョンのApache Hadoopで事前にビルドされたものです; このSparkの配布物はHadoopのランタイムが組み込まれているため、hadoop付き Spark 配布物と呼びます。もう1つは、ユーザ提供のHadoopで事前にビルドされたものです; このSpark配布物は組み込みのHadoopランタイムを含まないため、サイズは小さくなりますが、ユーザはHadoopインストールを別に提供する必要があります。この変種をhadoop無し Spark 配布物と呼びます。hadoop付き Spark 配布物に関しては、組み込みのHadoopランタイムがすでに含まれているため、デフォルトではジョブがHadoop Yarnクラスタにサブミットされる時にジョブの競合を防ぐために、SparkにはYarnのクラスパスが設定されないでしょう。この動作を上書きするために、spark.yarn.populateHadoopClasspath=trueを設定できます。hadoop無し Spark 配布物に関しては、Spark はHadoopランタイムを取得するために、デフォルトでYarnのクラスパスを設定します。hadoop付き Spark配布物の場合、アプリケーションがクラスタでのみ使用可能な特定のライブラリに依存している場合は、上記のプロパティを設定してYarnクラスパスを設定してみてください。そうすることでjarの競合の問題が発生する場合は、それをオフにしてこのライブラリをアプリケーションjarに含める必要があります。

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

YARN側からSparkランタイムのjarをアクセス可能にするために、spark.yarn.archive あるいは spark.yarn.jars を指定することができます。詳細はSpark Propertiesを参照してください。spark.yarn.archive あるいは spark.yarn.jars のどちらも指定されない場合は、Sparkは $SPARK_HOME/jars の下にある全てのjarを使ってzipファイルを生成し、それを分散キャッシュにアップロードするでしょう。

設定

他のデプロイモードについては、ほとんどの設定はYARN上のSPARKと同じです。これらの詳細な情報は設定ページを見てください。これらはYARN上のSPARKに固有です。

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

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

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履歴サーバとMapReduce履歴サーバの両方の動作が必要で、yarn-site.xml適切にyarn.log.server.url を設定する必要があります。Spark履歴サーバUI上のログURLは集約されたログを表示するためにMapReduce履歴サーバにリダイレクトするでしょう。

ログの集約をオンにしていない場合は、ログは各マシーン上のYARN_APP_LOGS_DIRの下にローカルに保持されます。これは通常/tmp/logs あるいは、Hadoopのバージョンおよびインストレーションに依存する $HADOOP_HOME/logs/userlogsに設定されます。コンテナンのログを見るにはそれらを含むホストに行き、このディレクトリを調べる必要があります。サブディレクトリはアプリケーションIDとコンテナIDでログファイルを整理します。このログはSpark Web UIのexecutorタブでも利用可能で、MapReduce履歴サーバの実行を必要としません。

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

アプリケーションマスターあるいはexecutorのための独自log4j設定を使うには、以下の選択肢があります:

• アプリケーションと一緒にアップロードされる--filesのファイルのリストにlog4j.propertiesを追加することで、spark-submitを使って独自のlog4j.propertiesをアップロードします。
• -Dlog4j.configuration=<location of configuration file>に spark.driver.extraJavaOptions (ドライバーのため)、あるいは spark.executor.extraJavaOptions (executorのため)を追加します。ファイルを使う場合は明示的に file: プロトコルが提供されなければならず、そのファイルは全てのノード上でローカルに存在しなければならない事に注意してください。
• $SPARK_CONF_DIR/log4j.properties ファイルを更新すると、他の設定と一緒に自動的にアップロードされるでしょう。複数のオプションが指定された場合は、このオプションよりも他の2つのオプションが優先されることに注意してください。

最初の選択肢は、executorとアプリケーションマスターの両方が同じlog4j設定を共有するでしょう。これは同じノード上で動作する場合に問題を起こすかもしれません(例えば、同じログファイルに書き込もうとします)。

YARNがログを適切に表示および集約できるようにYARN内でログファイルを置く適切な場所への参照を必要とする場合は、log4j.propertiesのspark.yarn.app.container.log.dirを使ってください。例えば、log4j.appender.file_appender.File=${spark.yarn.app.container.log.dir}/spark.log。ストリーミングアプリケーションについては、RollingFileAppenderの設置とファイルの場所をYARNのログディレクトリに設定することで、大きなログファイルによって起こるディスクオーバーフローを避けることができ、ログはYARNのログユーティリティを使ってアクセスすることができるでしょう。

アプリケーションマスターとexecutorのために独自の metrics.properties を使うには、$SPARK_CONF_DIR/metrics.properties ファイルを更新します。他の設定と一緒に自動的にアップロードされるでしょう。つまり、手動で --filesを使って指定する必要はありません。

Sparkのプロパティ

SHS カスタム executor ログ URL で利用可能なパターン

例えば、ノードマネージャの http サーバにリダイレクトさせずに、ログ URL リンクをジョブ履歴サーバに直接ポイントする場合は、以下のように 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 ドキュメントを見てください。理想的には、リソースは executor が割り当てられたリソースのみを見ることができるように、分離してセットアップされます。分離を有効にしていない場合、ユーザはリソースが executor 間で共有されないようにする検出スクリプトを作成する必要があります。

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.) の両方の設定を指定する必要があります。

例えば、ユーザは executor ごとに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 に通知しません。そのため、ユーザは起動時に executor によって実行される検出スクリプトを指定して、その executor が利用可能なリソースを検出する必要があります。サンプルスクリプトは examples/src/main/scripts/getGpusResources.sh にあります。スクリプトには実行権限が設定されている必要があり、ユーザは悪意のあるユーザがスクリプトを変更できないように権限を設定する必要があります。スクリプトは STDOUT に ResourceInformation クラスの形式で JSON 文字列を書き込む必要があります。これは、リソース名とその executor だけが利用できるリソースアドレスの配列を持ちます。

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

動的割り当てが有効な場合、YARNでステージレベルのスケジューリングがサポートされます。YARN固有で1つ注意すべきことは、各ResourceProfileはYARNで異なるコンテナ優先度を必要とすることです。The mapping is simply the ResourceProfile id becomes the priority, on YARN lower numbers are higher priority. これは、先に作成されたプロファイルがYARNでより高い優先度を持つことを意味します。Sparkは別のステージを開始する前に1つのステージを終了するため、通常これは問題になりません。これが影響を与える可能性があるのは、ジョブサーバ型のシナリオのみであるため、注意が必要です。基本のデフォルトプロファイルと独自のResourceProfileの間でカスタムリソースの処理方法に違いがあることに注意してください。ユーザがSparkスケジューリング無しで追加のリソースを含むYARNコンテナを要求できるようにするために、ユーザはspark.yarn.executor.resource.設定を介してリソースを指定できます。ただしこれらの設定は基本のデフォルトプロファイルのみで使われ、他の独自のResourceProfileには伝搬されません。これはステージにそれらを持たせたくない場合、それらを削除する方法がないためです。これによりデフォルトのプロファイルで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.)設定から指定しなければなりません。追加のリソースを含むYARNコンテナのみが必要で、Sparkがそれらの使用をスケジュールしない場合は、Spark設定をオフのままにします。現在のところ、独自のResourceProfileの場合、SparkがそれらをスケジューリングせずにYARNリソースのみを指定する方法はありません。これは、独自のResourceProfileの場合、ResourceProfileで定義されたすべてのリソースをYARNに伝播することを意味します。まだ、GPUとFPGAをYARNの組み込み型に変換します。これは、指定する独自のリソースの名前がYARNで定義されているものと一致する必要があります。

重要事項

• スケジュールの決定時にコアのリスクエストが尊重されるかどうかは、どのスケジューラが使われているか、およびどのように設定されているかに依存します。
• cluster モードではSpark executorおよびSpark ドライバによって使われるローカルディレクトリは、YARNのための設定のローカルディレクトリでしょう((Hadoop YARN config yarn.nodemanager.local-dirs)。ユーザが spark.local.dirを指定した場合は、無視されるでしょう。clientモードでは、Spark executorはYARNのために設定されたローカルディレクトリを使うでしょう。一方でSparkドライバは spark.local.dirで定義されたそれらを使うでしょう。これはSparkドライバは client モードでは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 問題は"困難"になる可能性があります。有用な方法のひとつは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

これら全てのオプションはアプリケーションマスター内で有効にすることができます:

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シャッフルサービスを開始するには、以下の説明に従ってください:

1. SparkをYARN profileを使ってビルドします。pre-packaged配布物を使っている場合はこのステップをスキップします。
2. spark-<version>-yarn-shuffle.jarを配置します。Sparkを自身で構築した場合は $SPARK_HOME/common/network-yarn/target/scala-<version> の下に無ければならず、配布物を使っている場合はyarnの下に無ければなりません。
3. このjarをクラスタ内の全てのNodeManagerのクラスパスに追加します。
4. 各ノード上のyarn-site.xml の中で、spark_shuffleをyarn.nodemanager.aux-servicesに追加し、その後、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設定から全ての設定を取得します(例、yarn-site.xml)。ただし、spark-shuffle-site.xmlという名前のファイルを使って、シャッフルサービスを個別に設定することもできます。このファイルはシャッフルサービスのクラスパスに配置する必要があります(デフォルトでは、NodeManagerのクラスパスで共有されます)。シャッフルサービスはこれを標準のHadoop設定リソースとして扱い、NodeManagerの設定を上書きします。

Apache Oozieを使ってアプリケーションを起動

Apache Oozie はSparkアプリケーションをワークフローの一部として起動することができます。secureクラスタ内で、起動されたアプリケーションはクラスタのサービスにアクセスするために関係するトークンを必要とするでしょう。Sparkがkeytabを使って起動された場合は、これは自動的です。しかし、もしSparkがkeytab無しで起動された場合は、securityをセットアップする責任はOozieに移譲されなければなりません。

secureなクラスタのためにOozieを設定およびジョブのための証明書を取得する詳細は、特定のリリースドキュメントの"認証"の章のOozie web サイトで見つけることができます。

Sparkのアプリケーションのために、OozieワークフローはOozieがアプリケーションが必要とする以下を含む全てのトークンを要求するようにセットアップしなければなりません:

• YARN リソースマネージャー。
• ローカルのHadoopファイルシステム。
• I/Oの起点あるいは宛先として使用されるリモートのHadoopファイルシステム。
• Hive - もし使っていれば。
• HBase - もし使っていれば。
• アプリケーションがYARNタイムラインサーバとやり取りするのであれば、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履歴サーバの使用

アプリケーション UIが無効の時に、実行中のアプリケーションのための追跡のURLとしてSpark履歴サーバ アプリケーションを使うことができます。これはsecureなクラスタ、あるいはSparkドライバのメモリの使用を減らすために望ましいかも知れません。Spark履歴サーバを使って追跡を設定するには、以下を行います:

• アプリケーション側で、Sparkの設定でspark.yarn.historyServer.allowTracking=true を設定します。これはアプリケーションのUIが無効の時に、追跡URLとして履歴サーバのURIを使うようにSparkに伝えます。
• Spark履歴サーバ側で、spark.ui.filters 設定の中のフィルタのリストに org.apache.spark.deploy.yarn.YarnProxyRedirectFilter を追加します。

履歴サーバの情報はアプリケーションの状態が原因で最新ではないかも知れないことに注意してください。

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

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

場合によってでゃ、異なるバージョンのSparkを使っているSparkシャッフルサービスの複数のインスタンスを実行することが望ましい場合があります。これは、例えば、複数のSparkバージョンを実行するアプリケーションのワークロードが混在するYARNクラスタを実行する場合に役立ちます。これは、特定のバージョンのシャッフルサービスが他のバージョンのSparkと常に互換性があるとは限らないためです。2.9.0以降のYARNバージョンは分離されたクラスローダ内でシャッフルサービスを実行する機能をサポートします(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 オプションを使ってこれを設定できます。別々のクラスパスを設定することに加えて、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-yarn-shuffle.jar,/path/to/spark-x-config
  yarn.nodemanager.aux-services.spark_shuffle_y.classpath = /path/to/spark-y-yarn-shuffle.jar,/path/to/spark-y-config

2つのspark-*-configディレクトリには、それぞれのファイル spark-shuffle-site.xmlが含まれています。これらはHadoop Configuration formatの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アプリケーションの設定で、1つは以下のように設定する必要があります。

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

もう1つは以下のように設定する必要があります:

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