数据倾斜？几招把你安排的板板正正的！

 🍅 作者：不吃西红柿 

🍅 简介：CSDN博客专家🏆、HDZ核心组成员💪、C站总榜前10名✌ 

🍅 粉丝专属福利：文末公号「信息技术智库」回复「资料」领取

🍅 如觉得文章不错，欢迎点赞、收藏、评论

---

文末下载PDF

拥有本篇PDF，意味着你拥有一本完善的书籍，本篇文章整理了数据仓库领域，几乎所有的知识点，文章内容主要来源于以下几个方面：

1. 源于「数据仓库交流群」资深数据仓库工程师的交流讨论，如《sql行转列的千种写法》。
2. 源于群友面试大厂遇到的面试真题，整理投稿给我，形成《面试题库》。
3. 源于笔者在系统学习过程中整理的笔记和一点理解。
4. 源于技术网站的优质文章和高赞答案。

本篇文章尤其适合初级程序员准备面试，以及作为工作中的指导手册，对资深程序员来说也可夯实基础。

当然，技术学习仅仅依靠一篇文章还是不够的，可加入公众号和技术交流群（联系方式见文末），群里有很多数据仓库领域资深大佬，大家经常在群里讨论技术热点问题、互相解决工作难题、安排内推、甚至有部门leader直接发出岗位邀请。「西红柿🍅」也会持续更新优质文章，也欢迎热爱学习总结的小伙伴有偿投稿，共同推动中国信息技术行业发展，让我们一起加油吧！

1、数据倾斜表现

1.1 hadoop中的数据倾斜表现

• 有一个多几个Reduce卡住，卡在99.99%，一直不能结束。
• 各种container报错OOM
• 异常的Reducer读写的数据量极大，至少远远超过其它正常的Reducer
• 伴随着数据倾斜，会出现任务被kill等各种诡异的表现。

1.2 hive中数据倾斜

一般都发生在Sql中group by和join on上，而且和数据逻辑绑定比较深。
 

1.3 Spark中的数据倾斜

Spark中的数据倾斜，包括Spark Streaming和Spark Sql，表现主要有下面几种：

• Executor lost，OOM，Shuffle过程出错；
• Driver OOM；
• 单个Executor执行时间特别久，整体任务卡在某个阶段不能结束；
• 正常运行的任务突然失败；

2、数据倾斜产生原因

我们以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操作，可能直接就数据倾斜了。
 

3、解决数据倾斜思路

很多数据倾斜的问题，都可以用和平台无关的方式解决，比如更好的数据预处理，异常值的过滤等。因此，解决数据倾斜的重点在于对数据设计和业务的理解，这两个搞清楚了，数据倾斜就解决了大部分了。

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）从业务和数据上解决数据倾斜

很多数据倾斜都是在数据的使用上造成的。我们举几个场景，并分别给出它们的解决方案。
 

一个原则：尽早过滤每个阶段的数据量。

1. 数据有损的方法：找到异常数据，比如ip为0的数据，过滤掉。
2. 数据无损的方法：对分布不均匀的数据，单独计算。
3. hash法：先对key做一层hash，先将数据随机打散让它的并行度变大，再汇聚。
4. 数据预处理：就是先做一层数据质量处理，类似于数据仓库维度建模时，底层先处理数据质量。

添加公众号「信息技术智库」：

🍅 硬核资料：20G，8大类资料，关注即可领取（PPT模板、简历模板、技术资料）
🍅 技术互助：技术群大佬指点迷津，你的问题可能不是问题，求资源在群里喊一声。
🍅 面试题库：由各个技术群小伙伴们共同投稿，热乎的大厂面试真题，持续更新中。
🍅 知识体系：含编程语言、算法、大数据生态圈组件（Mysql、Hive、Spark、Flink）、数据仓库、前端等。

👇👇送书抽奖丨技术互助丨粉丝福利👇👇