屡败屡战的大数据秋招之面试必问数据倾斜

面试必问。大数据面试绝对重点！！

面过的12家，有字节、快手、美的、顺丰、OPPO、京东、贝壳都被问道过。菜鸡的我没有实习经历项目中也没有遇到过数据倾斜的情况，每次被问到都如坐针毡思维混乱一通乱说。😅😅给各位面试官留下了逻辑性差、实践少的差印象。特把这个问题单独摘出来进行深入整理！！！！

各位朋友，本人实践经验有限，下文如有错误劳烦您指出，万分感谢！

花式提问😅😅

你遇到过Spark 的数据倾斜吗
你遇到过Hive 的数据倾斜吗
你遇到过Redis 的数据倾斜吗
你遇到过 Kafka 的数据倾斜吗
你在项目中遇到过数据倾斜吗
你知道怎么解决数据倾斜吗
.......

题眼

@Aerospike 一个月前，字节三面面经评论区这位大哥点醒了我。

partition倾斜那个应该就是热点倾斜，会导致消息堆积，最本质的是对每个message的hash处理

无论是哪个组件，在发生消息堆积的时候，也就是大量message 被发送到了一个地方，那我们来拆题：
Kafka 数据倾斜：大量数据被发送到了Kafka 中一个partition
Spark 数据倾斜：大量数据被发送到了Spark 的一个task
Hive 数据倾斜：大量数据被发送到了一个Reduce 任务中
Redis 数据倾斜：大量数据都存到了Redis 集群中的一个节点中

😅😅😅是不是一样啊，就是一样啊啊啊啊！！！！解决问题的思路是一样的！！

Kafka 数据倾斜解决思路：

自定义分区器Partitioner。

Redis 集群数据倾斜解决方案：

重新进行槽指派

Hive 数据倾斜解决方案

聚合倾斜

Join 倾斜

Spark 数据倾斜解决方案

1.广播变量

场景：对RDD进行join 类操作。A join B。且B的RDD比较小（百兆或者1~2GB）的情况下。
解决思路：对较小的RDD直接collect到内存并创建广播变量。对另一方执行map 类算子。也就是A RDD去和广播变量中的每条数据依次对比key，key相同的两条进行join。
效果：用广播变量 + map 代替join。规避join带来的shuffle。

2.聚合倾斜

场景：对RDD进行reduceByKey 等聚合类shuffle 算子，还有SparkSQL做分组聚合时。部分key 嗷嗷多，导致少数节点OOM，或已经完成的节点都在等这个还在做的节点。
解决思路： 通过map 算子给操作的key打上n以内的随机数，举个例子(hello, 1) (hello, 1) (hello, 1) (hello, 1)变为(1_hello, 1) (1_hello, 1) (2_hello, 1)，并进行reduceByKey的局部聚合。然后再次调用map 算子将key 的前缀随机数去掉，再次进行全局聚合。
效果：
将原本一个task 处理的数据分摊到多个task 进行局部聚合。规避了单个task 数据量大。

3.Join 倾斜

场景：两个大的RDD 进行Join 操作，并且一个RDD中少数key 数据量过大表示为RDDA，另一个RDD 的key 分布比较均匀表示为RDDB
解决思路：
a.对RDDA 进行采样，统计出数据量最大的几个key
b.对RDDA进行拆分，将倾斜的key拆分出来形成单独的RDDA_1,并打上0到n 的随机数前缀。剩余的另一部分形成RDDA_2。
c.对RDDB过滤出RDDA倾斜的key，得到RDDB_1，并将其中每条数据扩大n倍，之后按序附加0到n的前缀。剩余的一部分独立形成一个RDDB_2.
d.将RDDA_1和RDDB_1进行join。这时候倾斜的key被打散N份并分散到更多的task中进行Join。
e.将两个普通的RDD照常join
f.将两次join 的结果用 Union 算子结合，得到最终的join 结果。
效果：通过打随即前缀，将倾斜的RDDA_1 打散为n份做join。这样倾斜key 对应的大量数据被分摊到更多task上，规避倾斜。