该问题已同步到小程序：全栈面试题
问题
在数据开发日常工作当中，数据发散和数据倾斜问题是比较常见的。那么我们该如何判断呢？同时该如何规避这两种问题呢？注意：该问题也经常会被面试官拿来提问面试者
解答
基于以上问题，大佬们给出了如下的回答：
数据发散
Destiny：对于数据发散问题，可以查看left join关联对应的右表数据是否有重复，如果出现重复的情况，那么就会造成一对多，可能会出现发散情况。
致远大佬给出了本质性的解答：数据发散是因为关联字段值不唯一导致的。
Nic大佬分享了遇到的数据发散实际场景：在某次埋点上报的数据里，发现某个用户数据重复了2000条记录左右，然后当时数据处理上要把这个数据里面的三列炸裂展开，然后使用全联接，最后生成了2000*2000*2000条记录了。
追求无我：数据发散可能在事实表和维度表或者主明细表关联的时候发生，发生的原因可能是事实表里的一行记录关联到维度表里面的多行记录，这样就产生了数据发散。
别动我的奶酪：个人对数据发散的理解就是数据发生了笛卡尔积了，由于关联条件不唯一导致了数据重复，解决思路就是首先要判断数据是否需要发散，也就是需要什么样的数据结果集，其次在做关联之前要判断关联条件是否唯一，不唯一的需要进行汇总去重。同时需要配置稽核，看关联前后表的数据量级示范一致，金额等数值型字段的总和是否一致。
数据倾斜
关于数据倾斜的问题，笔者也发布了很多解决方案，具体可见
下面来看下以下两位大佬对数据倾斜的理解:
妄想复苏的心跳：数据倾斜其实就像是热点问题，指的是在分布式系统过程中一个或少数几个节点处理了整个数据集的大部分数据，造成了单机性能瓶颈。针对这种情况常见的解决方案就是先定位到倾斜key，根据倾斜key个数采取不同的手段，比如在其key前面加上前缀，最后聚合的时候再去掉前缀即可。
别动我的奶酪：数据倾斜最直观的判断就是reduce卡到了99%，一般都是大表关联小表。解决思路就是在关联前尽量减少不必要的数据，让大表的数据尽可能缩小量级