数据倾斜
数据倾斜是我们在处理大数据量问题时绕不过去的问题，也是在面试中几乎必问的考点。正常的数据分布理论上都是倾斜的，就是我们所说的'二八原理'：80%的财富集中在20%的人手中, 80%的用户只使用20%的功能 , 20%的用户贡献了80%的访问量。简单来说数据倾斜就是数据的key 的分化严重不均，造成一部分数据很多，一部分数据很少的局面。
表现
相信大部分做数据的童鞋们都会遇到数据倾斜，数据倾斜会发生在数据开发的各个环节中，比如：用Hive算数据的时候reduce阶段卡在99.99%用SparkStreaming做实时算法时候，一直会有executor出现OOM的错误，但是其余的executor内存使用率却很低。
Hadoop
当我们看任务进度长时间维持在99%，这里如果详细的看日志或者和监控界面的话会发现：
有一个多几个reduce卡住
各种container报错OOM
读写的数据量极大，至少远远超过其它正常的reduce
伴随着数据倾斜，会出现任务被kill等各种诡异的表现
Spark
Spark中的数据倾斜也很常见，Spark中一个 stage 的执行时间受限于最后那个执行完的 task，因此运行缓慢的任务会拖累整个程序的运行速度。过多的数据在同一个task中执行，将会把executor撑爆，造成OOM，程序终止运行。
Flink
使用Window、GroupBy、Distinct等聚合函数时，频繁出现反压，消费速度很慢，个别的task会出现OOM，调大资源也无济于事。
数据倾斜原理和解决方案
在做数据运算的时候会设计到，countdistinct、group by、join等操作，都会触发Shuffle动作。一旦触发，所有相同 key 的值就会拉到一个或几个节点上，发生单点问题。
一个简单的场景，在订单表中，北京和上海两个地区的订单数量比其他地区高几个数量级。那么进行聚合的时候就会出现数据热点。
解决数据倾斜的几个思路：
业务上：避免热点key的设计或者打散热点key，例如可以把北京和上海分成地区，然后单独汇总。
技术上：在热点出现时，需要调整方案避免直接进行聚合，可以借助框架本身的能力，例如进行mapside-join。
参数上：无论是Hadoop、Spark还是Flink都提供了大量的参数可以调整。
Hadoop/Hive参数
mapside-join
对于group by或distinct，设定 hive.groupby.skewindata=true
合并小文件
压缩文件
Spark 参数
使用map join 代替reduce join
提高shuffle并行度
Flink 参数
MiniBatch设置
并行度设置
其他更多的是在业务上的key设计来避免。如何处理数据倾斜是一个长期的过程，希望本文的一些思路能提供帮助。
