3

この他の質問のコンテキストでhere

hive.exec.reducers.max ディレクティブを使用すると、本当に困惑しました。

私の観点からは、ハイブはある種のロジックで機能すると思いました。たとえば、目的のクエリに N # 個のブロックがあるため、N 個のマップが必要です。NI からは、R = N / 2 から R = 1 までの範囲のリデューサー R の適切な範囲が必要になります。合計で 70 個のリデューサーしかないクラスターで作業していたことを除いて、これは問題ありませんでした。公平なジョブスケジューラを使用しても、これによりバックログが発生し、他のジョブがハングアップしました。そのため、hive.exec.reducers.max を見つけて 60 などに設定するまで、さまざまな実験を試みました。

その結果、248 分かかったハイブ ジョブが 155 分で終了し、結果に変化はありませんでした。私が気になっているのは、ハイブのデフォルトを N にして、クラスターのリデューサー容量よりも大きくならないようにして、リデューサーのセットを減らして数テラバイトのデータをロールオーバーできることを確認してから、ハイブが正しいと思うことです。常に試したほうがよいですかこのカウントを微調整しますか？

4

2 に答える 2

2

ハイブでの私の経験では、mapred.job.reuse.jvm.num.tasks を健全な数 (私の場合は 8) に設定すると、これらのアドホック クエリの多くに役立ちます。JVM のスポーンには約 20 ～ 30 秒かかるため、寿命が短い (< 30 秒) マッパーとリデューサーでは、再利用がかなり役立ちます。

于 2011-02-24T14:41:18.117 に答える
2

(スロット数の最適化について説明しています) を参照してください: http://wiki.apache.org/hadoop/LimitingTaskSlotUsage

同じことについての私の意見は次のとおりです。

1) Hive は、map タスクの後に生成されると予想されるデータ量に基づいて、Reducer の数を最適化しようとするのが理想的です。基礎となるクラスターが同じものをサポートするように構成されていることが期待されます。

2) このカウントを微調整するのが得策ではないかどうかについて:

  • まず、実行時間が 248 分から 155 分に短縮された理由を分析してみましょう。

ケース 1: Hive が 400 のレデューサーを使用している 問題: 特定の時点で実行できるレデューサーは 70 のみです。

  • JVM の再利用がないことを前提としています。JVM を何度も作成すると、大きなオーバーヘッドが追加されます。

  • これについては不明です。400 個のレデューサーを期待すると、断片化などの問題が発生します。たとえば、70 個のレデューサーしか実行できないことがわかっている場合、中間ファイルの保存戦略はそれに依存します。しかし、400 個のレデューサーを使用すると、戦略全体が台無しになります。

ケース 2: ハイブは 70 のレデューサーを使用しています - この数を設定することで両方の問題に対処できます。

利用可能な最大レデューサーの数を設定する方が良いと思います。しかし、私はこれについて専門家ではありません。これについて専門家にコメントしてもらいます。

于 2011-02-18T09:40:23.850 に答える