0X00 前提
技術選型：阿里雲Maxcompute 2.0
場景：普通的日常模型開發，原有的模型寬表基礎上通過left outer join獲取新的維度信息。操作：A LEFT OUTER JOIN B ON A.ID=B.CID;
0x01 過程
分析：
- A表80w數據量，B表200w。一開始懷疑是因爲小表左關聯大表導致數據量翻倍，但是通過另外一個50w行記錄的C表左關聯B表實驗，得到結果接近50w，即排除因爲小表關聯大表的原因導致數據翻倍；
- 接下來是排除數據質量問題，對關聯條件的字段做了空值、空白值、非常見符號剔除等操作。通過查詢A表：
insert overwrite table A_b select distinct id from A，獲得A表中所有唯一的id，然後A_b和B表full join 得80w數據量結果集。數據質量沒有問題； - 按理A和B表是一對一關係，左關聯後數據量應該接近A表的80w行，但實際結果是200w左右接近B表，拿了其中一個值爲6956667891XXX002的id的記錄爲例子進行查詢，按理結果應該只有一條，記錄裏面來源A表的字段id和來源B表的字段cid應該都是6956667891XXX002。然而事實大跌眼鏡，出現兩條記錄：
| id | cid |
|---|---|
| 6956667891XXX002 | 6956667891XXX002 |
| 6956667891XXX002 | 6956667891XXX005 |
- 第二行記錄不應該出現的記錄只是最後一位不一樣，懷疑是關聯時把id（多爲數字）截斷來比較了
- 最後開始懷疑是因爲表結構在建表時某些參數沒設置好導致的問題（其實已經開始懷疑人生了…）。在對比A、B、A_b三個表結構的時候，忽然發現，關聯條件id在A表中是bigint類型，而B、C、A_b表中均爲string類型，於是在關聯時做了強制類型轉換：A LEFT OUTER JOIN B ON cast(A.ID AS STRING)=B.CID; 最後結果：
| id | cid |
|---|---|
| 6956667891XXX002 | 6956667891XXX002 |
0X02 解決
阿里雲平臺上的Maxcompute在做表之間關聯時（不管左右關聯、全關聯等等），都需要確保表之間用來做關聯的條件字段，一定是相同類型，否則會出現上述關聯時兩條不一樣但相似的關聯值被當作正確值帶出來。如果關聯條件字段類型不一致，可以通過cast()函數來進行類型強制轉換。
0X03 反思
以前在使用hive的時候是不需要關心字段類型的，因爲在做關聯條件兩端匹配時，會自動轉換成字符串然後按照字段順序進行比較、匹配。估計阿里雲Maxcompute底層是做強類型定義的，需要精確控制存儲大小，而與hive的讀模式不一樣。
這個問題是我接手客戶公司原有的阿里雲數倉做重構時發現，看來以後可以開兩個新坑：
- 數據倉庫重構之路
- 各大NoSQL機制、方案比較
（無腦立Flag多多見諒，保命手動狗頭doge）