TEZ mapreduce ジョブで奇妙な動作が発生します。
Hive からログ データを読み取り、ID、日付、その他のパラメーターでいくつかのチャンクに分割してから、別の Hive テーブルに書き込もうとしています。
マップ フェーズは十分に速く動作し、レデューサーが動作を開始し、458 のレデューサーから 453 のレデューサーが次の 20 分以内にすべてのデータを処理するまでに約 20 分かかります。ただし、最後の 5 つのレデューサーは約 1 時間動作します。
これは、入力データに巨大なエントリが含まれており、これらのエントリの処理に時間がかかるために発生します。そのような場合のベストプラクティスは何ですか? 最後のレデューサーの一種の並列処理を可能にするために、hadoop/tez/hive のチューニングを行う必要がありますか?それとも、入力データを他のパラメーターで分割して巨大なエントリを回避する方が賢明でしょうか?
アドバイスをありがとう。
そのそれほど奇妙ではない動作の背後にある魔法の言葉は、skewです。そして、それは非常に一般的な問題です。通常、人々は問題を無視することを好みます...彼らが本当に痛みを感じるまで（あなたが今そうしているように）.
TEZ を使用すると、HIVE-7158 Use Tez autoparallelism in Hiveから、いくつかの特定のプロパティをいじることができます。
hive.tez.auto.reducer.parallelism
hive.tez.max.partition.factor
hive.tez.min.partition.factor
しかし、その「自動並列処理」機能は、マージ可能な異常に小さい縮小データセットがいくつかある場合に適用されるようですが、問題は正反対です(1つの異常に大きい縮小データセット)。だから、あなたもいじってみる必要があります
hive.exec.reducers.bytes.per.reducer
hive.exec.reducers.max
...スケールを変更して、「大」を新しい「通常」にします (したがって、「通常」が「小」になります)。しかし、そうすると、3 つのレデューサーをすべて完了するのに 1 時間かかるだけになるかもしれません。言いにくい。
幸運を。この種のパフォーマンス チューニングは、科学というより芸術です。
参照 ：
~~~~~~
PS:もちろん、入力データセットの編成方法を変更して歪みの原因を取り除くことができれば...