火山引擎數據調度實例的 DAG 優化方案

1. 實例 DAG 介紹

DataLeap 是火山引擎自研的一站式大數據中臺解決方案，集數據集成、開發、運維、治理、資產管理能力於一身的大數據研發治理套件。在平臺中，一個核心的功能爲任務的調度，會根據任務設置的調度頻率（月級，日級，小時級等）運行任務，從而生成對應的實例。

在數倉研發中，不同的表之間會存在依賴關係，而產生表數據的任務實例，也會因此存在依賴關係。只有在上游實例運行成功、下游實例到達設定的運行時間且資源充足的情況下，下游實例纔會開始執行。所以，在日常的任務運維中，常常需要分析實例上下游的運行情況，根據具體的情況對實例進行置成功、重跑等操作。

而如何清晰地展示實例之間的關係，幫助用戶快速地分析整個鏈路的運行情況，並完成問題定位和運維操作，則是實例 DAG 需要解決的問題。下面對比下優化前後的效果。

優化前：

可以看到在複雜鏈路中，將所有節點的關係全部展示出來，導致連線混亂，需要通過不停的拖拽、縮放，才能找到沒有執行的上游節點。

優化後：

通過採用了將節點聚合的形式，簡潔地展示上下游關係。同時，採用了將實例狀態進行分類的形式，提供快捷操作的按鈕，讓用戶可以只關注特定狀態的實例，減少了無用信息對用戶運維操作的干擾。下面將詳細介紹優化的整體過程。

1.1 概念

  1. 任務：在 DataLeap 數據研發平臺中，對數據執行一系列操作的定義。

  2. 實例：通過任務配置的執行頻率（月級、天級等）而創建的一個任務的快照。

  3. DAG：全稱爲 Directed Acyclic Graph，指有向無環圖，具備嚴密的拓撲性質，有很強的流程表達能力。

  4. DAG 佈局：指根據有向無環圖中邊的方向，自動計算節點層級和位置的佈局算法。

1.2 業務場景

以其中一個場景爲例：

對於任務 test_3 在 2022-09-29 的實例進行分析可知。當前實例沒有運行，是由於上游任務 test_2 在 2022-09-29 的實例運行失敗導致的，那麼此時可聯繫上游實例對應的任務的負責人，對實例進行處理（包括但不限於重跑，置成功等操作）。

2. 問題

在當前的實例 DAG 圖中，用戶在實際使用中會碰到如下問題：

  1. 複雜的實例 DAG 圖無法渲染。

    在一些業務方向中，會出現 DAG 圖中有幾千節點。由於數據處理的複雜和採用了 svg 的渲染方案，常常會導致前端瀏覽器的崩潰。

  2. 同層級節點過多，操作困難。

    以下圖爲例，在分析上游實例中，是哪個實例沒有運行，導致當前實例沒有執行時，需要通過連續拖拽，才能定位到關注的上游實例。

  1. 查看節點依賴時，只能不斷展開，在對不同的上游依賴進行展開時，會導致圖展示混亂。

3.  需求分析

在通過用戶調研及使用過程中發現，使用 DAG 進行分析時主要有以下場景：

  1. 當前實例已經到達指定運行時間，但是沒有運行。

    在這種情況下，用戶關注的是上游沒有運行的實例 / 運行失敗的實例，聯繫上游實例的責任人進行問題定位。

  2. 當實例已經運行成功，但是完成時間比正常情況下有延遲。

    在這種情況下，用戶關注的是上游實例中，最晚完成的實例。從而判斷是否對鏈路進行治理優化。

  3. 當實例運行失敗，導致下游沒有運行。

    在這種情況下，用戶關注的是依賴當前實例的所有下游實例，同時需要對下游實例進行聚合篩選，比如任務的優先級（代表任務的核心程度），以通知下游實例進行重跑等操作。

結合上面存在的問題可得到，主要原因是由於在複雜鏈路情況下，上述需求比較難滿足。而在舊版的 DAG 中，針對簡單鏈路和複雜鏈路的處理是一致的，爲此，我們需要設計解決複雜鏈路場景下的方案。

4. 功能設計

針對上面存在的問題以及對需求的分析，我們可以進行如下的功能實現與設計：

4.1 渲染方案替換

將 svg 的渲染方案替換成 canvas 渲染，通過減少頁面中 DOM 的數量，提高前端渲染性能。

4.2 不同場景的功能設計

通過上面的需求分析，我們設計了不同的功能模式以滿足不同的需求。

QWNNfu

4.2.1 通用模式

在通用模式中，用戶關注的是節點上下游的關係，在複雜鏈路中快速找到阻塞節點，同時關注阻塞節點的信息。

針對複雜鏈路，我們設計了多種優化形式：

首先，在同一層的節點超過一定的數量（可自定義）後，所有節點將聚合在一起，我們稱之爲聚合節點。這種優化下，可以解決上面提到的由於同一層級節點過多，查找特定狀態節點不便的問題。也支持點擊聚合詳情，通過列表的形式，查看所有被聚合的節點。並支持篩選，快速查找到關注的節點並通過展開，恢復與當前節點的依賴關係。‍

其次，以用戶最關注的實例狀態，對被聚合的節點進行分類，同時新增快捷展開操作。以下圖爲例，當前實例處於等待上游依賴完成狀態，在這種情況下，用戶關注的，則是上游沒有開始執行的節點。在聚合節點中，可以清晰地看到存在一個實例，是在等待執行的，點擊數字 1，即可快速展開實例。

在這個例子中，就將不需要關注的上游成功節點隱藏在列表中，突出圖所需要關注的重點信息。

同時，爲了降低節點展示過多導致圖顯示雜亂的情況，新增了收起功能及跳轉功能。

收起功能是指在通過在聚合節點展開的節點的情況，或是在直接展開上 / 下游的情況下，都支持對某個上游 / 下游節點的整條鏈路收起，方便用戶在瀏覽完一條鏈路後，恢復圖之前的狀態，繼續瀏覽下一條鏈路，減少對後續分析的干擾。

跳轉功能是在查看當前節點的上游的其他下游，或是下游的其他上游，此時，用戶關注的節點已經轉化爲其他的上游 / 下游節點。所以，通過跳轉新頁面的形式，將需要關注的不同節點的上 / 下游信息區分開，減少在一張圖中展示所有信息。

並且由於圖中的節點承載信息的能力有限，在通過點擊節點時，會在下方出現與選中實例相關信息，包括屬性，日誌等，協助用戶運維任務。

4.2.2 統計模式

在統計模式中，用戶關注的是依賴當前節點的下游節點，下游節點則可以分成直接下游和所有下游。所以設計了分層模式和合並模式，在這兩種模式下，可以按照任務的屬性（任務類型 / 實例狀態 / 責任人等）作爲分組維度。

分層模式：

合併模式：

4.2.3 鏈路模式

指定上游節點，一鍵展示指定節點與當前節點的鏈路信息，從而進行精準鏈路分析。 

5. 技術實現

5.1 數據處理

在原始數據中，是以一個數組的形式返回節點信息及依賴關係。所以，需要對數據進行處理形成圖所需要的數據，同時，利用多個 map 對數據進行存儲，方便後續對數據進行檢索，減少時間複雜度。

5.2 自定義節點註冊

實例節點的樣式需要通過基礎圖形 Text（文本）、Rect（矩形）、Icon（圖標）進行組合，以達到我們的設計要求。

5.3 圖預處理

在前面提到，我們需要在複雜的圖場景中，將超過一定數量的同層節點聚合起來，以達到清晰直觀地傳達圖所要表達的信息的目的，所以需要對圖的層級及節點進行處理，從而生成聚合節點和去掉多餘的節點。

5.4 DAG 圖佈局

通常來說，DAG 的佈局可以按照以下步驟實現。

  1. 去環：包括自環和非自環，爲節點分層做準備。

  2. 節點分層：給所有節點安排合適的層級。

  3. 節點排序：同層級內節點排序，減少相鄰層級中節點連續的交叉點數量。

  4. 節點座標分配：根據分層和同層節點的排序計算節點位置。

而在我們的場景中，節點的層級是有明確含義的，比如在節點 A 處於節點 B 的上方一層，且 A, B 之間有連線連接，則可認爲 A 是 B 的上游一層節點。因此與傳統 DAG 佈局產生了以下不同點，我們需要根據場景做定製。

  1. 節點所在層級固定：DAG 佈局既能支持自動計算層級，也能接受直接指定節點分層。

  2. 可能產生同層級連線：將同一層級裏有連線的節點進行分組，進行內部排序後，視爲整體再參與當前層級的排序，以減少交叉點的數量。

6. 總結

從功能設計上，我們需要從用戶的使用場景出發，區分不同的功能滿足用戶的訴求。同時，在前端領域中，針對大數據量的場景，需要判斷這些大數據量的展示對用戶是否存在價值，從大數據量中挖掘出用戶的關注點並突出重點，方便用戶快速地進行查看分析。

從技術實現上，我們需要結合業務，根據業務的特徵去修改已有的 DAG 佈局實現，以滿足在不同的業務場景下，更好地將信息呈現給用戶。

當然，當前的功能設計也存在不足之處，在當前的上游查看分析功能上，由於數據庫查詢存在瓶頸，只能分析一層的上游，在後續優化查詢性能後，可以通過一鍵分析，直接查找到出現問題的根節點，可以幫助用戶減少操作成本以提高分析效率。

7. 參考

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/TIW1sh_dG_O-jtGoXAqIvQ

猜你喜歡