攜程酒店基於血緣後設資料的資料流程最佳化實踐

　　 一、背景

　　後設資料MetaData狹義的解釋是用來描述資料的資料，廣義的來看，除了業務邏輯直接讀寫處理的那些業務資料，所有其它用來維持整個系統運轉所需的資訊／資料都可以叫作後設資料。比如資料表格的Schema資訊，任務的血緣關係，使用者和指令碼／任務的許可權對映關係資訊等等。

　　在資料倉儲的建設質量的評估中，一個必不可少的評價指標就是資料產出的及時性，特別是對於P0級別的流程，及時性指標的好壞一方面決定了下游應用方能否準時地獲取所需的業務指標，直接影響到業務的工作效率；另一方面也反映了相應指標的資料架構的合理程度。

　　資料及時性，顧名思義就是測試資料需要按時產出。及時性重點關注的三個要素是：定時排程時間、資料任務優先順序以及資料產出deadline。其中任務的優先順序決定了它獲取資料計算資源的多少，影響了任務執行時長。資料deadline則是資料最晚產出時間的統一標準，需要嚴格遵守。這三要素中，屬於業內統一認知且在質量保障階段需要重點關注的是：資料deadline，這也是我們最佳化資料流程產出的最終評判標準。

　　 二、問題

　　上述部分已經闡述了資料及時性的重要性和評判標準，在通常情況下，為了提升資料及時性，需要投入人力對重點資料流程進行最佳化。

　　但針對資料倉儲業界來講，對於一個重要的資料結果，其上游可能存在幾十個層級，數百個不同的資料處理任務，從最初的資料到最終的結果，資料流轉過程極其複雜，傳統的透過人工逐個排查的方式去定位影響資料流程產出的問題節點，存在如下的三項缺點：

　　1）覆蓋的任務範圍有限；

　　2）效率低下，判斷標準不統一，判定準確率不高；

　　3）無法形成知識沉澱，依賴於個人能力；

　　如果資料流程未能充分最佳化，一方面會存在資料結果產出時間不穩定，影響資料的及時性；另一方面也會造成計算資源和儲存資源的浪費，並且也不易於後續維護。

　　 三、方案

　　為了避免上述的問題，提升資料流程最佳化的效率和質量，我們採用了從血緣後設資料出發的方案。在數倉任務的執行中，都會依賴於一個排程系統元件，目前業內通用的是以DAG為核心的工作流系統，資料流程中的每個任務都會設定定時執行或者配置上游依賴，這些設定的上游依賴就是我們方案中需要的排程血緣的後設資料。

　　基於上述的血緣資料，我們的方案中需要實現以下兩個功能：

　　基於任務之間的血緣關係生成所有上游任務的層級依賴資料

　　以排程系統本身的後設資料作為出發點，排程系統自身的後設資料就包含了一個任務的上游和下游依賴，基於這個資料，透過層級遞迴的掃描，就可以得到指定根節點任務的所有上游任務的層級依賴結果。

　　設計合理的演算法定位到有問題的任務

　　在上一步驟得到指定根節點任務的所有上游任務的層級依賴結果後，透過如下三種邏輯定位有問題的任務：

　　1）定位過度分層：JobA的下游只有JobA1在使用，且JobA是JobA1產出的關鍵路徑，也即JobA1的產出時間由JobA決定，那麼此種情形下，我們可以把JobA的邏輯合併到JobA1，這樣一方面可以減少大資料任務的啟動消耗時間和獲取資源的時間；另一方面也可以減少依賴層級，方便後續維護。

　　2）定位重複依賴：在較複雜的資料流程中，會出現如下的情況：JobB2依賴JobB1和JobB，而JobB1也同時依賴JobB，簡化後的情況如下圖：　　

　　此時我們就可以檢查JobB2的邏輯，考慮任務內容中涉及到JobB的邏輯合併到JobB1，從而可以實現流程依賴和程式碼邏輯的合併最佳化，降低維護成本，提升整體產出時間。

　　3）定位關鍵路徑:在完成上述兩個步驟後，整個流程從結構上已經基本沒問題，如果要進一步最佳化產出時間，需要針對特定任務進行調優，此時可以基於已有的上游層級依賴資料，計算得到每個層級的最晚產出的任務Id，這些任務Id串聯在一起就是影響整個流程產出的關鍵路徑，然後對關鍵路徑上的任務進行調優。

　　上述方案的整體設計圖如下：　　

　　 四、案例

　　在對酒店訂單明細寬表的最佳化過程中，基於前期的後設資料建設，主要的工作內容分為以下三個步驟：

　　1）排程最佳化。排程最佳化的出發點是合理分配同步任務的優先順序，將非核心任務的資料同步延後。從而降低0到2點，酒店訂單寬表核心流程執行期間的叢集資源壓力。

　　2）模型最佳化。在這一步驟中，我主要是從兩個方向出發：

　　減少跨層級重複依賴，避免相似邏輯程式碼的出現，提升資料結果的複用能力。

　　避免濫用分層，對冗餘的分層、中間表進行合併，減少任務排程鏈路的層級，減少Job數量，節省Job的啟動時間。

　　3）任務最佳化。透過調整引數設定、SQL邏輯最佳化的方式對具體任務進行最佳化需要最佳化的任務。這一步驟的工作也就是傳統認知中的任務最佳化。

　　其中第二步和第三步就是基於本文中的方案快速定位到問題任務，整體最佳化後的效果如下：

　　酒店訂單明細寬表的7日平均產出時間由2:51提前到1:36，提升45%

　　全流程任務總數量從211個降到145個，減少32%

　　可控上游依賴任務(非外BU任務)總數量由180降到117，減少35%

　　關鍵鏈路排程層級由11層減少到6層，且其中兩層是外部BU任務

　　 五、展望

　　基於後設資料和血緣建設，本方案後續有如下三點可以深入最佳化：

　　跨多層判斷重複依賴。由於上述實際案例中的酒店訂單流程相對不復雜，在僅進行一層的重複依賴判斷後，就已經達到了比較滿意的最佳化效果，所以為繼續進行多層重複依賴的判斷，但從血緣結構上是可以支援多層判斷的。

　　定位多Job中重複/相似邏輯。多個任務依賴同一個上游任務，可以人工進行判斷是否存在可合併的重複/相似邏輯；這一點如果要提升效率，需要再結合表的血緣關係一起判斷。

　　多資料流程的最佳化。在數倉的工作中，一個主題域產出的結果表，通常會存在多張，在進行整個主題域流程的最佳化或者重構中，也可以利用本案的思想，結構化進行最佳化工作，提升效率。