数据发散
什么是数据发散
在join的过程中，关联键出现一对多，或者多对多时候，造出结果存在重复。
数据发散症状
症状
（1）结果存在重复。
（2）数据量剧增。
（3）可能导致无法使用正常资源处理完成。
排查
（1）出现这种原因就是
A left join B 的时候，使用主键的关联条件中，没有关联到表B的最小粒度。
（2）查找是否是这种原因
select 关联字段 from table group by 关联字段 having count（关联字段）>1 就可以判定是否有关联字段出现不唯一的发散情况。
避免或解决
（1）如果右表关联字段有重复值则要去重，否则数据会发散。
（2）仔细写好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
- 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）检查表的关联字段是否有空值。
数据倾斜
什么是数据倾斜
数据倾斜最笼统概念就是数据的分布不平衡，有些地方数据多，有些地方数据少。在计算过程中有些地方数据早早地处理完了，有些地方数据迟迟没有处理完成，造成整个处理流程迟迟没有结束，这就是最直接数据倾斜的表现。
数据倾斜症状
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）调参。
熟悉自己手中的工具（框架）
优秀的框架已经负重前行给你优化了好多不仅要学，更学会去用，更要努力去完善拓展框架功能。
