作者簡介

九號，攜程數據技術專家，關注數據倉庫架構、數據湖、流式計算、數據治理。

一、背景

元數據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中重復/相似邏輯。多個任務依賴同一個上游任務，可以人工進行判斷是否存在可合并的重復/相似邏輯；這一點如果要提升效率，需要再結合表的血緣關系一起判斷。
• 多數據流程的優化。在數倉的工作中，一個主題域產出的結果表，通常會存在多張，在進行整個主題域流程的優化或者重構中，也可以利用本案的思想，結構化進行優化工作，提升效率。