数据倾斜解决方案

数据倾斜定义

简单的讲，数据倾斜就是我们在数据计算的时候，由于数据的分散度不够，导致大量的数据集中到了一台或者几台机器上计算，这些机器的计算速度远远低于整个集群的平均计算速度，导致整个计算过程十分缓慢。

常见数据倾斜现象

数据倾斜往往会发生在数据开发的各个环节中，比如：
用Hive数据计算的时候reduce阶段卡在99.99%
用SparkStreaming做实时算法的时候，一直会有executor出现OOM的错误，但是其余的executor内存使用率却很低。
Hadoop中的数据倾斜主要表现在ruduce阶段卡在99.99%，一直99.99%不能结束。
这里如果详细看日志或者监控界面的话会发现：
有一个或几个reduce卡住
各种container报错OOM（内存溢出）
读写的数据量极大，至少远远超过其它正常的reduce
伴随着数据倾斜，会出现任务被kill等各种诡异的表现。
经验：Hive的数据倾斜，一般都发生在Sql中Group和On上，而且和数据逻辑绑定比较深。

产生的原因

以hive为例，我们在做数据运算的时候，往往会涉及到count distinct、group by、join等操作，这些都会触发Shuffle动作，一旦触发，所有相同key的值就会拉到一个或几个节点上，就容易发生单点问题，造成数据倾斜。

如何解决

举一个例子：
比如就说订单场景吧，我们在某一天在北京和上海两个城市多了强力的推广，结果可能是这两个城市的订单量增长了10000%，其余城市的数据量不变。
然后我们要统计不同城市的订单情况，这样，一做group操作，可能直接就数据倾斜了。
解决数据倾斜有这几个思路：
（1）业务逻辑，我们从业务逻辑的层面上来优化数据倾斜，比如上面的例子，我们单独对这两个城市来做count，最后和其它城市做整合。
（2）调参方面，Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜，合理利用它们就能解决大部分问题。如：
在hive中，通过设置hive.groupby.skewindata=true来自动进行负载均衡。
如：select count(distinct uid) from XXX group by XXX,当选项设定为 true，生成的查询计划会有两个 Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group ByKey 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce中），最后完成最终的聚合操作。
但是，当选项设定为 true时，hive不支持多列上的去重操作，如以下会报错：
SELECT ip, count(DISTINCTuid), count(DISTINCT uname) FROMlog GROUP BY ip；
（3）程序层面
1、比如说在Hive中，经常遇到count（distinct）操作，distinct会导致group by无法在map阶段做一次聚合操作，导致数据在传输到reduce端时，数据量未能减少，reduce如果需要处理的数据量太大，就会导致整个Job很难完成，我们可以先group 再在外面包一层count，就可以了。
如：
SELECT day, COUNT(DISTINCT id) AS uvFROM lxw1234GROUP BY day;
可以转换成：
SELECT day, COUNT(id) AS uvFROM (SELECT day,id FROM lxw1234 GROUP BY day,id) aGROUP BY day;

2、MapJoin：当大表关联一个小表时，容易发生数据倾斜，通过MapJoin把小表数据全部加载到内存在map端进行join，避免reducer处理。
如：
select c.channel_name,count(t.requesturl) PV
from ods.cms_channel c
join (select host,requesturl from dms.tracklog_5min where day=‘20151111’ ) t
on c.channel_name=t.host
group by c.channel_name
order by c.channel_name;
以上为小表join大表的操作，可以使用mapjoin把小表放到内存中处理，语法很简单只需要增加 /*+ MAPJOIN(pt) / ，把需要分发的表放入到内存中
select /+ MAPJOIN© */
c.channel_name,count(t.requesturl) PV
from ods.cms_channel c
join
(select host,requesturl from dms.tracklog_5min where day=‘20151111’ ) t
on c.channel_name=t.host
group by c.channel_name
order by c.channel_name;
在Hive0.11后，Hive默认启动该优化，也就是不在需要显示的使用MAPJOIN标记，其会在必要的时候触发该优化操作将普通JOIN转换成MapJoin，可以通过以下两个属性来设置该优化的触发时机
hive.auto.convert.join
默认值为true，自动开户MAPJOIN优化
hive.mapjoin.smalltable.filesize
默认值为2500000(25M),通过配置该属性来确定使用该优化的表的大小，如果表的大小小于此值就会被加载进内存中
注意：使用默认启动该优化的方式如果出现默名奇妙的BUG(比如MAPJOIN并不起作用),就将以下两个属性置为fase手动使用MAPJOIN标记来启动该优化
hive.auto.convert.join=false(关闭自动MAPJOIN转换操作)
hive.ignore.mapjoin.hint=false(不忽略MAPJOIN标记)
3、大表Join大表
把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果。
4、group by维度过小：
采用sum() group by的方式来替换count(distinct)完成计算。
5、特殊情况特殊处理：
在业务逻辑优化效果的不大情况下，有些时候是可以将倾斜的数据单独拿出来处理。最后union回去。

典型的业务场景

1、空值产生的数据倾斜
场景：如日志中，常会有信息丢失的问题，比如日志中的 user_id，如果取其中的 user_id 和 用户表中的user_id 关联，会碰到数据倾斜的问题。
解决方法1： user_id为空的不参与关联
select * from log a
join users b
on a.user_id is not null
and a.user_id = b.user_id
union all
select * from log a
where a.user_id is null;

解决方法2 ：赋与空值分新的key值
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;
结论：方法2比方法1效率更好，不但io少了，而且作业数也少了。解决方法1中 log读取两次，jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数，就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。
2、不同数据类型关联产生数据倾斜
场景：用户表中user_id字段为int，log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时，默认的Hash操作会按int型的id来进行分配，这样会导致所有string类型id的记录都分配到一个Reducer中。
解决方法：把数字类型转换成字符串类型
select * from users a
left outer join logs b
on a.usr_id = cast(b.user_id as string)
3、小表不小不大，怎么用 map join 解决倾斜问题
使用 map join 解决小表(记录数少)关联大表的数据倾斜问题，这个方法使用的频率非常高，但如果小表很大，大到map join会出现bug或异常，这时就需要特别的处理。 以下例子:
select * from log a
left outer join users b
on a.user_id = b.user_id;
users 表有 600w+ 的记录，把 users 分发到所有的 map 上也是个不小的开销，而且 map join 不支持这么大的小表。如果用普通的 join，又会碰到数据倾斜的问题。
解决方法：
select /+mapjoin(x)/* from log a
left outer join (
select /+mapjoin©/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;

假如，log里user_id有上百万个，这就又回到原来map join问题。所幸，每日的会员uv不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。

总结

使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语句调节进行优化

感谢coderblack指点