火山引擎數據飛輪實踐：在電商場景中，如何建設全鏈路數據血緣？

數據作為新型生產要素，正支撐企業的數智化轉型。但企業數字化建設也存在管理成本高、數據產品使用門檻高、數據資產價值不夠的問題，其原因在于業務和數據之間沒有形成雙向良性驅動。

結合新時代企業數字化轉型需求，火山引擎基于字節跳動十余年數據驅動的實踐經驗，對外發布企業數智化升級新范式“數據飛輪”，幫助企業實現數據驅動。

具體來說，數據消費是數據飛輪的核心，通過一個又一個具體業務中的數據消費，在上層“業務應用輪”實現決策科學、行動敏捷，帶來業務價值提升；在下層“數據資產輪”，也通過頻繁的數據消費和業務收益，有的放矢建設高質量、低成本的數據資產，更好支撐業務應用。

構建扎實的數據資產輪能更好支撐企業上層數據應用。那么，在企業實踐中，究竟應該如何做呢？

作為數據資產輪的支撐產品之一，火山引擎DataLeap在資產建設治理層面，能提升數據質量，實現效率提升和成本優化。本文將從電商角度出發，聚焦在數據血緣建設層面，具體介紹如何建設血緣底座、電商場景的血緣應用實踐。

數據全鏈路血緣介紹

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

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

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

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

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

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

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

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

解決數據不斷膨脹的問題

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

幫助數倉開發提效

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

保障數據一致性

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

如何構建數據血緣底座

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

整體架構

整體架構-關系圖譜

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

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

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

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

血緣質量度量體系

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

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

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

應用層血緣

應用層調度鏈路

應用層數據采集方案

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

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

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

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

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

電商場景的血緣應用實踐

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

新舊表切換

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

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

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

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

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

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

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

字段口徑探查

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

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

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

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

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

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

核心步驟如下：

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