スパーククラスタは小さなデータに拡張されません

Question

私は現在、線形回帰（Spark ML）のベンチマークを持つ小さなクラスタ（3つのノードが32のCPUと128 GBのRAM）でSpark 2.1.0を評価しています。私はパラメータ計算（開始、データロードなどを含まない）の時間を測定し、以下の動作を認識しました。小さなデータセット0.1 Mio - 3 Mioデータポイントの場合、測定時間は実際には増加しておらず、約40秒にとどまります。 300 Mioデータポイントのような大きなデータセットでのみ、処理時間は最大200秒になりました。だから、クラスタは小さなデータセットにまったくスケールされていないようです。

ローカルPCの小さなデータセットと、10人の作業者と16GBのRAMしか使用していないクラスターを比較しました。クラスタの処理時間は3分の1になります。これはSPARKの通常の動作と考えられ、通信オーバヘッドで説明できますか何か間違っていますか（実際には代表的な線形回帰ですか）？

クラスタはスタンドアロンクラスタ（YarnまたはMesosなし）であり、ベンチマークは90人の従業員とともに提出され、それぞれ1コアと4 GBのラムがあります。

スパークは提出： ./spark-submit --masterスパーク：//サーバー：7077 --classベンチマーク--deployモードクライアント--total - エグゼキュータ・コア90 --executor・メモリの4Gを - num executor 90 .../Benchmark.jar pathToData

Answer 1

最適なクラスタサイズと構成は、データとジョブの性質によって異なります。この場合、あなたの直感は正しいと思います。クラスター（コアとエグゼキュータ）のサイズを考えれば、過剰なオーバーヘッドがあるため、ジョブは小さなデータセットで完了するのに時間がかかりすぎるようです。

データ量を2桁増加させると、処理時間がわずか5倍に増加することに注意してください。クラスタ設定に最適なサイズにデータを増やしています。

スパークは大量のデータを処理するための優れたツールですが、データが収まる場合は1台のマシンで1つのプロセスを実行することで競合することはありません。ただし、データが1台のマシンに収まらないディスクベースの分散処理ツールよりもはるかに高速です。

私は数年前に話をしていましたが、Sparkは自転車レースのようなものであるとのアナロジーを示しました。重い荷物の場合、機関車は速度を上げるのに時間がかかるかもしれませんが、最終的には速くなります。 （私はスピーカーの名前を忘れてしまうのではないかと心配していますが、それはロンドンのカサンドラ会合であり、スピーカーはエネルギー部門の会社からのものでした）。

Answer 2

@ ImDarrenGの評価と、一般的に機関車/自転車の類推に同意します。このようなデータの少量

、私は強くあなたが300Mような何かをする必要がある場合は特に（各ノードにデータセットをブロードキャストし、データセット全体と

B）をキャッシュする）

Aをお勧めします

もう1つの考慮すべき点は、ファイルの数（まだキャッシュされていない場合）です.1つの分割できないファイルを読み込んでいる場合、1つのコアだけがそのファイルを読み込みます。しかし、一度データセットをキャッシュすると（合体または適切に再分割すると）、パフォーマンスは低下しませんongerはディスクにバインドされ、行をシリアライズします。