アプリケーションの提出
Sparkのbin
ディレクトリの中にある spark-submit
スクリプトはクラスタ上でアプリケーションを起動するために使われます。それは一様のインタフェースを使ってSparkのサポートするクラスタマネージャーを使用することができるため、アプリケーションをそれぞれのために特別に設定する必要はありません。
アプリケーションの依存性をバンドル
コードが他のプロジェクトに依存する場合は、コードをSparkのクラスタに配布するためにアプリケーションと一緒にそれらをパッケージする必要があるでしょう。これをするには、コードとその依存物を含むアセンブリjar(あるいは"uber"jar)を作る必要があります。sbt と Mavenの両方ともアセンブリ プラグインを持ちます。アセンブリjarを生成する時に、SparkおよびHadoopをprovided
依存性としてリストします; それらは実行時にクラスタマネージャーによって提供されるため、これらはバンドルされる必要があります。一旦アセンブルされたjarを持つと、ここで示すようにjarを渡している間に bin/spark-submit
スクリプトを呼び出すことができます。
Pythonの場合、.py
, .zip
あるいは .egg
ファイルをアプリケーションと一緒に分散されるものに追加するために、spark-submit
の--py-files
引数を使うことができます。複数のPythonファイルに依存する場合は、それらを.zip
または .egg
にパッケージングすることをお勧めします。サードパーティのPythonの依存については、Python Package Managementを見てください。
spark-submitを使ってアプリケーションを起動
一旦ユーザアプリケーションがバンドルされると、bin/spark-submit
スクリプトを使って起動することができます。このスクリプトはSparkおよびその依存物を使ったクラスパスの設定の世話をし、Sparkがサポートする異なるクラスターマネージャーとデプロイモードをサポートします。
良く使われるオプションの幾つかは:
--class
: アプリケーションのエントリーポイント(例えば、org.apache.spark.examples.SparkPi
)--master
: クラスターのためのmaster URL (例えば、spark://23.195.26.187:7077
)--deploy-mode
: ワーカーノード上(cluster
)のドライバをデプロイするか、外部クライアント(client
)としてローカルにデプロイするかどうか (デフォルトt:client
) †--conf
: key=value形式の任意のSpark設定プロパティ空白を含む値の場合、(このように)"key=value"を引用符で囲みます。複数の設定は、個々の引数として渡されなければなりません。(例えば、--conf <key>=<value> --conf <key2>=<value2>
)application-jar
: アプリケーションとs部得ての依存物を含むバンドルされたjarのパス。クラスタ内でURLは大域的に見えなければなりません。例えば、全てのノード上に存在するhdfs://
パスあるいはfile://
パスです。application-arguments
: もしあれば、メインクラスのメインメソッドに渡す引数
† 一般的なデプロイのストラテジはワーカーマシーンと物理的に同じ場所にあるゲートウェイマシーンからアプリケーションをサブミットします(例えば、スタンドアローンEC2クラスタ内のマスターノード)。このセットアップでは、クライアント
モードが適切です。クライアント
モードでは、ドライバーはクラスターに対するクライアント
として振る舞うspark-submit
プロセスの中で直接起動されます。アプリケーションの入力と出力はコンソールにアタッチされます。したがって、このモードはREPLを含むアプリケーション (例えば、Spark シェル)に特に適しています。
もう一つの方法として、もしアプリケーションがワーカーマシーンから離れたマシーンからサブミットされた場合(例えば、手元のラップトップ)、ドライバーとexecutorの間のネットワーク遅延を最小化するためにクラスター
モードを使うことが一般的です。現在のところ、スタンドアローンモードはPythonアプリケーションについてクラスタモードをサポートしません。
Pythonアプリケーションに関しては、JARの代わりに.py
ファイルを <application-jar>
の代わりに単純に渡し、Pythonの.zip
, .egg
あるいは .py
ファイルを --py-files
を使って検索パスに追加します。
使用されるクラスターマネージャーに固有の利用可能な2,3のオプションがあります。例えば、クラスタ
デプロイモードのSpark スタンドアローンクラスタを使って、もし非0の終了コード無しに失敗した場合にドライバーが自動的に必ず再起動するように--supervise
を指定することもできます。そのようなspark-submit
で利用可能な全てのオプションを数え上げるには、--help
を付けてそれを実行してください。一般的なオプションの2,3の例があります:
マスターURL
Sparkに渡されるマスターURLは以下のフォーマットのうちの一つです:
マスターURL | 意味 |
---|---|
local | Sparkをローカルで一つのワーカースレッドで実行する(つまり、全く並行ではありません)。 |
local[K] | SparkをローカルでK個のワーカースレッドで実行する(理想的には、マシーン上のコアの数に設定します)。 |
local[K,F] | SparkをローカルでK個のワーカースレッドとF のmaxFailureで実行する(この変数の説明についてはspark.task.maxFailuresを見てください)。 |
local[*] | Sparkをローカルでマシーン上の論理コアと同数のワーカースレッドで実行する。 |
local[*,F] | Sparkをローカルでマシーン上の論理コアと同数のワーカースレッドと、F maxFailureで実行する。 |
local-cluster[N,C,M] | ローカルクラスタモードはユニットテストのためだけのものです。N個のワーカー、ワーカーごとにC個のコア、ワーカーごとにM MiBのメモリを単一のJVM内で分散クラスタをエミュレートします。 |
spark://HOST:PORT | 指定されたSpark スタンドアローン クラスタ マスターに接続する。ポートはマスターが使用するように設定されたどちらかでなければなりません。デフォルトでは7077です。 |
spark://HOST1:PORT1,HOST2:PORT2 | 指定された ZooKeeperを使ったスタンドバイのマスタを持つSparkスタンドアローンクラスタへ接続する。リストは、ZooKeeperを使ってセットアップした高可用性クラスタ内のマスターの全てのホストである必要があります。ポートは各マスターが使用するように設定されたどちらかでなければなりません。デフォルトでは7077です。 |
mesos://HOST:PORT | 指定された Mesosクラスタに接続する。ポートはマスターが使用するように設定されたどちらかでなければなりません。デフォルトでは5050です。あるいはZooKeeperを使っているMesosクラスタの場合は、mesos://zk://... を使います。--deploy-mode cluster を付けてサブミットするには、MesosClusterDispatcherに接続するために HOST:PORT が設定されていなければなりません。
|
yarn | --deploy-mode の値に依存するclient あるいは cluster モードで、 YARN クラスタに接続します。クラスタの場所はHADOOP_CONF_DIR あるいは YARN_CONF_DIR 変数に基づいて見つけられるでしょう。
|
k8s://HOST:PORT | --deploy-mode の値に依存するclient あるいは cluster モードで、Kubernetes クラスタに接続します。HOST とPORT は、Kubernetes API Serverを参照します。デフォルトでTLSを使って接続します。安全では無い接続を使うように強制するために、k8s://http://HOST:PORT を使うことができます。
|
ファイルから設定をロードする
spark-submit
スクリプトはプロパティファイルからデフォルトのSpark 設定値をロードし、それらをアプリケーションに渡すことができます。デフォルトでは、Sparkディレクトリ内のconf/spark-defaults.conf
からオプションを読み込むでしょう。詳細は デフォルトの設定のロードの章を見てください。
この方法でデフォルトのSpark設定をロードすると、特定のフラグがspark-submit
する必要性を未然に防ぎます。例えば、もしspark.master
プロパティが設定された場合、安全に --master
フラグをspark-submit
から省略することができます。一般的に、SparkConf
に明示的に設定された設定値は高い先例となり、次にspark-submit
に渡されたフラグで、その次がデフォルトのファイル中の値です。
設定オプションが来ている場所がこれまで明確では無い場合は、c0>spark-submitを--verbose
オプションを付けて実行することで、細かいデバッグ情報を出力することができます。
上級の依存管理
spark-submit
を使う場合、--jars
オプションを使って含まれる全てのjarと一緒にアプリケーションのjarが自動的にクラスタに転送されるでしょう。--jars
の後に渡されるURLはカンマで区切られてなければなりません。そのリストはドライバーとexecutorのクラスパスに含まれます。ディレクトリの拡張は --jars
と一緒には動作しません。
Sparkはjarを広めるために以下の異なる戦略を使用します:
- file: - ドライバーのHTTPファイルサーバによって提供される絶対パスと
file:/
URI。各executorはドライバーのHTTPサーバからファイルを取り出します。 - hdfs:, http:, https:, ftp: - これらは期待されるURIからファイルおよびJARを取り出します。
- local: - local:/ から始まるURIは、各ワーカーノード上のローカルファイルとして存在することが期待されます。このことは、ネットワークIOが発生せず、各ワーカーに送信、あるいはNFS、GlusterFSなどで共有される大きなファイル/JARにとって良く動作します。
JARおよびファイルはexecutorノード上の各SparkContextの作業ディレクトリにコピーされることに注意してください。これは長い間に膨大な量の容量を使い果たすかも知れず、掃除されなければならないでしょう。WARNを使う場合、掃除は自動的に処理され、Sparkスタンドアローンを使う場合はspark.worker.cleanup.appDataTtl
プロパティを使って自動的な掃除が設定可能です。
ユーザは--packages
を使ってMaven coordinateのカンマ区切りのリストを渡すことで他の依存性も含めるかもしれません。全ての推移的な依存性はこのコマンドが使われる場合に処理されるでしょう。追加のリポジトリ(あるいはSBTでのリゾルバー)は、フラグ--repositories
を使ったカンマ区切りの方式で追加することができます。(https://user:password@host/...
のようにリポジトリのURIの中でパスワードで保護されたリポジトリのために証明書を提供することができることに注意してください。このやり方で証明書を提供する場合には注意してください。) これらのコマンドはSparkパッケージを含むために pyspark
, spark-shell
と spark-submit
と一緒に使うことができます。
Pythonでは、.egg
, .zip
および .py
ライブラリをexecutorに分配するために、等価な --py-files
オプションを使うことができます。
更なる情報
アプリケーションを一旦デプロイすると、分散化処理で必要とされるコンポーネントと、どうやってアプリケーションを監視およびデバッグするかについて、クラスタモードの概要で説明します。