概述
螞蟻的轉化歸因在初期運行兩個多小時的情況下，進行了一系列優化，其中建立hash cluster表及強制hash關聯及Shuffle的手動干預進行remove操作此部分優化佔了較大比重。本文則主要講述hash cluster表的一些運用。
Hash cluster表具有兩個作用：
- 存儲預排序的重排壓縮。Hash cluster表採用分桶排序操作，若相同的值重複度高，則可以達到更好的壓縮效果。
- 下游任務的Shuffle Remove。Hash cluster表由於採用對指定字段分桶操作，下游若一些關聯、聚合操作與分桶鍵策略相同，則會進行Shuffle Remove操作。MaxCompute操作中，Shuffle是昂貴的，因此有必要在優化階段儘可能移除不必要的Shuffle。什麼情況下可以移除Shuffle？簡單來說就是數據本身已經具有某些數據分佈特性，剛好這個數據分佈特性滿足了上游算子對這份數據的分佈要求，就不需要再做Shuffle，這個也是Hash cluster表的重要應用場景。
前言
轉化歸因任務加工相對較複雜，在此對其中關鍵步驟做個說明：
1、源頭分三部分，訪問日誌數據A，點擊日誌數據B，接入的事件數據C，此三部分數據表已設置爲4096分桶的hash表。
2、以上三部分數據以用戶進行分組，分別傳入用戶的點擊、訪問和事件數據，通過udf處理得到單用戶的歸因結果數據（以字條串返回）。
3、返回以用戶粒度的結果數據進行字段拆分後以用戶的事件id進行膨脹，膨脹後關聯用戶事件數據補充事件數據後其它字段。
4、上一步關聯後的結果數據以日誌id進行膨脹，膨脹後的數據關聯訪問和點擊日誌數據得到日誌中的其它一些補充字段。
以上步驟按單用戶數據處理過程流程大致如下：
圖(1)
以支付寶支付線來講，最初總計運行兩個來小時，加工邏輯步驟有近十來個任務。後續進行了udf優化並邏輯合併爲一個script，圖2右部分。
圖(2)
圖(3)
優化過程
中間狀態
以下任務是在經過多任務合併爲一script任務後內容，其中源頭輸入表點擊(mid_log_clk_xxxx_di)和訪問(mid_log_vst_xxxx_di)表建立hash cluster，而事件表是以事件代碼爲二級分區的普通表（事件表是通過頁面通過不同的事件碼在線接入後生成不同的任務產出的表），以支付線爲例，任務改造後穩定在半小時左右，但目前隨着事件增加有所增長。
點擊訪問建表主要內容
CLUSTERED BY (user_id ASC) SORTED BY (user_id ASC,log_id ASC) INTO 4096 BUCKETS
整體運行圖如下，相比原來十來個任務，無論是日常運行、歷史回刷都變的相對簡潔。
圖(4)
在此過程中個人分析若事件輸入表能在運行過程中變hash cluster的話，那下游按理可再減少一些Shuffle操作，嘗試對事件表增加 DISTRIBUTE BY user_id SORT BY scene_type,order_id 操作且設置參數set odps.sql.reducer.instances=4096，但測試發現下游對此無感知，聯繫MaxCompute 開發人員得知目前暫無此功能。
接入事件hash表不能在運行中得到那隻能再增加一個任務把事件數據插入一cluster表供任務使用，但由於在主鏈路上，增加的時間影響整體產出時間，但以支付線幾個億數據量爲例，插入cluster表整體3分鐘左右，建立cluster後整體執行圖如下：
圖(5)
以上執行圖已經相當簡單，運行速度相比原來任務及增加的上游整體也有一定的提升，但是發現兩主task中，m3和m4同樣都是4096實例，都是按用戶分桶進行的分發，按理此兩M應該是可以Shuffle remove進行合併的，問及MaxCompute開發人員大致是一些複雜操作後屬性丟失後不能消除Shuffle。
最終狀態
雖然圖5的執行計劃相對來說已經非常簡潔，但一些實際結果與認知不同時總想找到問題出在哪裏。因此，我對任務中的一些sql嵌套進行層次減少，對一些關聯先拆解再慢慢增加，在此過程中發現增加了一個小表的mapjoin會導致下游需要進行Shuffle（理論上小表mapjoin不影響主表分發），其中一個黑名單列表，數據量少且近三年都無增加數據，因此直接改造爲固定值傳入，另外一個小表在最後再進行mapjoin關聯，最終執行圖如下，只有一個主的task，非常簡潔。
圖(6)
以下爲m2中的算子，非常複雜，但無需Shuffle執行效率非常高
圖(7)
執行結果
最終執行時長不到20分鐘，相對原先減少一半，而且消耗的cu及內存都有所降低，轉化歸因整體鏈路產出提前20分鐘+。
圖(8)
圖(9)
總結
1、本文的一些優化整體是基於Hash Clustering Table的建立，在創建Hash表時需要考慮分桶鍵的設定，並不是說一定要所有的關聯鍵設置爲分桶鍵，在考慮Hash的一些任務性能的同時，也需要考慮表的存儲壓縮大小。
2、針對MaxCompute平臺的一些策略原理，首先需要有自己的一些自身認知，很多時候不一定是一兩個文檔能夠說清楚，更需要一些實踐的測試來加深知識點的理解。
3、MaxCompute很多方面已經非常智能及高效，希望在自動的優化方面可以更加智能。
作者：開七 螞蟻集團數據技術專家
本文爲阿里雲原創內容，未經允許不得轉載。