数据倾斜是我们在处理大数据量问题时绕不过去的问题,也是在面试中几乎必问的考点。 正常的数据分布理论上都是倾斜的,就是我们所说的'二八原理':80%的财富集中在20%的人手中, 80%的用户只使用20%的功能 , 20%的用户贡献了80%的访问量。 简单来说数据倾斜就是数据的key 的分化严重不均,造成一部分数据很多,一部分数据很少的局面。
相信大部分做数据的童鞋们都会遇到数据倾斜,数据倾斜会发生在数据开发的各个环节中,比如: 用Hive算数据的时候reduce阶段卡在99.99% 用SparkStreaming做实时算法时候,一直会有executor出现OOM的错误,但是其余的executor内存使用率却很低。
当我们看任务进度长时间维持在99%,这里如果详细的看日志或者和监控界面的话会发现:
Spark中的数据倾斜也很常见,Spark中一个 stage 的执行时间受限于最后那个执行完的 task,因此运行缓慢的任务会拖累整个程序的运行速度。过多的数据在同一个task中执行,将会把executor撑爆,造成OOM,程序终止运行。
使用Window、GroupBy、Distinct等聚合函数时,频繁出现反压,消费速度很慢,个别的task会出现OOM,调大资源也无济于事。
在做数据运算的时候会设计到,countdistinct、group by、join等操作,都会触发Shuffle动作。一旦触发,所有相同 key 的值就会拉到一个或几个节点上,发生单点问题。
一个简单的场景,在订单表中,北京和上海两个地区的订单数量比其他地区高几个数量级。那么进行聚合的时候就会出现数据热点。
解决数据倾斜的几个思路:
其他更多的是在业务上的key设计来避免。 如何处理数据倾斜是一个长期的过程,希望本文的一些思路能提供帮助。