大廠的數據質量中心系統設計

日常工作中，數據開發上線完一個任務後並不是就可以高枕無憂，時常因上游鏈路數據異常或者自身處理邏輯的 BUG 導致產出的數據結果不可信。而問題發現可經歷較長周期（尤其離線場景），往往是業務方通過上層數據報表發現數據異常後 push 數據方去定位問題（對於一個較冷的報表，這個周期可能會更長）。

由於數據加工鏈路較長，需藉助數據血緣關係逐個任務排查，也會導致問題定位難度增大，嚴重影響開發效率。如數據問題未及時發現，可能導致業務方作出錯誤決策。此類問題可統一歸屬為大數據領域數據質量問題。本文將向大家介紹伴魚基礎架構數據團隊在應對該類問題時推出的平臺化產品-數據質量中心的設計與實現。

1 調研

業內數據質量平臺化產品介紹不多，主要對兩個開源產品和一個雲平臺產品進行調研。

1.1 Apache Griffin

Apache Griffin，eBay 開源基於 Apache Hadoop 和 Apache Spark 的數據質量服務平臺。

1.1.1 架構圖

數據質量平臺的核心流程：

• Define：數據質檢規則（指標）的定義
• Measure：數據質檢任務的執行，基於 Spark 引擎實現
• Analyze：數據質檢結果量化及可視化展示

平臺對數據質檢規則進行了分類（業內普遍認可的數據質量的六大標準）:

• Accuracy：準確性。如是否符合表的加工邏輯
• Completeness：完備性。如數據是否存在丟失
• Timeliness：及時性。如表數據是否按時產生
• Uniqueness：唯一性。如主鍵欄位是否唯一
• Validity：合規性。如欄位長度是否合規、枚舉值集合是否合規
• Consistency：一致性。如表與表之間在某些欄位上是否存在矛盾

該項目僅在 Accuracy 類的規則上實現。Griffin是完全閉環的平臺化產品。質檢任務執行依賴內置定時調度器的調度，調度執行時間由用戶在 UI 上設定。任務將通過 Apache Livy 組件提交至配置的 Spark 集群。即質檢實時性難保，無法強行阻斷產出異常數據的任務，二者不是在同一調度平臺被調度，時序也不能保持串列。

1.2 Qualitis

Qualitis，微眾銀行開源的一款數據質量管理系統。同樣，它提供了一整套統一的流程來定義和檢測數據集的質量並及時報告問題。從整個流程上看我們依然可以用 Define、Measure 和 Analyze 描述。它是基於其開源的另一款組件 Linkis 進行計算任務的代理分發，底層依賴 Spark 引擎，同時可以與其開源的 DataSphereStudio 任務開發平臺無縫銜接，也就實現了在任務執行的工作流中嵌入質檢任務，滿足質檢時效性的要求。可見，Qualitis 需藉助微眾銀行開源一系列產品才好用。

1.3 DataWorks 數據質量

DataWorks，阿裡雲提供一站式大數據工場，包括數據質量在內的產品解決方案。實現依賴阿裡雲其他產品組件支持。DataWorks 數據質量部分的使用介紹從產品形態上給了我們很大的幫助，對我們產品設計有指導性作用。

2 設計目標

• 暫只支持離線部分數據質量管理
• 支持通用規則描述和規則管理
• 質檢任務由公司內部統一的調度引擎調度執行，可支持對質檢結果異常的任務進行強阻斷。同時，儘量降低質檢功能對調度引擎的代碼侵入
• 支持質檢結果可視化

3 系統設計

3.1 背景

離線調度開發平臺基於 Apache Dolphinscheduler（簡稱DS）實現，分散式去中心化，易擴展的可視化 DAG 調度系統，支持包括 Shell、Python、Spark、Flink 等多種類型的 Task 任務，並具有很好的擴展性。

3.2 架構

Master 節點負責任務的監聽和調度，Worker 節點則負責任務的執行。值得註意的是，每一個需要被調度的任務必然需要設置一個調度時間的表達式（cron 表達式），由 Quartz 定時為任務生成待執行的 DAG Command，有且僅有一個 Master 節點獲得執行權，掌管該 DAG 各任務節點的調度執行。

3.3 整體架構

平臺整體架構圖：

• DQC Web UI：質檢規則等前端操作頁
• DQC(GO)：簡單的實體元數據管理後臺。主要包括：規則、規則模板、質檢任務和質檢結果幾個實體。
• DS(數據質量部分)：質檢任務依賴 DS 調度執行，需要對 DS 進行一定的改造。
• DQC SDK(JAR)：DS 調度執行任務時，檢測到任務綁定了質檢規則，將生成一類新的任務 DQC Task （與 DS 中其他類型的 Task 同級，DS 對於 TasK 進行了很好的抽象可以方便擴展），本質上該 Task 將以腳本形式調用執行 DQC SDK 的邏輯。DQC SDK 涵蓋了規則解析、執行的全部邏輯。

各模塊設計權衡。

4 規則表述

4.1 標準與規則

業界數據質量有六大標準，但：

• 如何將標準與平臺的規則對應起來？
• 標準中涉及到的現實場景是否我們可以一一枚舉？
• 即便可將標準一一細化，數據開發人員是否可輕鬆理解？

可將這些問題統一歸類為：平臺在規則設定上是否需要和業界數據質量標準所抽象出來的概念進行綁定。很遺憾沒找到有關數據質量標準更細化和指導性的描述，作為一個開發，這些概念比較費解，更貼近程式員視角是「show me the code」，因此我們決定將這一層概念弱化。未來實踐過程後再細思。

4.1.1 標量化

如何對規則提供一種通用描述（or DSL）？

跳脫出前文所描述一切背景和概念，仔細思考數據質檢過程，本質就是通過一次真實的任務執行產出結果，對比輸出結果與期望是否滿足，以驗證任務邏輯正確性。和 Unit Testing 類比:

• Unit Testing 是通過模擬數據構造的一次代碼邏輯的執行
• 數據任務執行產生的結果是一張二維結構的 Hive 表，需加工才能獲取想要的統計結果

據此，可用 Unit Testing 概念從以下深入：

① Actual Value

數據任務執行產出結果是一張 Hive 表，要對這張 Hive 表數據加工、提取以獲得需要Actual Value。涉及 Hive 表加工，就想到以 SQL 實現，通過 Query 和 一系列 Aggregation 拿到結果，此結果結構又可分為：

• 二維數組
• 單行或單列的一維數組
• 單行且單列的標量

顯然單行且單列標量是期望，因為易於結果比較（就目前能想到的規則，都可通過 SQL 提取為一個標量結果）。因此，規則設計中，需要規則創建者輸入一段用於結果提取的 SQL，該段 SQL 執行結果需要為一個標量。

② Expected Value

既然 Actual Value 是標量，Expected Value 也是標量，需要規則創建者在平臺輸入。

③ Assert

上述標量的類型決定斷言比較方式。目前只支持數值型標量的比較方式，包含「大於」、「等於」及「小於」三種比較運算元。

三要素即可完整的描述規則想要表達的核心邏輯。如表述「欄位為空異常」規則（潛在含義：欄位為空的行數大於 0 時判定異常）：

• Actual Value ：出現欄位為空的行數
• Expected Value：0
• Assert： 「大於」

4.2 規則管理

4.2.1 規則模板

為了規則復用抽象出的一個概念，模板中包含規則的 SQL 定義、規則的比較方式、參數定義（註：SQL 中包含一些占位符，這些占位符將以參數的形式被定義，在規則實體定義時需要用戶明確具體含義）以及其他的一些元信息。

「欄位空值的行數」模板示例：

4.2.2 規則實體

基於規則模板構建，是規則的具象表達。

在規則實體中將明確規則的 Expected Value、比較方式中具體的比較運算元、參數的含義以及其他的一些元信息。基於同一個規則模板，可構造多個規則實體。

「某表 user_id 唯一性校驗」規則示例：

規則可能不僅針對單表校驗，多表case，這套規則模板同樣適用，只要能將邏輯用 SQL 表達。

4.3 規則綁定

在 DS 的前端交互上支持為任務直接綁定校驗規則，規則列表通過 API 從 DQC 獲取，這種方式在用戶的使用體驗上存在一定的割裂（規則創建和綁定在兩個平臺完成）。同時，在 DQC 的前端亦可以直接設置關聯調度，為已有任務綁定質檢規則，任務列表通過 API 從 DS 獲取。同一個任務可綁定多個質檢規則，這些信息將存儲至 DS 的 DAG 元信息中。但是：

• 規則的哪些信息應該存儲至 DAG 的元信息中？
• 規則的更新 DAG 元信息是否可實時同步？

主要有兩種方式：

• 大JSON將規則信息打包存儲，計算時解析 JSON 逐個執行校驗。在規則更新時，需要同步調用修改 JSON 信息
• List 存儲規則 ID，計算時需執行一次 Pull 操作獲取規則具體信息然後執行校驗。規則更新，無須同步更新 List 信息

最終選型後者，ID List可使對 DS 侵入最低。

4.4 規則執行

強規則和弱規則

規則的強弱性質由用戶為任務綁定規則時設定，此性質決定了規則執行的方式。

強規則

和當前所執行的任務節點同步執行，一旦規則檢測失敗整個任務節點將置為執行失敗的狀態，後續任務節點的執行會被阻斷。對應 DS 中的執行過程：

• Step1：某一個 Master 節點獲取 DAG 的執行權，將 DAG 拆分成不同的 Job Task 先後下發給 Worker 節點執行。
• Step2：執行 Job Task 邏輯，並設置 Job Task 的 ExitStatusCode。
• Step3：判斷 Job Task 是否綁定了強規則。若是，則生成 DQC Task 並觸發執行，最後根據執行結果修正 Job Task 的 ExitStatusCode。
• Step4：Master 節點根據 Job Task 的 ExitStatusCode 判定任務是否成功執行，繼續進入後續的調度邏輯。

弱規則

和當前所執行的任務節點非同步執行，規則檢測結果對於原有的任務執行狀態無影響，從而也就不能阻斷後續任務的執行。對應 DS 中的執行過程：

• Step1：某一個 Master 節點獲取 DAG 的執行權，將 DAG 拆分成不同的 Job Task 先後下發給 Worker 節點執行。
• Step2：執行 Job Task 邏輯，並設置 Job Task 的 ExitStatusCode。
• Step3：判斷 Job Task 是否綁定了弱規則。若是，則在 Job Task 的 Context 中設置弱規則的標記 。
• Step4：Master 節點根據 Job Task 的 ExitStatusCode 判定任務是否成功執行，若成功執行再判定是否 Context 中帶有弱規則標記，若有則生成一個新的 DAG（有且僅有一個 DQC Task，且新生成的 DAG 與 當前執行的 DAG 沒有任何的關聯） 然後繼續進入後續的調度邏輯。
• Step5：各 Master 節點競爭新生成的 DAG 的執行權。

可以看出在強弱規則的執行方式上，對 DS 調度部分的代碼有一定的侵入，但這個改動不大，成本是可以接受的。

DQC Task & DQC SDK

上文提及到一個 Job Task 綁定的規則（可能有多個）將被轉換為一個 DQC Task 被 DS 調度執行，接下來我們就討論下 DQC Task 的實現細節以及由此引出的 DQC SDK 的設計和實現。

DQC Task 繼承自 DS 中的抽象類 AbstractTask，只需要實現抽象方法 handle（任務執行的具體實現）即可。那麼對於我們的質檢任務，實際上執行邏輯可以拆分成以下幾步：

• 提取 Job Task 綁定的待執行的 Rule ID List。
• 拉取各個 Rule ID 對應的詳情信息。
• 構建完整的執行 Query 語句（將規則參數填充至模板 SQL 中）。
• 執行 Query。
• 執行 Asset。

最核心的步驟為 Query 的執行。Query 的實現方式又可分為兩種：

Spark 實現

• 優點：實現可控，靈活性更高。
• 缺點：配置性要求較高。

Presto SQL 實現

• 優點：不需要額外配置，開發量少，拼接 SQL 即可。
• 缺點：速度沒有 Spark 快。

選擇後者，最易實現，離線場景計算耗時也可接受。同時由於一個 DQC Task 包含多條規則，在拼接 SQL 時將同表的規則聚合以減少 IO 次數。不同的 SQL 交由不同的線程並行執行。

上述執行邏輯其實是一個完整且閉環的功能模塊，因此我們想到將其作為一個單獨的 SDK 對外提供，並以 Jar 包的形式被 DS 依賴，後續即便是更換調度引擎，這部分的邏輯可直接遷移使用（當然概率很低）。那麼 DS 中 DQC Task 的 handle 邏輯也就變得異常簡單，直接以 Shell 形式調用 SDK ，進一步降低對 DS 代碼的侵入。

4.5 執行結果

單條規則的質檢結果將在平臺上直接展現，目前我們還未對任務級的規則進行聚合彙總，這是接下來需要完善的。對於質檢失敗的任務將向報警接收人發送報警。

實踐中的問題

平臺解決了規則創建、規則執行的問題，而在實踐過程中，對用戶而言更關心：

• 一個任務應該需要涵蓋哪些的規則才能有效地保證數據的質量？
• 我們不可能對全部的表和欄位都添加規則，那麼到底哪些是需要添加的？

這些是很難通過平臺自動實現的，因為平臺理解不了業務的信息，平臺能做的只能是通過質量檢測報告給與用戶反饋。因此這個事情需要具體的開發人員對核心場景進行梳理，在充分理解業務場景後根據實際情況進行設定。話又說回來，平臺只是工具，每一個數據開發人員應當提升保證數據質量的意識，這又涉及到組織內規範落地的問題了。

5 規劃

數據質量管理是一個長期的過程，未來在平臺化方向我們還有幾個關鍵的部分有待繼續推進：

• 基於血緣關係建立全鏈路的數據質量監控。當前的監控粒度是任務級的，如果規則設置的是弱規則，下游對於數據問題依舊很難感知
• 數據質量的結果量化。需建立一套指標用於定量衡量數據質量
• 支持實時數據的質量檢測

關註我，緊跟本系列專欄文章，咱們下篇再續！

作者簡介：魔都技術專家兼架構，多家大廠後端一線研發經驗，各大技術社區頭部專家博主，編程嚴選網創始人。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。

負責：

• 中央/分銷預訂系統性能優化
• 活動&優惠券等營銷中台建設
• 交易平臺及數據中台等架構和開發設計

目前主攻降低軟體複雜性設計、構建高可用系統方向。

參考：

• 編程嚴選網

本文由博客一文多發平臺 OpenWrite 發佈！