3

異なるクライアントサーバーから大量のHadoopジョブを送信する場合でも、同じサーバーからすべて送信する場合でも、リソースに測定可能な影響はありますか？すべての作業がクラスターで行われるので、私はそうは思わないでしょう。これは正しいです？

4

3 に答える 3

6

Hadoop クラスターに送信するクライアントでリソースを集中的に使用するのは、入力分割の計算だけです。入力データが膨大な場合、または同じクライアントから送信されるジョブが多すぎる場合、入力分割の計算が原因で、ジョブの送信が少し遅くなることがあります。

Hadoop のリリースやパラメーターを思い出すことはできませんが、ジョブを送信するクライアントから Hadoop クラスターに入力分割の計算を移動するための構成可能なパラメーターが含まれていました。

于 2013-01-21T01:06:34.197 に答える
3

どこからジョブを送信するかは問題ではありません。クライアント自体は多くのことを行うわけではありません。RPC プロトコルを使用してサービスに接続し、ジョブが完了するまでアイドル状態になります。

また、最も重要なのは、リソースの割り当てに使用するスケジューラーの種類です。これはおそらく最も重要な違いを生み、どのリソースをどのジョブに割り当てるかを決定します。ジョブ スケジューリングの詳細については、こちらをご覧ください。

于 2013-01-20T05:48:07.900 に答える
1

「クラシック」バージョンでは、入力分割計算を Job Tracker に移動できないと思います。YARNでは、次を使用して移動できます

「yarn.app.mapreduce.am.compute-splits-in-cluster」

おそらく、Hadoop のユーザーは、ジョブ トラッカーに入力分割の作成で過負荷をかけたくなかったのでしょう。HDFS の Namenode にあまり多くの作業を割り当てないという設計上の決定に似ています。

YARN では、すべてのジョブが独自の Application Master を取得するため、ジョブ トラッカーのような SPOF/ボトルネック マスターの過負荷について心配する必要はありません。

元の質問を参照すると、クライアント ジョブは、ブロックの場所を取得するために namenode にアクセスする必要があります (ブロック ストレージ クラスのコードの一部がメタ データのデータ ノードを呼び出しているのを見たことがあります...これらが実行中に発生するかどうかはわかりません)。入力分割の作成またはタスク トラッカー ノードで) 。これは、同じクライアント ノードで多くのジョブを処理している場合に問題になる可能性があります。YARN を使用している場合、これらすべての通信がクラスター内で行われると、パフォーマンスがわずかに向上します。

Oozie がこの問題をどのように処理しているかを確認する必要があります。

うまくいけば、これは役に立ちます！アルン

于 2014-02-27T16:52:47.377 に答える