数据发散

什么是数据发散

在join的过程中，关联键出现一对多，或者多对多时候，造出结果存在重复。

数据发散症状

症状

（1）结果存在重复。

（2）数据量剧增。

（3）可能导致无法使用正常资源处理完成。

排查

（1）出现这种原因就是

A left join B 的时候，使用主键的关联条件中，没有关联到表B的最小粒度。

（2）查找是否是这种原因

select 关联字段 from table group by 关联字段 having count（关联字段）>1
就可以判定是否有关联字段出现不唯一的发散情况。

避免或解决

（1）做join或left join时一定要检查左表的关联字段是否有null值。

（2）如果右表关联字段有重复值则要去重，否则数据会发散。

（3）仔细写好SQL，是否存在业务逻辑的错误(关联字段用错)。

笛卡儿积

什么是笛卡儿积

笛卡尔积在SQL中的实现方式既是交叉连接(Cross Join)。所有连接方式都会先生成临时笛卡尔积表，笛卡尔积是关系代数里的一个概念，表示两个表中的每一行数据任意组合

笛卡儿积案例

A表
id name city
1 aa 1001
2 bb 1002
3 cc 1003

B表
id city_name
1 a城
2 b城
3 c城

SQL
  1. SELECT * FROM A,B;

结果
id name city id city_name
1 aa 1001 1 a城
1 aa 1001 2 bb
1 aa 1001 3 c城
2 bb 1002 1 a城
2 bb 1002 2 bb
2 bb 1002 3 c城
3 cc 1003 1 a城
3 cc 1003 2 bb
3 cc 1003 3 c城

产生原因

（1）当连接没有on条件是，会出现笛卡尔积(全部笛卡尔积)。
（2）当连接on条件是非唯一字段时，会出现笛卡尔积(局部笛卡尔积)。
（3）join的两个表中都含有空行。

怎么避免或解决

（1）关联范围在最小粒度的列.
（2）检查左表的关联字段是否有null值。

数据倾斜

什么是数据倾斜

数据倾斜最笼统概念就是数据的分布不平衡，有些地方数据多，有些地方数据少。在计算过程中有些地方数据早早地处理完了，有些地方数据迟迟没有处理完成，造成整个处理流程迟迟没有结束，这就是最直接数据倾斜的表现。

数据倾斜症状

Hive

hive自身的MR引擎：发现所有的map task全部完成，并且99%的reduce task完成，只剩下一个或者少数几个reduce task一直在执行，这种情况下一般都是发生了数据倾斜。说白了就是Hive的数据倾斜本质上是MapReduce的数据倾斜。

Flink

（1）Flink 任务出现数据倾斜的直观表现是任务节点频繁出现反压。

（2）部分节点出现 OOM异常，是因为大量的数据集中在某个节点上，导致该节点内存被爆，任务失败重启。

Spark

（1）Executor lost，OOM，Shuffle过程出错。

（2）Driver OOM。

（3）单个Executor执行时间特别久，整体任务卡在某个阶段不能结束。

（4）正常运行的任务突然失败。

怎么避免或解决

往期详细介绍过

不管再出现分布式计算框架出现数据倾斜问题解决思路如下：很多数据倾斜的问题，都可以用和平台无关的方式解决，比如更好的数据预处理，异常值的过滤等。因此，解决数据倾斜的重点在于对数据设计和业务的理解，这两个搞清楚了，数据倾斜就解决了大部分了。关注这几个方面：

业务逻辑方面

（1）数据预处理。

（2）解决热点数据：分而治之(第一次打散计算，第二次再最终聚合计算)。

程序代码层面

（1）导致最终只有一个Reduce任务的，需要想到用替代的关键字或者算子去提升Reduce任务数。

（2）调参。

熟悉自己手中的工具（框架）

优秀的框架已经负重前行给你优化了好多不仅要学，更学会去用，更要努力去完善拓展框架功能。