[调优]数据倾斜是多么痛？

数据倾斜是多么痛？spark作业/面试/调优必备秘籍
http://mp.weixin.qq.com/s?src=3×tamp=1477560215&ver=1&signature=gWAPwUKk8c8DWu7rMLSS0LVvlBPoi3mvSzH8FtRLwMNgV0OBW5YCpzmlrVAC85vSEVyrhCGegGNsaFMC2tRwQcH5Mz3fGB6tX-sov6NXUFQL0HNSN9ALtzxQLluX8S4CF9DQVthnX7IM6bU8-Klpk*1CYIcmDNLzwKUs9NKaY=
数据倾斜是多么痛？！！！
如果数据倾斜没有解决，完全没有可能进行性能调优，其他所有的调优手段都是一个笑话。数据倾斜是最能体现一个spark大数据工程师水平的性能调优问题。
数据倾斜如果能够解决的话，代表对spark运行机制了如指掌。

//
数据倾斜俩大直接致命后果。
1 数据倾斜直接会导致一种情况：OOM。
2 运行速度慢,特别慢，非常慢，极端的慢，不可接受的慢。

//
数据倾斜的原因：
在Shuffle阶段。同样Key的数据条数太多了。导致了某个key(上图中的80亿条)所在的Task数据量太大了。远远超过其他Task所处理的数据量。
而这样的场景太常见了。二八定律可以证实这种场景。

//
搞定数据倾斜需要：
1 搞定shuffle
2 搞定业务场景
3 搞定 cpu core的使用情况
4 搞定OOM的根本原因等。
所以搞定了数据倾斜需要对至少以上的原理了如指掌。所以搞定数据倾斜是关键中的关键。
告诉大家一个屡试不爽的经验结论：一般情况下，OOM的原因都是数据倾斜。某个task任务数据量太大，GC的压力就很大。这比不了Kafka,因为kafka的内存是不经过JVM的。是基于Linux内核的Page.

//
数据倾斜发生的原理
　　数据倾斜的原理很简单：在进行shuffle的时候，必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理，比如按照key进行聚合或join等操作。此时如果某个key对应的数据量特别大的话，就会发生数据倾斜。比如大部分key对应10条数据，但是个别key却对应了100万条数据，那么大部分task可能就只会分配到10条数据，然后1秒钟就运行完了；但是个别task可能分配到了100万数据，要运行一两个小时。因此，整个Spark作业的运行进度是由运行时间最长的那个task决定的。　　因此出现数据倾斜的时候，Spark作业看起来会运行得非常缓慢，甚至可能因为某个task处理的数据量过大导致内存溢出。