一、數據全鏈路血緣介紹

在電商場景中，我們建設數據全鏈路血緣的核心目的，是對數據從源頭到終端全過程進行追蹤和管理。

以零售行業舉例，數據包括商品數據、物流信息、用戶反饋等，其全流程包括：

• 通過數據采集，如業務日志、埋點、表格、存儲。
• 經過 ETL 數據加工，包括離線和實時兩種任務。
• 再到數據服務中的物理表、邏輯表，以及服務編排。
• 最后透傳到數據應用，比如接口、頁面、報表、指標等。

在業務發展過程中，我們常常會遇到如下問題：

首先，隨著業務的快速發展，數據不斷膨脹。數據量增大，但數據產生的實際價值在哪里？數據血緣則可以幫助我們更好評估數據價值，并在滿足業務需求的同時，控制存儲計算資源的膨脹速度。與此同時，數據血緣還能夠衡量數倉建設的優劣，并且做好數倉體系化建設。

第二，如何做好數倉變更監控？在數倉的日常開發過程中，我們經常會遇到上下游變更，變更后希望能及時、準確地衡量數據變更的影響。由于數據來源變更豐富，需要通過數據血緣將數據變更及時通知下游關聯方。

第三，數倉研發提效。我們希望通過數據血緣及時完成表重構，理清字段的來源以及加工口徑，并且進行任務精準回溯。

最后，通過數據血緣助力指標體系化建設，保證指標一致性，避免重復開發。在指標體系化建設中，數據血緣可以幫助將新增的指標綁定到已有的指標上。

1. 解決數據不斷膨脹的問題

針對數據膨脹的問題，數據血緣可以明確數據流轉路徑，優化資源配置。血緣關系可以精確衡量數倉對業務的價值，實現數據治理，控制資源膨脹，并且能夠精準地完成影響面評估。

2. 幫助數倉開發提效

隨著業務發展，我們經常面臨模型重構的問題，比如一些舊表要切換到新表。數據血緣分析可以幫助我們快速定位模型重構的切入點，提升數據處理的效率。基于算子級的血緣關系，數據血緣可以實現任務的精準回溯優化，減少數據修復流程時間，減少錯誤傳播。

3. 保障數據一致性

在數據一致性方面，通過全鏈路血緣等手段，我們實現了指標從定義到生產消費的完整自動化流程，提升了指標的管理效率，減少了人為失誤。通過血緣分析加解析能力，我們能識別出重復加工的字段，優化數據流程，從而減少不必要的資源消耗。

二、如何構建數據血緣底座

血緣底座是全鏈路數據血緣的基石。接下來，我將從整體架構、質量評估體系和應用層血緣三個方面來介紹血緣底座的建設。

1. 整體架構

整體架構-關系圖譜

如上圖所示，關系圖譜中有一些關鍵特點，如點、邊、節點存儲和邊存儲等。

• 點（Node）：代表各種類型的節點，如指標、任務等
• 邊（Edge）：表示節點之間的血緣關系，如數據流向、任務依賴等
• 節點存儲：每個節點類型對應一個或多個圖中的點
• 邊存儲：節點間的血緣關系通過邊來表示，邊包含方向和類型信息

一般數倉加工鏈路會進行分層，如 ODS 貼源層、DWD 明細層、DWS 匯總層等，最終透傳到數據產品的前端頁面。

如果用傳統的離線數倉來實現以上架構，且有明確關系的表模型，是非常困難的。最終，我們選擇了字節自研圖數據庫來實現血緣數據的底層存儲。

2. 血緣質量度量體系

血緣質量是整個全鏈路血緣從應用到實踐的最核心評測標準。

舉個例子，如果某個業務要基于字段級的血緣回溯下游，但是由于血緣質量不達標，預期要回溯 10 個任務，最終查出來 11 個或者 9 個，出現一定誤差。

在電商場景中，我們搭建了一套完整的血緣質量度量體系，從血緣解析的準確率、成功率、覆蓋率、查詢能力等維度來度量血緣的數據質量，評估血緣質量的健康程度，并且定期自動化檢驗血緣數據與實際數據流向的一致性。我們通過定期巡檢機制發現 bad case，并隨之更新、迭代對應的血緣模塊。

3. 應用層血緣

應用層血緣，與常規理解的數倉鏈路血緣不同。

對于數據鏈路血緣來說，我們針對異構數據源的 SQL 進行解析，在數據平臺上維護了很多豐富的元數據，可以更好解析數倉之間的鏈路關系。但是對于應用層則不同，在電商場景中，我們維護了很多數據應用，如果逐一推進應用接入全鏈路血緣能力，成本很高。數據流轉是從產品頁面經過 HTTP 或者 thrift 接口請求后端服務，經過數據服務層打到數倉底表。

右圖將該過程劃分層級，通過低代碼平臺搭建前端頁面、業務產品頁面、數據產品頁面，再通過接口的形式請求后端服務，最終映射到在 one service 上，形成對應的 API，其底層就是剛才提到的數倉鏈路的血緣。

為了解決業務應用接入成本高的問題，我們實現了網關層自動參數上報，通過日志平臺以及網關平臺、服務平臺間的合作，在前端請求接口時會自動上報 URL refer 參數，再通過日志采集系統把所有前端請求的日志采集下來，經過清洗，最終實現應用程序血緣的數據采集。

但在整個過程中，我們會遇到爬蟲亂傳參數、不傳參數等問題，對血緣質量造成污染。為了解決該問題，我們通過腳本對域內的爬蟲進行補全。通過自定義爬蟲腳本，對全域的前端接口進行抓包，替換外部污染的數據。

三、電商場景的血緣應用實踐

接下來重點介紹一下血緣應用在電商場景的實踐，包含新舊表切換、字段口徑探查、指標自動化拆解三個部分。

1. 新舊表切換

開發人員使用 IDE 修改一個方法時，會改方法名、方法的入參以及方法的出參，IDE 則提供代碼級的替換能力。

而對于數倉研發人員來說，沒有類似的能力可以做切換的操作。一般在重構中，數倉研發人員拿到要切換的表，通過人工查詢，獲取切換舊表影響的任務，進而手動拉群，做切換表的通知，下游的接收人收到消息后，更改任務代碼，并進行數據比對，如果發現有問題需要再與上游進行溝通，如果沒有問題則上線代碼。

基于一站式新舊表切換功能，上述人工操作可以由平臺自動完成，大幅降低了切換的工作量，提高了工作效率和質量。

通過平臺能力，數倉研發人員只需要在系統中錄入舊表信息，以及新舊表的映射關系，就可以自動生成切換后的代碼。在生成代碼、跑數之后，平臺還支持與舊表的歷史數據進行比對。對比結果無誤的情況下，下游無需做任何調整。除此之外，平臺還提供了批量切換的能力，可以同時進行多張表的切換。

對于下游切換者來說，原本由于切換收益不大，導致操作意愿不強。但現在通過平臺提供的切換收益量化的能力，如 SLA 和穩定性提升，提升下游切換意愿。

下面介紹技術實現。用戶輸入需要切換的舊表之后，平臺通過舊表的產出任務進行解析，獲取語法樹文件，并基于語法樹文件做裁剪、替換?；谟脩糨斎氲男屡f表映射關系生成切換后的 SQL，再提交到比對平臺，最終完成整體比對。

在這一過程中，用戶不希望原生代碼遭到太多破壞，如注釋被溶解，或對一些寫法造成影響。針對這種情況，我們會在 SQL 解析前把注釋的關鍵信息保留下來，拿到比對完成的 SQL 之后再做補全，最終把原始任務的 SQL 盡可能相似地提供出來。

2. 字段口徑探查

作為一名數倉研發人員或 BI 分析師，經常需要閱讀其他人代碼，如果代碼復雜度高，對讀碼的專業性要求會比較高。為解決這個問題，平臺提供可視化頁面輔助轉譯。

如上圖中的例子，將一段 SQL 轉譯成圖的形式，可以更好幫助不寫代碼的角色更好理解這段 SQL。

在大多數使用場景中，用戶只想看到某個字段，或者某幾個字段在任務中的加工邏輯。平臺能力實現了在任務中裁剪出所需字段加工邏輯的能力，最終裁剪掉超 90% 的無關代碼。原本需要從 100 行代碼中提取出來某個字段的加工口徑，現在借助平臺能力，只需要閱讀幾行代碼就可以完成需求。

此外，我們希望將整個數倉鏈路中分層維護的 SQL 進行溶解。

一個傳統數倉鏈路有 ODS 層、DWD 層、DWM 層、APP 層等等，每層都會維護一段 SQL。用戶需要梳理 APP 層的 SQL 里面的某個字段從 ODS 層哪里來的，過程比較復雜。

基于平臺的能力，我們把 4 個任務的 SQL 先展開成一段大 SQL，再進行內斂，最終變成從 ODS 層溯源到 APP 層的字段。平臺內斂之后進行裁剪。代碼的展開和收斂，是通過自研的一套語義解析引擎實現，該引擎已經申請了專利。

核心步驟如下：

• 第一步，對 SQL 算子進行優化，平臺功能必須對算子級別 SQL 進行裁剪。
• 第二步，語法糖溶解，一段 SQL 要不斷內斂，基于血緣關系找到上游表，放到替換掉這個實際的物理表名稱中，在這個過程中，就會涉及到很多語法糖的溶解，在傳統離線數倉里命名很多臨時表，平臺會進行完整的語法糖溶解。
• 第三步，基于此加上算子重寫，獲取關系代數，最終 unparsed 成一段 SQL 返回給用戶。

3. 指標自動化拆解

左圖是傳統數據指標體系化建設架構，包含配置信息、原子指標、度量、時間周期、修飾詞等。每個指標種類不一樣，衍生指標來源于原子指標，復合指標來源于衍生指標。

指標體系化建設的核心目的就是保證指標的一致性，避免指標重復建設。

在電商場景中，我們早期推進指標體系化建設有一個核心的步驟——指標拆解，即把字段關聯到錄入好的配置信息里面。如果發現綁定已有的衍生指標，則避免了重復建設的工作。

在該過程中，通過進行用戶調研，我們發現，在做拆解的過程中，用戶有幾個核心環節，如通過字段口徑了解字段真實的來源鏈路，同時還要看字段整體的加工邏輯，再人工用該 SQL 做拆解工作。最后，用戶在指標平臺里面維護好元信息。應用層的指標開發完成之后，再去評審最終拆解結果的質量。

指標自動化拆解-技術實現

上圖為指標自動化拆解-技術實現過程。

第一，工程能力。工程能力底層是字段口徑探查的能力，將應用層的指標透傳到明細數據層表，同時平臺進行單指標粒度的裁剪，裁剪完成之后拿到字段應該綁定的 DWD 表，最終內斂到 DWD 表的極簡 SQL，過程中不需要人為查詢代碼完成邏輯梳理。

第二，底層數據能力。關鍵是必須維護好高質量的元數據。在電商場景中，我們維護了萬級別的指標關系，在指標關系中再維護類似于業務過程度量的 SQL 邏輯，如 where 條件。

第三，大模型的能力?；诖竽Ｐ湍芰?，我們結合裁剪之后的 SQL、待選 SQL 完成召回。裁剪之后的 SQL，基于元數據及大模型能力，與規則方法論進行匹配，最終把標的元素判斷出來。也就是說，研發人員只需要輸入新開發的表，就可以知道該表是否存在重復開發的問題。

判斷過程：根據拆解過程找到對應 SQL，原子指標、修飾詞、時間周期三個元素生成衍生指標，該衍生指標如果存在，就是存在重復開發，如果不存在，則可以在系統里綁定，供給數據應用使用。

四、總結與展望

數據血緣底座是提升數據管理效率和數據質量的關鍵。我們希望能不斷提升全鏈路數據血緣的能力，在上文提到的新舊表切換、數倉價值評估、指標拆解等場景中，更好結合大模型等能力優化功能和用戶體驗，為業務提供更多價值。