一、數(shù)據(jù)全鏈路血緣介紹

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

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

• 通過數(shù)據(jù)采集，如業(yè)務(wù)日志、埋點(diǎn)、表格、存儲(chǔ)。
• 經(jīng)過 ETL 數(shù)據(jù)加工，包括離線和實(shí)時(shí)兩種任務(wù)。
• 再到數(shù)據(jù)服務(wù)中的物理表、邏輯表，以及服務(wù)編排。
• 最后透傳到數(shù)據(jù)應(yīng)用，比如接口、頁面、報(bào)表、指標(biāo)等。

在業(yè)務(wù)發(fā)展過程中，我們常常會(huì)遇到如下問題：

首先，隨著業(yè)務(wù)的快速發(fā)展，數(shù)據(jù)不斷膨脹。數(shù)據(jù)量增大，但數(shù)據(jù)產(chǎn)生的實(shí)際價(jià)值在哪里？數(shù)據(jù)血緣則可以幫助我們更好評估數(shù)據(jù)價(jià)值，并在滿足業(yè)務(wù)需求的同時(shí)，控制存儲(chǔ)計(jì)算資源的膨脹速度。與此同時(shí)，數(shù)據(jù)血緣還能夠衡量數(shù)倉建設(shè)的優(yōu)劣，并且做好數(shù)倉體系化建設(shè)。

第二，如何做好數(shù)倉變更監(jiān)控？在數(shù)倉的日常開發(fā)過程中，我們經(jīng)常會(huì)遇到上下游變更，變更后希望能及時(shí)、準(zhǔn)確地衡量數(shù)據(jù)變更的影響。由于數(shù)據(jù)來源變更豐富，需要通過數(shù)據(jù)血緣將數(shù)據(jù)變更及時(shí)通知下游關(guān)聯(lián)方。

第三，數(shù)倉研發(fā)提效。我們希望通過數(shù)據(jù)血緣及時(shí)完成表重構(gòu)，理清字段的來源以及加工口徑，并且進(jìn)行任務(wù)精準(zhǔn)回溯。

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

1. 解決數(shù)據(jù)不斷膨脹的問題

針對數(shù)據(jù)膨脹的問題，數(shù)據(jù)血緣可以明確數(shù)據(jù)流轉(zhuǎn)路徑，優(yōu)化資源配置。血緣關(guān)系可以精確衡量數(shù)倉對業(yè)務(wù)的價(jià)值，實(shí)現(xiàn)數(shù)據(jù)治理，控制資源膨脹，并且能夠精準(zhǔn)地完成影響面評估。

2. 幫助數(shù)倉開發(fā)提效

隨著業(yè)務(wù)發(fā)展，我們經(jīng)常面臨模型重構(gòu)的問題，比如一些舊表要切換到新表。數(shù)據(jù)血緣分析可以幫助我們快速定位模型重構(gòu)的切入點(diǎn)，提升數(shù)據(jù)處理的效率。基于算子級的血緣關(guān)系，數(shù)據(jù)血緣可以實(shí)現(xiàn)任務(wù)的精準(zhǔn)回溯優(yōu)化，減少數(shù)據(jù)修復(fù)流程時(shí)間，減少錯(cuò)誤傳播。

3. 保障數(shù)據(jù)一致性

在數(shù)據(jù)一致性方面，通過全鏈路血緣等手段，我們實(shí)現(xiàn)了指標(biāo)從定義到生產(chǎn)消費(fèi)的完整自動(dòng)化流程，提升了指標(biāo)的管理效率，減少了人為失誤。通過血緣分析加解析能力，我們能識別出重復(fù)加工的字段，優(yōu)化數(shù)據(jù)流程，從而減少不必要的資源消耗。

二、如何構(gòu)建數(shù)據(jù)血緣底座

血緣底座是全鏈路數(shù)據(jù)血緣的基石。接下來，我將從整體架構(gòu)、質(zhì)量評估體系和應(yīng)用層血緣三個(gè)方面來介紹血緣底座的建設(shè)。

1. 整體架構(gòu)

整體架構(gòu)-關(guān)系圖譜

如上圖所示，關(guān)系圖譜中有一些關(guān)鍵特點(diǎn)，如點(diǎn)、邊、節(jié)點(diǎn)存儲(chǔ)和邊存儲(chǔ)等。

• 點(diǎn)（Node）：代表各種類型的節(jié)點(diǎn)，如指標(biāo)、任務(wù)等
• 邊（Edge）：表示節(jié)點(diǎn)之間的血緣關(guān)系，如數(shù)據(jù)流向、任務(wù)依賴等
• 節(jié)點(diǎn)存儲(chǔ)：每個(gè)節(jié)點(diǎn)類型對應(yīng)一個(gè)或多個(gè)圖中的點(diǎn)
• 邊存儲(chǔ)：節(jié)點(diǎn)間的血緣關(guān)系通過邊來表示，邊包含方向和類型信息

一般數(shù)倉加工鏈路會(huì)進(jìn)行分層，如 ODS 貼源層、DWD 明細(xì)層、DWS 匯總層等，最終透傳到數(shù)據(jù)產(chǎn)品的前端頁面。

如果用傳統(tǒng)的離線數(shù)倉來實(shí)現(xiàn)以上架構(gòu)，且有明確關(guān)系的表模型，是非常困難的。最終，我們選擇了字節(jié)自研圖數(shù)據(jù)庫來實(shí)現(xiàn)血緣數(shù)據(jù)的底層存儲(chǔ)。

2. 血緣質(zhì)量度量體系

血緣質(zhì)量是整個(gè)全鏈路血緣從應(yīng)用到實(shí)踐的最核心評測標(biāo)準(zhǔn)。

舉個(gè)例子，如果某個(gè)業(yè)務(wù)要基于字段級的血緣回溯下游，但是由于血緣質(zhì)量不達(dá)標(biāo)，預(yù)期要回溯 10 個(gè)任務(wù)，最終查出來 11 個(gè)或者 9 個(gè)，出現(xiàn)一定誤差。

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

3. 應(yīng)用層血緣

應(yīng)用層血緣，與常規(guī)理解的數(shù)倉鏈路血緣不同。

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

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

為了解決業(yè)務(wù)應(yīng)用接入成本高的問題，我們實(shí)現(xiàn)了網(wǎng)關(guān)層自動(dòng)參數(shù)上報(bào)，通過日志平臺(tái)以及網(wǎng)關(guān)平臺(tái)、服務(wù)平臺(tái)間的合作，在前端請求接口時(shí)會(huì)自動(dòng)上報(bào) URL refer 參數(shù)，再通過日志采集系統(tǒng)把所有前端請求的日志采集下來，經(jīng)過清洗，最終實(shí)現(xiàn)應(yīng)用程序血緣的數(shù)據(jù)采集。

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

三、電商場景的血緣應(yīng)用實(shí)踐

接下來重點(diǎn)介紹一下血緣應(yīng)用在電商場景的實(shí)踐，包含新舊表切換、字段口徑探查、指標(biāo)自動(dòng)化拆解三個(gè)部分。

1. 新舊表切換

開發(fā)人員使用 IDE 修改一個(gè)方法時(shí)，會(huì)改方法名、方法的入?yún)⒁约胺椒ǖ某鰠?，IDE 則提供代碼級的替換能力。

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

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

通過平臺(tái)能力，數(shù)倉研發(fā)人員只需要在系統(tǒng)中錄入舊表信息，以及新舊表的映射關(guān)系，就可以自動(dòng)生成切換后的代碼。在生成代碼、跑數(shù)之后，平臺(tái)還支持與舊表的歷史數(shù)據(jù)進(jìn)行比對。對比結(jié)果無誤的情況下，下游無需做任何調(diào)整。除此之外，平臺(tái)還提供了批量切換的能力，可以同時(shí)進(jìn)行多張表的切換。

對于下游切換者來說，原本由于切換收益不大，導(dǎo)致操作意愿不強(qiáng)。但現(xiàn)在通過平臺(tái)提供的切換收益量化的能力，如 SLA 和穩(wěn)定性提升，提升下游切換意愿。

下面介紹技術(shù)實(shí)現(xiàn)。用戶輸入需要切換的舊表之后，平臺(tái)通過舊表的產(chǎn)出任務(wù)進(jìn)行解析，獲取語法樹文件，并基于語法樹文件做裁剪、替換。基于用戶輸入的新舊表映射關(guān)系生成切換后的 SQL，再提交到比對平臺(tái)，最終完成整體比對。

在這一過程中，用戶不希望原生代碼遭到太多破壞，如注釋被溶解，或?qū)σ恍懛ㄔ斐捎绊?。針對這種情況，我們會(huì)在 SQL 解析前把注釋的關(guān)鍵信息保留下來，拿到比對完成的 SQL 之后再做補(bǔ)全，最終把原始任務(wù)的 SQL 盡可能相似地提供出來。

2. 字段口徑探查

作為一名數(shù)倉研發(fā)人員或 BI 分析師，經(jīng)常需要閱讀其他人代碼，如果代碼復(fù)雜度高，對讀碼的專業(yè)性要求會(huì)比較高。為解決這個(gè)問題，平臺(tái)提供可視化頁面輔助轉(zhuǎn)譯。

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

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

此外，我們希望將整個(gè)數(shù)倉鏈路中分層維護(hù)的 SQL 進(jìn)行溶解。

一個(gè)傳統(tǒng)數(shù)倉鏈路有 ODS 層、DWD 層、DWM 層、APP 層等等，每層都會(huì)維護(hù)一段 SQL。用戶需要梳理 APP 層的 SQL 里面的某個(gè)字段從 ODS 層哪里來的，過程比較復(fù)雜。

基于平臺(tái)的能力，我們把 4 個(gè)任務(wù)的 SQL 先展開成一段大 SQL，再進(jìn)行內(nèi)斂，最終變成從 ODS 層溯源到 APP 層的字段。平臺(tái)內(nèi)斂之后進(jìn)行裁剪。代碼的展開和收斂，是通過自研的一套語義解析引擎實(shí)現(xiàn)，該引擎已經(jīng)申請了專利。

核心步驟如下：

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

3. 指標(biāo)自動(dòng)化拆解

左圖是傳統(tǒng)數(shù)據(jù)指標(biāo)體系化建設(shè)架構(gòu)，包含配置信息、原子指標(biāo)、度量、時(shí)間周期、修飾詞等。每個(gè)指標(biāo)種類不一樣，衍生指標(biāo)來源于原子指標(biāo)，復(fù)合指標(biāo)來源于衍生指標(biāo)。

指標(biāo)體系化建設(shè)的核心目的就是保證指標(biāo)的一致性，避免指標(biāo)重復(fù)建設(shè)。

在電商場景中，我們早期推進(jìn)指標(biāo)體系化建設(shè)有一個(gè)核心的步驟——指標(biāo)拆解，即把字段關(guān)聯(lián)到錄入好的配置信息里面。如果發(fā)現(xiàn)綁定已有的衍生指標(biāo)，則避免了重復(fù)建設(shè)的工作。

在該過程中，通過進(jìn)行用戶調(diào)研，我們發(fā)現(xiàn)，在做拆解的過程中，用戶有幾個(gè)核心環(huán)節(jié)，如通過字段口徑了解字段真實(shí)的來源鏈路，同時(shí)還要看字段整體的加工邏輯，再人工用該 SQL 做拆解工作。最后，用戶在指標(biāo)平臺(tái)里面維護(hù)好元信息。應(yīng)用層的指標(biāo)開發(fā)完成之后，再去評審最終拆解結(jié)果的質(zhì)量。

指標(biāo)自動(dòng)化拆解-技術(shù)實(shí)現(xiàn)

上圖為指標(biāo)自動(dòng)化拆解-技術(shù)實(shí)現(xiàn)過程。

第一，工程能力。工程能力底層是字段口徑探查的能力，將應(yīng)用層的指標(biāo)透傳到明細(xì)數(shù)據(jù)層表，同時(shí)平臺(tái)進(jìn)行單指標(biāo)粒度的裁剪，裁剪完成之后拿到字段應(yīng)該綁定的 DWD 表，最終內(nèi)斂到 DWD 表的極簡 SQL，過程中不需要人為查詢代碼完成邏輯梳理。

第二，底層數(shù)據(jù)能力。關(guān)鍵是必須維護(hù)好高質(zhì)量的元數(shù)據(jù)。在電商場景中，我們維護(hù)了萬級別的指標(biāo)關(guān)系，在指標(biāo)關(guān)系中再維護(hù)類似于業(yè)務(wù)過程度量的 SQL 邏輯，如 where 條件。

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

判斷過程：根據(jù)拆解過程找到對應(yīng) SQL，原子指標(biāo)、修飾詞、時(shí)間周期三個(gè)元素生成衍生指標(biāo)，該衍生指標(biāo)如果存在，就是存在重復(fù)開發(fā)，如果不存在，則可以在系統(tǒng)里綁定，供給數(shù)據(jù)應(yīng)用使用。

四、總結(jié)與展望

數(shù)據(jù)血緣底座是提升數(shù)據(jù)管理效率和數(shù)據(jù)質(zhì)量的關(guān)鍵。我們希望能不斷提升全鏈路數(shù)據(jù)血緣的能力，在上文提到的新舊表切換、數(shù)倉價(jià)值評估、指標(biāo)拆解等場景中，更好結(jié)合大模型等能力優(yōu)化功能和用戶體驗(yàn)，為業(yè)務(wù)提供更多價(jià)值。