來看看字節跳動內部的數據血緣用例與設計

數據血緣描述了數據的來源和去向，以及數據在多個處理過程中的轉換。數據血緣是組織內使數據發揮價值的重要基礎能力。本文從字節的數據鏈路概況開始，介紹了數據血緣在字節的應用場景，總體設計，數據模型以及衡量指標。

文 | 羅小亮、拾捌、大濱來自字節跳動數據平台開發套件團隊

字節跳動數據鏈路介紹

為了明確問題的討論范圍，我們首先介紹一下字節的數據鏈路。

字節的數據的來源分為兩種：

• 端數據：APP 和 Web 端通過埋點 SDK 發送的，經過 LogService，最終落入 MQ；

• 業務數據：APP，Web 和第三方服務所進行的業務操作，通過各種應用的服務，最終落入 RDS，RDS 中的數據，經過 Binlog 的方式，匯入 MQ；

MQ 中的數據，在 MQ 之間有分流的過程，做轉換格式，流量拆分等。

離線數倉的核心是 Hive，數據通過各種手段最終匯入其中，使用主流的 HiveSQL 或 SparkJob 做業務處理，流入下游 Clickhouse 等其他存儲。

實時數倉的核心是 MQ，使用主流的 FlinkSQL 或通用 FlinkJob 做處理，期間與各種存儲做 SideJoin 豐富數據，最終寫入各種存儲。

典型的數據出口有三類：

• 指標系統：業務屬性強烈的一組數據，比如“抖音日活”

• 報表系統：以可視化的形式，各種維度展示加工前或加工后的數據

• 數據服務：以 API 調用的形式進一步加工和獲取數據

在字節，數據血緣的系統邊界是：從 RDS 和 MQ 開始，一路途徑各種計算和存儲，最終匯入指標、報表和數據服務系統。

血緣的應用場景

在討論技術細節之前，需要先講清楚血緣的應用場景與業務價值，進一步明確數據血緣需要解決的問題。不同的應用場景，對於血緣數據的消費方式，血緣的覆蓋范圍，血緣的質量訴求，都會有所差別。

數據血緣系統的整體設計

01 - 概覽

通過對字節血緣鏈路和應用場景的討論，可以總結出血緣整體設計時需要考慮的兩個關鍵點：

• 可擴展性：在字節，業務復雜而龐大，整條數據鏈路中，使用到的各種存儲有幾十種，細分的任務類型也是幾十種，血緣系統需要可以靈活的支持各種存儲和任務類型

• 開放的集成方式：消費血緣時，有實時查詢的場景，也有離線消費的場景，還有可能下游系統會基於當前數據做擴展
  

字節數據血緣系統的整體架構可以分為三部分：

• 任務接入：以某種方式，從任務管理系統中獲取任務信息

• 血緣解析：通過解析任務中的信息，獲取到血緣數據

• 數據導出：負責將血緣數據存儲到 Data Catalog 系統中，並供下游系統消費

02 - 任務接入

有兩個關鍵的設計考慮：

提供兩種可選的鏈路，以應對不同下游系統對於數據實時性的不同要求：

• 近實時鏈路：任務管理系統將任務的修改的消息寫入 MQ，供血緣模塊消費

• 離線鏈路：血緣模塊周期性的調用任務管理系統的 API 接口，拉取全量（或增量）任務信息，進行處理

定義統一的 Task 模型，並通過 TaskType 來區分不同類型任務，確保后續處理的可擴展性：

• 不同任務管理系統，可能管理相同類型的任務，比如都支持 FlinkSQL 類型的任務；同一任務管理系統，有時會支持不同類型的任務，比如同時支持編寫 FlinkSQL 和 HiveSQL

• 新增任務管理系統或者任務類型，可以添加 TaskType

03 - 血緣解析

有兩個關鍵的設計考慮：

定義統一的血緣數據模型 LineageInfo

針對不同的 TaskType，靈活定制不同的解析實現，也支持不同 TaskType 可服用的兜底解析策略。比如：

• SQL 類任務：比如 HiveSQL 與 FlinkSQL，會調用 SQL 類的解析服務

• Data Transfer Service（DTS）類：解析任務中的配置，建立源與目標之間的血緣關系

• 其他類任務：比如一些通用任務會登記依賴和產出，報表類系統的控制面會提供報表來源的庫表信息等

04 - 數據導出

血緣解析所產出的 LineageInfo，會首先送入 DataCatalog 系統，支持三種集成方式：

• 對於 Data Catalog 中血緣相關 API 調用，實時拉取需要的血緣數據

• 消費 MQ 中的血緣修改增量消息，以近實時能力構造其他周邊系統

• 消費數倉中的離線血緣導出數據，做分析梳理等業務

血緣的數據模型

血緣數據模型的定義，是確保系統可擴展性和方便下游消費集成的關鍵設計之一。

01 -概覽

我們以圖的數據模型來建模整套血緣系統。圖中包含兩類節點和兩類邊：

• 數據節點：對於存儲數據的介質的抽象，比如一張 Hive 表，或者是 Hive 表的一列

• 任務節點：對於任務（或鏈路）的抽象，比如一個 HiveSQL 腳本

• 從數據節點指向任務節點的邊：代表一種消費關系，任務讀取了這個數據節點的數據

• 從任務節點指向數據節點的邊：代表一種生產關系，任務生產了這個數據節點的數據

將任務節點和數據節點統一到一張圖上的 2 點優勢：

• 將血緣的生命周期與任務的生命周期統一，通過更新任務關聯的邊來更新血緣關系

• 可以靈活的支持從任務切入和從數據節點切入的不同場景。比如數據資產領域從數據節點切入的居多，而數據開發領域從任務切入的場景居多，不同的應用場景可以在一張大圖上靈活遍歷

02 - 字段（Column）級血緣

字段血緣是血緣模型中的邊界情況，單獨拿出來簡單討論。在實現時，有兩種可供選擇的思路：

我們最終采用了第 2 種方案。

血緣衡量指標

實際推廣血緣時，最常被用戶問到的問題就是，血緣質量怎么樣，他們的場景能不能用。面對這種靈魂拷問，每個用戶都單獨評估一遍的開銷過大，所以我們花了很多精力討論探索出了最常用的三個技術指標，以佐證血緣質量。用戶可以根據這些指標，判斷自己的場景是否適用。

01 - 准確率

定義：假設一個任務實際的輸入和產出與血緣中該任務的上游和下游相符，既不缺失也不多余，則認為這個任務的血緣是准確的，血緣准確的任務占全量任務的比例即為血緣准確率。

准確率是用戶最關注的指標，像數據開發的影響分析場景，血緣的缺失有可能會造成重要任務沒有被通知，造成線上事故。

不同類型的任務，血緣解析的邏輯不同，計算准確率的邏輯也有區別：

• SQL 類任務：比如 HiveSQL 和 FlinkSQL 任務，血緣來源於 SQL 的解析，當 SQL 解析服務給出的質量保證是，成功解析的 SQL 任務，產生的血緣關系就一定是准確的，那么這類任務的血緣准確率，就可以轉化成 SQL 解析的成功率。

• 數據集成（DTS）類任務：比如 MySQL->Hive 這類通道任務，血緣來源於對用戶登記上下游映射關系的配置，這類血緣的准確率，可以轉化成對於任務配置解析的成功率。

• 腳本類任務：比如 shell，python 任務等，這些血緣來源於用戶登記的任務產出，這類血緣的准確率，可以轉化成登記產出中正確的比例。

注意一個問題，上面所講的准確率計算，轉化的時候都有一個前提假設，是程序按照我們假定的方式運行，實際情況並不一定總是這樣。其實這件事情沒必要特別糾結，血緣就像我們在運行的其他程序一樣，都可能因程序 bug，環境配置，邊界輸入等，產生不符合預期的結果。

作為准確率的補充，我們在實踐中通過三種途徑，盡早發現有問題的血緣：

• 人工校驗：通過構造測試用例來驗證其他系統一樣，血緣的准確性問題也可以通過構造用例來驗證。實際操作時，我們會從線上運行的任務中采樣出一部分，人工校驗解析結果是否正確，有必要的時候，會 mock 掉輸出，持續運行校驗。

• 埋點數據驗證：字節中的部分存儲會產生訪問埋點數據，通過清洗這些埋點數據，可以分析出部分場景的血緣鏈路，以此來校驗程序中血緣產出的正確性。比如，HDFS 的埋點數據可以用來校驗很多 Hive 相關鏈路的血緣產出。

• 用戶反饋：全量血緣集合的准確性驗證是個浩瀚的過程，但是具體到某個用戶的某個業務場景，問題就簡化多了。實際操作中，我們會與一些業務方深入的合作，一起校驗血緣准確性，並修復問題。

02 - 覆蓋率

定義：當至少有一條血緣鏈路與資產相關時，稱為資產被血緣覆蓋到了。被血緣覆蓋到的資產占關注資產的比例即為血緣覆蓋率。

血緣覆蓋率是比較粗粒度的指標。作為准確率的補充，用戶通過覆蓋率可以知道當前已經支持的資產類型和任務類型，以及每種覆蓋的范圍。

在內部，我們定義覆蓋率指標的目的有兩個，一是圈定出我們比較關注的資產集合，二是尋找系統中缺失的整塊的任務類型。

以 Hive 表為例，字節生產環境的 Hive 表已經達到了幾十萬級別，其中有很大一部分，是不會被長期使用與關注的。計算血緣覆蓋率時，我們會根據規則圈選出其中的部分，比如，過去 7 天有數據寫入的，作為分母，在這之上，看血緣覆蓋率是多少。

當血緣覆蓋率低時，通常說明我們漏掉了某種任務類型或者圈選的資產范圍不合理。舉個例子，在初期時，我們發現 MQ 的血緣覆蓋率只有個位數，分析后發現，我們漏掉了以另外一種格式定義的流式數據集成任務。

03 - 時效性

定義：從任務發生修改，到最終反應到血緣存儲系統的端到端延時。

對於一些用戶場景來說，血緣的時效性並沒有特別重要，屬於加分項，但是有一些場景是強依賴。不同任務類型的時效性會有差異。

數據開發領域的影響分析場景，是對血緣實時性要求很高的場景之一。用戶在圈定修改的影響范圍時，如果只能拉取到昨天為止的狀態，是會產生嚴重業務事故的。

提升時效性的瓶頸，通常不在血緣服務方，而是任務管理系統是否可以近實時的將任務相關的修改，以通知形式發送出來。

未來

文中闡述的部分數據血緣技術已經通過火山引擎大數據研發治理套件 DataLeap 對外開放。

接下來，字節跳動數據平台在數據血緣方面的工作，會主要集中在三個方向：

• 首先，是持續提升血緣的准確性。當前我們的血緣准確性已經提升到了可用的狀態，但是依然需要人工的校驗與修復。如何持續穩定的提升准確性，是探索的重要方向。

• 其次，是血緣的標准化建設。除了數據血緣之外，應用級別的血緣其實也很重要，在解決方案上，我們希望做到通用與標准。當前業務方會基於數據血緣拼接一些自己業務領域的鏈路，完成標准化后，這部分用例可以復用整套基礎設施，定制產品層面的展現就好了。

• 最后，是加強對外部生態的支持。細分下來有兩個方向，一是探索通用的 SQL 類血緣解析引擎，當前，新接入一種 SQL 類的引擎血緣，成本是比較高的；二是支持開源或公有雲上產品的端到端血緣。

相關產品

火山引擎大數據研發治理套件DataLeap

一站式數據中台套件，幫助用戶快速完成數據集成、開發、運維、治理、資產、安全等全套數據中台建設，幫助數據團隊有效的降低工作成本和數據維護成本、挖掘數據價值、為企業決策提供數據支撐。

歡迎關注字節跳動數據平台同名公眾號