原因データが生成されたスキュー
原因データは、傾斜して多くの重合は、2つのカテゴリに参加斜めに傾いています
傾いた重合性基のハイブ傾き
- 理由：
- 小さな寸法を通るパケットは、各次元の値が一定値を低減消費長い処理時間をもたらす、過剰です。
- 他のデータ型のいくつかの種類に統計のいくつかの種類のデータ、特に大量の場合は極めて稀です。データによって基の種類に応じて行う場合、ノード重合を引くために、同じフィールドによって同じグループのために必要な作業を削減し、各グループのデータが大きすぎると、前記算出され、他のグループが存在することになります完了しており、これは、他のノードが完了すると、このノードのタスクの実行を待っている完成された計算を削減していない、我々は常にマップの例100％のreduce99の％が表示されます。
- ソリューション：
- 真のセットhive.map.aggr =;
- 真のセットhive.groupby.skewindata =;
- 原理：
- hive.map.aggr = trueこの構成では、重合マップの開放端部を表します。
- オプションがtrueに設定されている場合hive.groupby.skewindata =真、結果のクエリプランは、2つのMRジョブを持っています。第1のMRジョブは、地図の合成出力をランダム各重合操作に分配小さくすることで、DO部を減らし、その結果を出力します。この結果、負荷分散の目的を達成するように、可能性の高い別の削減に配布するグループ化キーと同じです。前処理の結果に応じて第2のMR仕事をし、データをグループ化キーの分布を低減するために、同じキーが同じを削減し、最終的には、最終的な重合操作を完了するために割り当てられているこのプロセス確実に。
地図の削減と最適化のハイブ傾き
- 1 - 理由：あまりにも多くの小さなファイルがある場合には、小さなファイルをマージする必要があります。= Trueの場合、セットhive.merge.mapredfilesによって解決することができます。
- 2-理由は：入力データチャンクとのような深刻な問題の小片がある：大型ファイル128M、1000個の小さなファイル、各1キロバイトです。対処方法：タスクの入力ファイルのマージを行う前に、一つの大きなファイルに多数の小さなファイルをマージします。セットhive.merge.mapredfiles =真を解くことにより、
- 3-理由：単一のファイルサイズマップの数を増加させる必要が適宜この時点で、ブロックのブロック構成のサイズよりもわずかに大きいです。解像度：セットmapred.map.tasksの数。
- 4 - 原因：適度な大きさが、非常に大規模なクライアントコンピューティングマップ、のような：。SELECT ID、COUNT（*）、合計（ケース...）、合計（ケース...）...マップを追加する必要があります番号。解像度：mapred.reduce.tasksの数を設定した設定mapred.map.tasksの数;
HQLハイブの傾きは、カウント（異なる）を含む場合
- データの量が非常に大きい場合、そのような選択Aの実装は、によって（異なるB）T基からカウント、タイプSQL、データに問題が傾斜されるとき。
- 回避策：代わりに使用することにより和...グループ。例えば：から、和（1）によってグループ（のTによる群、BからA、Bを選択）。
HQLのハイブ傾きは、最適化に参加します
- 大きなテーブルと小さなテーブルに直面したときの動作に参加します。使用mapjoin小さなテーブルがメモリにロードされます。例えば：a.c1 = b.c1 Bに参加から/ * + MAPJOIN（）* / a.c1、b.c1、b.c2を選択します。
- 参加必要遭遇するが、関連するデータフィールドには、会合の表II、表IDとIDのニーズのように、ヌルです。
- 解決方法1：IDがnullアソシエーションが参加していないです
など：
- 解決方法1：IDがnullアソシエーションが参加していないです
select * from log a
join users b
on a.id is not null and a.id = b.id union all select * from log a where a.id is null; - 解決策2：ランダムなキー値に割り当てられたNULL値
など、：
select * from log a
left outer join users b on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id; 合理的な数マップを設定
上記の概要説明
- 1）通常、ジョブは一つによって生成された以上のタスクは、入力されたディレクトリをマッピングします。
主な決定要因は次のとおりです：文書入力、入力ファイルのサイズ、クラスター・セットアップの総数のファイルのブロックサイズ。 - 2）マップは、より良い数値ではありませんか？
答えはノーです。タスクが（ブロックサイズよりはるかに小さい128M）多数の小さなファイルを持っている場合、各ファイルには、マップを完了するために、タスクと、小さなブロックとして扱われ、され、処理ロジックよりも有意に長いマップ初期化タスクが開始され、時間、それは資源の大きな無駄が発生します。また、実行可能なマップの数が制限されます。 - 3）各マップには、ほぼ128メートルファイルブロックのを扱わ後ろに座るとリラックスしていないことを確認してください？
答えは、必ずしもではありません。例えば、127メートルのファイルがあり、通常は完全にマップを使用しますが、ファイルは1つまたは2つだけの小さなフィールドがありますプロセスは、確かに、より複雑な論理マップ、実行するタスクとマップ、であれば、レコードの数千万人が、ありますまた、時間がかかります。 - 質問2と3以上の場合、我々は解決する2つの方法を取る必要があります。すなわち、マップの数を削減し、マップの数を増やすこと。