一、数据倾斜包含：hadoop数据倾斜，hive中数据倾斜、spark数据倾斜
【hadoop中的数据倾斜表现】
1、有一个多几个 Reduce 卡住，卡在 99.99%，一直不能结束。
2、各种 container 报错 OOM
3、异常的 Reducer 读写的数据量极大，至少远远超过其它正常的 Reducer
4、伴随着数据倾斜，会出现任务被 kill 等各种诡异的表现。
【hive 中数据倾斜】
一般都发生在 Sql 中 group by 和 join on 上，而且和数据逻辑绑定比较深。
【Spark 中的数据倾斜】
Spark 中的数据倾斜，包括 Spark Streaming 和 Spark Sql，表现主要有下面几种：
1、Executor lost，OOM，Shuffle 过程出错；
2、Driver OOM；
3、 单个 Executor 执行时间特别久，整体任务卡在某个阶段不能结束；
4、 正常运行的任务突然失败；
二、数据倾斜产生的原因
我们以 Spark 和 Hive 的使用场景为例。
他们在做数据运算的时候会涉及到，count distinct、group by、join on 等操作，这些都会触发 Shuffle 动作。一旦触发 Shuffle，所有相同 key 的值就会被拉到一个或几个 Reducer 节点上，容易发生单点计算问题，导致数据倾斜。
一般来说，数据倾斜原因有以下几方面：
1、key分布不均匀
2、建表时考虑不周
例如有两张表
user（用户信息表）：userid，register_ip
ip（IP 表）：ip，register_user_cnt
这可能是两个不同的人开发的数据表。如果我们的数据规范不太完善的话，会出现一种情况：
user 表中的 register_ip 字段，如果获取不到这个信息，我们默认为 null；但是在 ip 表中，我们在统计这个值的时候，为了方便，我们把获取不到 ip 的用户，统一认为他们的 ip 为 0。两边其实都没有错的，但是一旦我们做关联了，这个任务会在做关联的阶段，也就是 sql的 on 的阶段卡死。
3、业务数据激增
比如订单场景，我们在某一天在北京和上海两个城市多了强力的推广，结果可能是这两
个城市的订单量增长了 10000%，其余城市的数据量不变。
然后我们要统计不同城市的订单情况，这样，一做 group 操作，可能直接就数据倾斜了。
【数据倾斜解决思路】
很多数据倾斜的问题，都可以用和平台无关的方式解决，比如更好的数据预处理，异常值的过滤等。因此，解决数据倾斜的重点在于对数据设计和业务的理解，这两个搞清楚了，数据倾斜就解决了大部分了。
1、业务逻辑
我们从业务逻辑的层面上来优化数据倾斜，比如上面的两个城市做推广活动导致那两个城市数据量激增的例子，我们可以单独对这两个城市来做 count，单独做时可用两次 MR，第一次打散计算，第二次再最终聚合计算。完成后和其它城市做整合。
2、程序层面
比如说在 Hive 中，经常遇到 count(distinct)操作，这样会导致最终只有一个 Reduce 任务。
我们可以先 group by，再在外面包一层 count，就可以了。比如计算按用户名去重后的总用户量：
（1）优化前 只有一个 reduce，先去重再 count 负担比较大：
select name,count(distinct name)from user;
（2）优化后
// 设置该任务的每个 job 的 reducer 个数为 3 个。Hive 默认-1，自动推断。
set mapred.reduce.tasks=3;
// 启动两个 job，一个负责子查询(可以有多个 reduce)，另一个负责 count(1)：
select count(1) from (select name from user group by name) tmp;
3、调参方面
Hadoop 和 Spark 都自带了很多的参数和机制来调节数据倾斜，合理利用它们就能解决大部分问题。
4、从业务和数据上解决数据倾斜
很多数据倾斜都是在数据的使用上造成的。我们举几个场景，并分别给出它们的解决方案。
⚫ 有损的方法：找到异常数据，比如 ip 为 0 的数据，过滤掉
⚫ 无损的方法：对分布不均匀的数据，单独计算
⚫ 先对 key 做一层 hash，先将数据随机打散让它的并行度变大，再汇集
⚫ 数据预处理
定位导致数据倾斜代码
Spark 数据倾斜只会发生在 shuffle 过程中。
这里给大家罗列一些常用的并且可能会触发 shuffle 操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition 等。
出现数据倾斜时，可能就是你的代码中使用了这些算子中的某一个所导致的。