制御HiveでのMapとreduceの数

4454 ワード

一、制御Hive中のMapとreduceの数量
Hiveのsqlクエリは実行計画を生成し、実行計画がMapReduceで実行されると、データとクラスタのサイズを組み合わせるとmapとreduceの数がsql実行の効率に影響します.
Hiveが生成するJobの数だけでなくmapとreduceの数も制御する.
1、mapの数、通常splitの大きさと関係があり、前に書いたblog「mapとreduceの数がどのように定義されているか」について説明します.
hiveでデフォルトのhive.input.formatはorg.apache.hadoop.hive.ql.io.CombineHiveInputFormat,combineHiveInputFormat,その入力map数
3つの構成によって決定され、
mapred.min.split.size.per.Node、1つのノード上のsplitの少なくともサイズ
mapred.min.split.size.per.rack 1つのスイッチの下でsplitの少なくともサイズ
mapred.max.split.size split最大サイズ
その主な考え方は入力ディレクトリの下の大きいファイルを複数のmapの入力に分けて、そして小さいファイルを合併して、1つのmapの入力とすることです.具体的な原理は以下の3つのステップである.
a、入力ディレクトリの下の各ファイルに基づいて、その長さがmapredを超える場合.max.split.sizeは、block単位で複数のsplit(1つのsplitはmapの入力)に分けられ、各splitの長さはmapredより大きい.max.split.size、block単位なのでblockSizeよりも大きくなり、このファイルの残りの長さがmapredより大きい場合.min.split.size.per.nodeは、splitを生成する、そうでなければ一時的に保持する.
b、今残っているのは長さの短い破片で、各rackの下の破片を合わせて、長さがmapredを超える限り.max.split.sizeはsplitに結合し、最後に残りの破片がmapred.min.split.size.per.rackが大きい場合はsplitにマージし、そうでなければ一時的に保持する.
c、異なるrackの下の破片を合併し、長さがmapredを超える限り.max.split.sizeはsplitに結合し、残りの破片は長さにかかわらずsplitに結合する.
例:mapred.max.split.size=1000
mapred.min.split.size.per.node=300
mapred.min.split.size.per.rack=100
ディレクトリの下の5つのファイル、rack 1の下の3つのファイルを入力、長さは20501499、10、rack 2の下の2つのファイル、長さは1010、80である.またblockSizeは500である.
第1ステップを経て、5つのsplit:1000001000491000を生成する.残りの破片はrack 1下:50,10;rack 2下10:80
2つのrackの下の破片は100を超えないため、第2のステップを経てsplitも破片も変化しなかった.
第3のステップでは、4つの破片を1つのsplitに結合し、長さは150である.
mapの数を減らすにはmapredを大きくすることができます.max.split.size、そうでなければ小さくすればいい.
その特徴は:1つのブロックは1つのmapの入力として多く、1つのファイルは複数のブロックがある可能性があり、1つのファイルはブロックが異なるmapの入力として多く分けられる可能性があり、1つのmapは複数のブロックを処理する可能性があり、複数のファイルを処理する可能性がある.
2、reduce数量
hiveがsqlを実行するときに、次のように印刷できます.
Number of reduce tasks not specified. Estimated from input data size: 1 In order to change the average load for a reducer (in bytes): set hive.exec.reducers.bytes.per.reducer= In order to limit the maximum number of reducers: set hive.exec.reducers.max= In order to set a constant number of reducers: set mapred.reduce.tasks=
reduce数は、以下の3つのパラメータによって決定する、mapred.reduce.tasks(reduceのタスク数を強制的に指定)
hive.exec.reducers.bytes.per.reducer(reduceタスクごとに処理されるデータ量、デフォルトは1000^3=1 G)
hive.exec.reducers.max(各タスクの最大reduce数、デフォルトは999)
reducer数の計算式は簡単N=min(hive.exec.reducers.max、総入力データ量/hive.exec.reducers.bytes.per.reducer)
reduceのシーンは1つしかありません:a、group byの要約bがなくて、order by c、デカルト積
二、joinとGroupの最適化普通のjoin操作に対して、map端でkeyのhash値に基づいて、shuffleはあるreduceに行って、reduce端でjoin接続操作をして、メモリの中でjoin左の表をキャッシュして、右の表を遍歴して、一回join操作をします.だからjoin操作をするときは、データ量の多いテーブルをjoinの右側に置きます.データ量が比較的大きく,key分布が不均一であると,大量のkeyが1つのreduceにshuffleし,データの傾斜が現れた.
     Group  ,   map   ,   reduce    ,hive      ,        
     · hive.map.aggr = true    Map      ,    True
    · hive.groupby.mapaggr.checkinterval = 100000  Map             


     join Group            。
                    
  1、  hive.groupby.skewindata = true,           ,         MR Job。    MR Job  ,Map               Reduce  ,   Reduce        ,     ,            Group By Key            Reduce  ,           ;    MR Job               Group By Key     Reduce  (            Group By Key         Reduce  ),           。
  2、where     join  ,    join   (  map   ,        )
  3、mapjoin  , reduce  , map  join  (map cache       ),         Full/RIGHT OUTER join  
  4、  count(distinct)  , map  group by    count       key,        key,            
  5、        ,   join  key     ,  key hash   reduce   ,      ,     key    key   
       key  join  。

もちろんhive操作では、データの傾きの問題はありません.例えば、sum、countのようなデータ集約クラスの操作は、map側で集約操作を行っているので、reduce側までのデータは相対的に少ないので、この問題はありません.
四、小ファイルの合併大量の小ファイルはファイル数が多すぎて、HDFSに圧力をもたらし、hive処理の効率に大きな影響を及ぼし、mapとreduceで発生したファイル・hiveを合併することができる.merge.mapfiles=trueとMapがファイルを出力するかどうか、デフォルトはTrue・hiveです.merge.mapredfiles=falseがReduce出力ファイルをマージするかどうか、デフォルトはFalse・hive.merge.size.per.task=256*1000*1000マージファイルのサイズ
五、in/exists(not)left semi joinによってin操作を実現し、一つの制限はjoinの右側の表がjoin条件にしか現れないことである.
六、パーティションの切り抜き条件にパーティションを指定することで、データスキャンの範囲を制限し、クエリーの効率を極めて高めることができる
七、ソートorder byソートは、reduceが1つしか存在しないため、効率が低い.sort byで操作できます.通常はdistribute byと組み合わせてreduceパーティションキーとして使用されます.http://blog.csdn.net/zhong_han_jun/article/details/50814246 http://blog.csdn.net/michael_zhu_2004/article/details/8284089 https://www.cnblogs.com/xiohao/p/6404042.html?utm_source=itdadao&utm_medium=referral