作者簡介

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

一、背景

元數(shù)據(jù)MetaData狹義的解釋是用來描述數(shù)據(jù)的數(shù)據(jù)，廣義的來看，除了業(yè)務邏輯直接讀寫處理的那些業(yè)務數(shù)據(jù)，所有其它用來維持整個系統(tǒng)運轉所需的信息／數(shù)據(jù)都可以叫作元數(shù)據(jù)。比如數(shù)據(jù)表格的Schema信息，任務的血緣關系，用戶和腳本／任務的權限映射關系信息等等。

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

數(shù)據(jù)及時性，顧名思義就是測試數(shù)據(jù)需要按時產(chǎn)出。及時性重點關注的三個要素是：定時調度時間、數(shù)據(jù)任務優(yōu)先級以及數(shù)據(jù)產(chǎn)出deadline。其中任務的優(yōu)先級決定了它獲取數(shù)據(jù)計算資源的多少，影響了任務執(zhí)行時長。數(shù)據(jù)deadline則是數(shù)據(jù)最晚產(chǎn)出時間的統(tǒng)一標準，需要嚴格遵守。這三要素中，屬于業(yè)內(nèi)統(tǒng)一認知且在質量保障階段需要重點關注的是：數(shù)據(jù)deadline，這也是我們優(yōu)化數(shù)據(jù)流程產(chǎn)出的最終評判標準。

二、問題

上述部分已經(jīng)闡述了數(shù)據(jù)及時性的重要性和評判標準，在通常情況下，為了提升數(shù)據(jù)及時性，需要投入人力對重點數(shù)據(jù)流程進行優(yōu)化。

但針對數(shù)據(jù)倉庫業(yè)界來講，對于一個重要的數(shù)據(jù)結果，其上游可能存在幾十個層級，數(shù)百個不同的數(shù)據(jù)處理任務，從最初的數(shù)據(jù)到最終的結果，數(shù)據(jù)流轉過程極其復雜，傳統(tǒng)的通過人工逐個排查的方式去定位影響數(shù)據(jù)流程產(chǎn)出的問題節(jié)點，存在如下的三項缺點：

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

2）效率低下，判斷標準不統(tǒng)一，判定準確率不高；

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

如果數(shù)據(jù)流程未能充分優(yōu)化，一方面會存在數(shù)據(jù)結果產(chǎn)出時間不穩(wěn)定，影響數(shù)據(jù)的及時性；另一方面也會造成計算資源和存儲資源的浪費，并且也不易于后續(xù)維護。

三、方案

為了避免上述的問題，提升數(shù)據(jù)流程優(yōu)化的效率和質量，我們采用了從血緣元數(shù)據(jù)出發(fā)的方案。在數(shù)倉任務的執(zhí)行中，都會依賴于一個調度系統(tǒng)組件，目前業(yè)內(nèi)通用的是以DAG為核心的工作流系統(tǒng)，數(shù)據(jù)流程中的每個任務都會設置定時執(zhí)行或者配置上游依賴，這些設置的上游依賴就是我們方案中需要的調度血緣的元數(shù)據(jù)。

基于上述的血緣數(shù)據(jù)，我們的方案中需要實現(xiàn)以下兩個功能：

• 基于任務之間的血緣關系生成所有上游任務的層級依賴數(shù)據(jù)

以調度系統(tǒng)本身的元數(shù)據(jù)作為出發(fā)點，調度系統(tǒng)自身的元數(shù)據(jù)就包含了一個任務的上游和下游依賴，基于這個數(shù)據(jù)，通過層級遞歸的掃描，就可以得到指定根節(jié)點任務的所有上游任務的層級依賴結果。

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

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

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

2）定位重復依賴：在較復雜的數(shù)據(jù)流程中，會出現(xiàn)如下的情況：JobB2依賴JobB1和JobB，而JobB1也同時依賴JobB，簡化后的情況如下圖：

此時我們就可以檢查JobB2的邏輯，考慮任務內(nèi)容中涉及到JobB的邏輯合并到JobB1，從而可以實現(xiàn)流程依賴和代碼邏輯的合并優(yōu)化，降低維護成本，提升整體產(chǎn)出時間。

3）定位關鍵路徑:在完成上述兩個步驟后，整個流程從結構上已經(jīng)基本沒問題，如果要進一步優(yōu)化產(chǎn)出時間，需要針對特定任務進行調優(yōu)，此時可以基于已有的上游層級依賴數(shù)據(jù)，計算得到每個層級的最晚產(chǎn)出的任務Id，這些任務Id串聯(lián)在一起就是影響整個流程產(chǎn)出的關鍵路徑，然后對關鍵路徑上的任務進行調優(yōu)。

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

四、案例

在對酒店訂單明細寬表的優(yōu)化過程中，基于前期的元數(shù)據(jù)建設，主要的工作內(nèi)容分為以下三個步驟：

1）調度優(yōu)化。調度優(yōu)化的出發(fā)點是合理分配同步任務的優(yōu)先級，將非核心任務的數(shù)據(jù)同步延后。從而降低0到2點，酒店訂單寬表核心流程執(zhí)行期間的集群資源壓力。

2）模型優(yōu)化。在這一步驟中，我主要是從兩個方向出發(fā)：

• 減少跨層級重復依賴，避免相似邏輯代碼的出現(xiàn)，提升數(shù)據(jù)結果的復用能力。
• 避免濫用分層，對冗余的分層、中間表進行合并，減少任務調度鏈路的層級，減少Job數(shù)量，節(jié)省Job的啟動時間。

3）任務優(yōu)化。通過調整參數(shù)設置、SQL邏輯優(yōu)化的方式對具體任務進行優(yōu)化需要優(yōu)化的任務。這一步驟的工作也就是傳統(tǒng)認知中的任務優(yōu)化。

其中第二步和第三步就是基于本文中的方案快速定位到問題任務，整體優(yōu)化后的效果如下：

• 酒店訂單明細寬表的7日平均產(chǎn)出時間由2:51提前到1:36，提升45%
• 全流程任務總數(shù)量從211個降到145個，減少32%
• 可控上游依賴任務(非外BU任務)總數(shù)量由180降到117，減少35%
• 關鍵鏈路調度層級由11層減少到6層，且其中兩層是外部BU任務

五、展望

基于元數(shù)據(jù)和血緣建設，本方案后續(xù)有如下三點可以深入優(yōu)化：

• 跨多層判斷重復依賴。由于上述實際案例中的酒店訂單流程相對不復雜，在僅進行一層的重復依賴判斷后，就已經(jīng)達到了比較滿意的優(yōu)化效果，所以為繼續(xù)進行多層重復依賴的判斷，但從血緣結構上是可以支持多層判斷的。
• 定位多Job中重復/相似邏輯。多個任務依賴同一個上游任務，可以人工進行判斷是否存在可合并的重復/相似邏輯；這一點如果要提升效率，需要再結合表的血緣關系一起判斷。
• 多數(shù)據(jù)流程的優(yōu)化。在數(shù)倉的工作中，一個主題域產(chǎn)出的結果表，通常會存在多張，在進行整個主題域流程的優(yōu)化或者重構中，也可以利用本案的思想，結構化進行優(yōu)化工作，提升效率。