[解決済み] sparkのexecutor数、cores、executor memoryのチューニング方法は？

質問

上記のパラメータをチューニングするには、どこから始めればよいのでしょうか。実行者メモリから始めて実行者数を得るのでしょうか、それともコアから始めて実行者数を得るのでしょうか。私は リンク . しかし、高レベルのアイデアを得たが、まだどのように、またはどこから始め、最終的な結論に到達するかがわからない。

どのように解決するのですか？

以下の回答は、タイトルにある3つの主要な側面、すなわち、エグゼキュータ数、エグゼキュータメモリ、コア数、をカバーしています。ドライバメモリやその他のパラメータについては、この回答では触れていませんが、近い将来に追加したいと思います。

ケース 1 ハードウェア - 6 ノード、および各ノード 16 コア、64 GB RAM

各エクゼキュータは、JVMインスタンスです。そのため、1つのノードで複数のエグゼキュータを持つことができます。

まずOSとHadoopデーモンに1コアと1GBが必要なので、各ノードには15コア、63GBのRAMが利用可能です。

まずコア数の選び方から :

Number of cores = Concurrent tasks as executor can run 

So we might think, more concurrent tasks for each executor will give better performance. But research shows that
any application with more than 5 concurrent tasks, would lead to bad show. So stick this to 5.

This number came from the ability of executor and not from how many cores a system has. So the number 5 stays same
even if you have double(32) cores in the CPU.

実行者の数。

Coming back to next step, with 5 as cores per executor, and 15 as total available cores in one Node(CPU) - we come to 
3 executors per node.

So with 6 nodes, and 3 executors per node - we get 18 executors. Out of 18 we need 1 executor (java process) for AM in YARN we get 17 executors

This 17 is the number we give to spark using --num-executors while running from spark-submit shell command

各エクゼキュータ用のメモリ。

From above step, we have 3 executors  per node. And available RAM is 63 GB

So memory for each executor is 63/3 = 21GB. 

However small overhead memory is also needed to determine the full memory request to YARN for each executor.
Formula for that over head is max(384, .07 * spark.executor.memory)

Calculating that overhead - .07 * 21 (Here 21 is calculated as above 63/3)
                            = 1.47

Since 1.47 GB > 384 MB, the over head is 1.47.
Take the above from each 21 above => 21 - 1.47 ~ 19 GB

So executor memory - 19 GB

最終的な数値 - エグゼキュータ - 17、コア - 5、エグゼキュータメモリ - 19 GB

ケース2 ハードウエア : 同 6ノード、32コア、64GB

5は並行性が良いので同じ

各ノードのエグゼキュータ数 = 32/5 ~ 6

つまり、総実行者数 = 6 * 6ノード = 36。とすると、最終的な数は36 - AMの1 = 35となります。

エクゼキュータのメモリは、各ノードにつき6個です。63/6 ~ 10 . オーバーヘッドは0.07 * 10 = 700 MBです。従って、1GBに丸めると、10-1 = 9 GBとなります。

最終的な数値 - エグゼキュータ - 35、コア - 5、エグゼキュータメモリ - 9 GB

ケース3

上記のシナリオは、コア数を固定とすることから始まり、エグゼキュータ数、メモリ数に移行していきます。

さて、最初のケースですが、19GBも必要ない、10GBで十分だと考えた場合、以下のようになります。

コア数 5 # 各ノードのエグゼキュータ数 = 3

この段階では、最初の計算と同じように21となり、次に19となるはずです。しかし、10 は大丈夫だと思ったので (オーバーヘッドが少ないと仮定して)、ノードあたりの実行者数を 6 に切り替えることはできません。 を6に変更することはできません（63/10のように）。というのも、16コアしかないのに、6コアにすると30コアになってしまうからです。そのため、各エクゼキュータのコア数を変更する必要があります。 コアを変更する必要があります。

というわけで、もう一度計算します。

マジックナンバー 5 は 3 になります (5以下の任意の数)。つまり、3 つのコアと 15 個の利用可能なコアで、1 ノードあたり 5 つのエグゼキュータが得られます。つまり、(5*6 -1) = 29 エグゼキュータとなります。

ということは、メモリは63/5 ~ 12。オーバーヘッドは 12*.07=.84 ということは、エクゼキュータのメモリは12 - 1 GB = 11 GBとなります。

最終的な数値は、29 executor, 3 core, executor memory is 11 GBです。

ダイナミック・アロケーション。

注：動的割り当てが有効な場合の実行者数の上限です。つまり、スパークアプリケーションは必要であればすべてのリソースを食い尽くすことができるということです。つまり 他のアプリケーションが動作しているクラスタでは、タスクを実行するためにコアが必要です。つまり、YARに特定のコア数を割り当てることができます。 ユーザーアクセスに基づいてYARNに特定のコア数を割り当てることができます。つまり、spark_userを作成し、そのユーザーに対してコア数（最小/最大）を割り当てることができます。この制限は、sparkとYARN上で動作する他のアプリケーションの間で共有するためのものです。

spark.dynamicAllocation.enabled - これがtrueに設定されている場合 - エグゼキュータについて言及する必要はありません。理由は以下の通りです。

spark-submitで与える静的なパラメータ数は、ジョブ期間全体に対するものです。しかし、ダイナミックアロケーションが登場した場合、次のような異なるステージが存在することでしょう。

何から始めるか:

最初の実行者数 ( spark.dynamicAllocation.initialExecutors )で開始します。

何個:

次に、負荷（保留中のタスク）に基づき、いくつリクエストするか。これは最終的にspark-submitで静的な方法で与える数字になります。というわけで、最初の実行者数が決まったら、次はmin( spark.dynamicAllocation.minExecutors ) と max ( spark.dynamicAllocation.maxExecutors（スパークダイナミックアロケーションマックスエグゼキュータ ) の数値が必要です。

尋ねるとき、与えるとき。

いつ新しい実行者を依頼するか ( spark.dynamicAllocation.schedulerBacklogTimeout ) - これだけの期間、保留中のタスクがあるので、リクエストします。各ラウンドでリクエストされるエグゼキュータの数は、前のラウンドから指数関数的に増加します。例えば、アプリケーションは最初のラウンドで1つのエグゼキュータを追加し、その後のラウンドで2、4、8...とエグゼキュータを追加していきます。特定の時点で、上記の最大値が表示されます。

いつエクゼキュータを手放すか ( spark.dynamicAllocation.executorIdleTimeout ) -

私が何かを見逃しているならば、私を修正してください。上記は、私が質問で共有したブログといくつかのオンラインリソースに基づいた私の理解です。ありがとうございます。

参考文献。

• http://site.clairvoyantsoft.com/understanding-resource-allocation-configurations-spark-application/
• http://spark.apache.org/docs/latest/configuration.html#dynamic-allocation
• http://spark.apache.org/docs/latest/job-scheduling.html#resource-allocation-policy