面试必问。大数据面试绝对重点！！ 面过的12家，有字节、快手、美的、顺丰、OPPO、京东、贝壳都被问道过。菜鸡的我没有实习经历项目中也没有遇到过数据倾斜的情况，每次被问到都如坐针毡思维混乱一通乱说。😅😅给各位面试官留下了逻辑性差、实践少的差印象。特把这个问题单独摘出来进行深入整理！！！！ 各位朋友，本人实践经验有限，下文如有错误劳烦您指出，万分感谢！ 花式提问😅😅 你遇到过Spark 的数据倾斜吗 你遇到过Hive 的数据倾斜吗 你遇到过Redis 的数据倾斜吗 你遇到过 Kafka 的数据倾斜吗 你在项目中遇到过数据倾斜吗 你知道怎么解决数据倾斜吗....... 题眼 @Aerospike 一个月前，字节三面面经评论区这位大哥点醒了我。 partition倾斜那个应该就是热点倾斜，会导致消息堆积，最本质的是对每个message的hash处理 无论是哪个组件，在发生消息堆积的时候，也就是大量message 被发送到了一个地方，那我们来拆题：Kafka 数据倾斜：大量数据被发送到了Kafka 中一个partitionSpark 数据倾斜：大量数据被发送到了Spark 的一个taskHive  数据倾斜：大量数据被发送到了一个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 进行采样，统计出数据量最大的几个keyb.对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照常joinf.将两次join 的结果用 Union 算子结合，得到最终的join 结果。效果：通过打随即前缀，将倾斜的RDDA_1 打散为n份做join。这样倾斜key 对应的大量数据被分摊到更多task上，规避倾斜。 4.调参解决