數據開發中，這些讓你頭疼過嗎？
數據發散
什么是數據發散
在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）調參。
熟悉自己手中的工具（框架）
優秀的框架已經負重前行給你優化了好多不僅要學，更學會去用，更要努力去完善拓展框架功能。
