数据倾斜解决方案

数据倾斜定义

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

常见数据倾斜现象

数据倾斜往往会发生在数据开发的各个环节中，比如：
● 用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）程序层面，比如说在Hive中，经常遇到count（distinct）操作，distinct会导致group by无法在map阶段做一次聚合操作，导致数据在传输到reduce端时，数据量未能减少，reduce如果需要处理的数据量太大，就会导致整个Job很难完成，我们可以先group 再在外面包一层count，就可以了。
如：

SELECT day, COUNT(DISTINCT id) AS uv FROM lxw1234 GROUP BY day;

可以转换成：

SELECT day, COUNT(id) AS uv FROM (SELECT day,id FROM lxw1234 GROUP BY day,id)a GROUP BY day;

（3）调参方面，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；
（4）MapJoin：当大表关联一个小表时，容易发生数据倾斜，通过MapJoin把小表数据全部加载到内存在map端进行join，避免reducer处理。

参考资料：
https://segmentfault.com/a/1190000009166436
https://blog.csdn.net/baidu_29843359/article/details/46967473
https://blog.csdn.net/evo_steven/article/details/17526725

2018.9.5
dhp