Hive数据倾斜及调优

Hive中的数据倾斜和优化
常见的优化
1大表转化为小表，充分利用临时表
合理的利用分区表+外部表
数据存储格式，压缩的配置
SQL语句的优化 join---尽量使用map join
 filter 先过滤再处理

开启并行
hive.exec.parallel  ->修改为true,开启并行
hive.exec.parallel.thread.number 设置并行的个数

开启JVM重用,调整为合理的值，看有多少Task
hive> set parquet.compression=SNAPPY;
hive> set mapreduce.job.jvm.numtasks=100;

map和reduce的个数
map的个数；默认一个文件块一个maptask
          min(split.size.max, max(block_size, split.size.min)) 
          通过更改分片的大小来修改map task的个数，不能修改block_size
reduce的个数:
    （0.95至1.75）*节点数量*每个节点的最大容器数
    工作中：进行合理的采样，设置reduce的个数
开启推测执行：可能会有资源的阻塞，如果资源问题，就不要开启
    mapreduce中 mapreduce.map.speculative和mapreduce.reduce.speculative 设置为true
    hive.mapred.reduce.tasks.speculative.execution ->true

启动hive的本地模式
    select count(1) from log_test; //提交到集群中运行
    hive.exec.mode.local.auto ->true
    开启本地模式后，符合条件的job会只在当前节点执行，不会提交到集群
    条件：1输入的数据不能大于128M   2map的个数必须<4,reduce的个数最多只能有一个
    hive > set hive.exec.mode.local.auto=true;
        

Hive中的数据倾斜
概念: 表示在处理大量的数据的过程中其中某一个值过多，导致某些task的任务迟迟不能完成，影响整个job的运行
一系列的key: A A A A A B C 
reduce: 1 2 3 
5个A都到了1 ； B到了2； C到了3，这叫数据倾斜，
产生原因： 1 join产生 2 group by产生 distinct 

Join:
1 map join:适合小表与大表的join。好处：小表会被导入内存，与大表进行join
    使用方式，第一种 hive.auto.convert.join =true
                hive.mapjoin.smalltable.filesize 例如25000000判断小表的条件
                如果hive判断符合小表的条件则自动使用map join
            第二种,指定一张表为小表，进行map join
                  /*+MapJOIN(tablename)*/
2 reduce join:适用大表join大表,效率比较低
3 SMB join: sort merge bulked 叫做排序合并，适合于大表join大表
A:1 2 3 .。。100    例如 1桶 1-25   ；2桶 26- 50  3桶 51-75 4桶 76-100
B:1 2 3 .。。100    例如 1桶 1-25   ；2桶 26- 50  3桶 51-75 4桶 76-100
这时候会给他一个分桶, 通过key的hash值取余的方式，决定某条记录放入哪个桶
要求：B的桶的个数必须是A桶个数的倍数
hive.auato.convert.sortmerge.join=true
这样将A和B进行了拆分

工作中尽量使用map join和SMB join

二group by(distinct)造成的数据倾斜
hive.map.aggr =true 默认为true，实际开启了map端的combiner,提前进行了一次聚合
hive.groupby.skewindata=true //默认false，需要手动开启，在reduce进行分区的时候，不按照hash取余的方式进行分区，而是随机分区
随机分区进行一次处理聚合，再启动一个MapReduce进行一次处理
数据倾斜产生的原因：http://www.cnblogs.com/ggjucheng/archive/2013/01/03/2842860.html
select /*+mapjoin(x)*/* from log a
  left outer join (
    select  /*+mapjoin(c)*/d.*
      from ( select distinct user_id from log ) c
      join users d
      on c.user_id = d.user_id
    ) x
  on a.user_id = b.user_id;

使map的输出数据更均匀的分布到reduce中去，是我们的最终目标。由于Hash算法的局限性，按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤：
1、采样log表，哪些user_id比较倾斜，得到一个结果表tmp1。由于对计算框架来说，所有的数据过来，他都是不知道数据分布情况的，所以采样是并不可少的。
2、数据的分布符合社会学统计规则，贫富不均。倾斜的key不会太多，就像一个社会的富人不多，奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。
3、map读入users和log，假如记录来自log,则检查user_id是否在tmp2里，如果是，输出到本地文件a,否则生成<user_id,value>的key,value对，假如记录来自member,生成<user_id,value>的key,value对，进入reduce阶段。
4、最终把a文件，把Stage3 reduce阶段输出的文件合并起写到hdfs。

如果确认业务需要这样倾斜的逻辑，考虑以下的优化方案：
1、对于join，在判断小表不大于1G的情况下，使用map join
2、对于group by或distinct，设定 hive.groupby.skewindata=true
3、尽量使用上述的SQL语句调节进行优化