0

スパーククラスターをセットアップしています。同じインスタンスに hdfs データ ノードとスパーク マスター ノードがあります。

現在のセットアップは 1 マスター (spark と hdfs) 6 スパーク ワーカーと hdfs データ ノードです。

すべてのインスタンスは同じで、16 ギガのデュアル コアです (残念ながら)。

もう 3 台のマシンがありますが、これも同じ仕様です。ここで、3 つのオプションがあります。1. これら 3 台のマシンに es を展開するだけです。クラスターは、1 つのマスター (spark と hdfs)、6 つの Spark ワーカー、hdfs データ ノード、3 つの Elasticsearch ノードのようになります。

  1. es master を 1 に展開し、spark と hdfs を拡張し、その他すべてに es を展開します。クラスターは 1 マスター (spark と hdfs) 1 マスター エラスティックサーチ 8 スパーク ワーカー、hdfs データ ノード、es データ ノードのようになります

私のアプリケーションは、結合、ml などに spark を多用していますが、検索機能を探しています。リアルタイムで検索する必要はなく、最大 30 分の更新間隔でも問題ありません。

同時に、spark クラスターには、es インデックス作成以外の長時間実行されるタスクがあります。

解決策は上記のいずれかである必要はありません。誰かが提案した場合、私は実験にオープンです。他の開発者にとっても、一度結論を下すと便利です。

また、私は es hadoop、es-spark プロジェクトを試していますが、3 つの専用ノードを実行すると、1 分あたり 60 万レコードのように取り込みが非常に遅いと感じました。

4

1 に答える 1

0

ここでの最適なアプローチは、主にネットワーク帯域幅と、それが運用のボトルネックであるかどうかに依存します。

ネットワークリンクが飽和しているかどうかを say iftop -i anyまたは同様の方法で確認し、そうであるかどうかを確認します。ネットワークの物理容量に近いデータ レートが表示される場合は、ES を実行している同じマシンで hdfs + spark を実行して、ネットワークの往復を節約し、速度を上げることができます。

ここでネットワークがボトルネックではないことが判明した場合は、次に Spark と HDFS をデプロイする方法を検討します。使用可能なすべての RAM を使用していますか (Java Xmx は十分に高く設定されていますか?Spark のメモリ制限は?Spark が Yarn を介してデプロイされている場合は Yarn のメモリ制限はありますか?)

また、ここで ES または Spark がボトルネックであるかどうかを確認する必要があります。おそらくそれは ES です。追加の ES インスタンスを生成することもできますが、3 つの ES ノードで 6 つの Spark ワーカーに供給することは、最適とは言えません。どちらかといえば、私はおそらくその比率を逆にして、Spark エグゼキューターを減らし、ES 容量を増やすことを試みるでしょう。ES は、HDFS がデータを書き込むよりも、データを提供する方がはるかに遅い可能性があります (ただし、これは実際には両方の構成に依存します... ここでは知識に基づいた推測にすぎません :))。ここでは、より多くの ES ノードとより少ない Spark ワーカーがより良いアプローチになる可能性が非常に高くなります。

つまり、一言で言えば：

  • ES ノードを追加し、Spark ワーカー数を減らす
  • ネットワーク リンクが飽和しているかどうかを確認します。飽和している場合は、両方を同じマシンに配置します (これは 2 つのコアのみでは有害になる可能性がありますが、それでも試してみたいと思います...これを試してみる必要があります)。
  • ESノードを追加することは、あなたができる2つのことのより良い賭けです:)
于 2016-12-22T17:52:56.227 に答える