hive数据倾斜问题

关于数据倾斜问题的思考

（本人小白，不是什么大牛，有什么不对的地方欢迎指正）
背景：
数据倾斜是大数据领域绕经常遇到的问题，当你所需处理的数据量到达了上亿甚至是千亿条的时候，数据倾斜将是横在你面前一道巨大的坎，这也是大数据处理的一个隐形的bug。最近在用Hadoop跑批的时候经常遇到，一条hivesql要跑好久才能跑完。

相信大部分做数据的童鞋们都会遇到数据倾斜，数据倾斜会发生在数据开发的各个环节中，比如：

• 用Hive算数据的时候reduce阶段卡在99.99%
• 用SparkStreaming做实时算法时候，一直会有executor出现OOM的错误，但是其余的executor内存使用率却很低

一、什么是数据倾斜以及数据倾斜是怎么产生的？

简单来说数据倾斜就是数据的key的分化严重不均，造成一部分数据很多，一部分数据很少的局面。 举个 word count 的入门例子，它的map 阶段就是形成 （“aaa”,1）的形式，然后在reduce 阶段进行 value 相加，得出 “aaa” 出现的次数。若进行 word count 的文本有100G，其中 80G 全部是 “aaa” 剩下 20G 是其余单词，那就会形成 80G 的数据量交给一个 reduce 进行相加，其余 20G 根据 key 不同分散到不同 reduce 进行相加的情况。如此就造成了数据倾斜，临床反应就是 reduce 跑到 99%然后一直在原地等着 那80G 的reduce 跑完。

一、Hadoop中的数据倾斜

Hadoop中直接贴近用户使用使用的时Mapreduce程序和Hive程序，虽说Hive最后也是用MR来执行（至少目前Hive内存计算并不普及），但是毕竟写的内容逻辑区别很大，一个是程序，一个是Sql，因此这里稍作区分。

Hadoop中的数据倾斜主要表现在、ruduce阶段卡在99.99%，一直99.99%不能结束。

这里如果详细的看日志或者和监控界面的话会发现：

有一个多几个reduce卡住

各种container报错OOM

读写的数据量极大，至少远远超过其它正常的reduce

伴随着数据倾斜，会出现任务被kill等各种诡异的表现。

经验：Hive的数据倾斜，一般都发生在Sql中Group和On上，而且和数据逻辑绑定比较深。

二、Spark中的数据倾斜

Spark中的数据倾斜也很常见，这里包括Spark Streaming和Spark Sql，表现主要有下面几种：

Executor lost，OOM，Shuffle过程出错

Driver OOM

单个Executor执行时间特别久，整体任务卡在某个阶段不能结束

正常运行的任务突然失败

补充一下，在Spark streaming程序中，数据倾斜更容易出现，特别是在程序中包含一些类似sql的join、group这种操作的时候。 因为Spark Streaming程序在运行的时候，我们一般不会分配特别多的内存，因此一旦在这个过程中出现一些数据倾斜，就十分容易造成OOM。

0x03 数据倾斜的原理

一、数据倾斜产生的原因
我们以Spark和Hive的使用场景为例。他们在做数据运算的时候会设计到，countdistinct、group by、join等操作，这些都会触发Shuffle动作，一旦触发，所有相同key的值就会拉到一个或几个节点上，就容易发生单点问题。

二、万恶的shuffle
Shuffle是一个能产生奇迹的地方，不管是在Spark还是Hadoop中，它们的作用都是至关重要的。关于Shuffle的原理，这里不再讲述，看看Hadoop相关的论文或者文章理解一下就ok。这里主要针对，在Shuffle如何产生了数据倾斜。

Hadoop和Spark在Shuffle过程中产生数据倾斜的原理基本类似。如下图。

大部分数据倾斜的原理就类似于下图，很明了，因为数据分布不均匀，导致大量的数据分配到了一个节点。

这篇写的比较深刻：https://segmentfault.com/a/1190000009166436