火山引擎DataLeap:「資料血緣」踩過哪些坑?

陶然陶然發表於2023-02-28

  DataLeap 是火山引擎數智平臺 VeDI 旗下的大資料研發治理套件產品,幫助使用者快速完成資料整合、開發、運維、治理、資產、安全等全套資料中臺建設,降低工作成本和資料維護成本、挖掘資料價值、為企業決策提供資料支撐。資料血緣是幫助使用者找資料、理解資料以及使資料發揮價值的基礎能力。基於位元組跳動內部沉澱的資料治理經驗,火山引擎 DataLeap 具備完備的資料血緣能力,本文將從資料血緣應用背景、發展概況、架構演講以及未來展望四部分,為大家介紹資料血緣在位元組跳動進化史。

  背景介紹

  1. 資料血緣是資料資產平臺的重要能力之一

  在火山引擎 DataLeap 中,資料資產平臺主要提供後設資料搜尋、展示、資產管理以及知識發現能力。在資料資產平臺中,資料血緣是幫助使用者找資料、理解資料以及使資料發揮價值的重要基礎能力。  

  2. 位元組跳動的資料鏈路情況  

  資料來源

  在位元組跳動,資料主要來源於以下兩部分:

  埋點資料:

  主要來自 APP 端和 Web 端。經過日誌採集後,這類資料最終進入到訊息佇列中。

  業務資料:

  該類資料一般以線上形式儲存,如 RDS 等。

  中間部分是以 Hive 為代表的離線數倉:

  該類資料主要來自訊息佇列或者線上儲存,經過資料整合服務把資料匯入離線數倉。經過離線數倉的資料加工邏輯,流轉到以 ClickHouse 為代表的 OLAP 引擎。

  另外,在訊息佇列部分,還會透過 Flink 任務或者其他任務對Topic 分流,因此上圖也展現了一個回指的箭頭。

  資料去向

  主要以指標系統和報表系統為代表。指標系統包含重要且常用的業務指標,如抖音的日活等。報表系統是把指標以視覺化形式展現出來。

  資料服務

  主要透過 API 提供資料,具體而言,從訊息佇列、線上儲存、下游消費以及上圖右側所示的資料流轉,都涵蓋在資料血緣範圍內。

  血緣發展概況  

  接下來介紹血緣在位元組跳動的三個發展階段。

  第一階段:2019 年左右開始

  第一階段主要提供資料血緣基礎能力,以 Hive 和 ClickHouse 為代表,支援表級血緣、欄位血緣,涉及10+後設資料。

  第二階段:從 2020 年初開始

  第二階段引入了任務血緣,同時支援的後設資料型別進行擴充,達到15+。

  第三階段:從 2021 年上半年至今

  在這一階段,我們對整個後設資料系統(即前文提到的資產平臺)進行了 GMA 改造,同步對血緣架構進行全面升級,由此支援了更豐富的功能,具體包括:

  首先, 後設資料種類擴充到近 30 種且時效性提升。之前以離線方式更新血緣資料,導致資料加工邏輯變化的第二天,血緣才會產生變化。目前,基於近實時的更新方式,資料加工邏輯在 1 分鐘內即在血緣中體現。

  其次,新增血緣消費方式的變更通知。由於該版本支援實時血緣,業務方產生及時瞭解血緣變化的需求,變動通知功能就是把血緣變化情況以訊息佇列的形式告知業務方。

  再次,支援評估血緣質量。新增一條鏈路,專門服務於血緣資料質量。

  最後,引入標準化接入方式。為了減少重複工作、降低血緣接入成本,我們制定了詳細的血緣接入標準,業務方資料均以標準化方式接入。

  以上就是整體的發展情況,目前處於第三個版本當中。

  資料血緣架構的演進

  1. 第一版血緣架構:建立血緣基本能力,初探使用場景

  血緣架構  

  1. 在資料來源方面,目前血緣主要包括兩個資料來源(見上圖左上角):

  第一,資料開發平臺: 使用者在開發平臺寫任務,並對資料加工,由此產生血緣資料。

  第二,追蹤資料: 第三方平臺(即任務平臺)對使用者埋點等資料進行計算,也會產生血緣資訊。

  2. 在血緣加工任務方面(見上圖中間部分):

  這部分會對任務進行血緣解析,產生血緣快照檔案。由於第一版採用離線方式執行,每天該血緣任務均會生成對應的血緣快照檔案。我們透過對比前後兩天的血緣快照檔案,來獲取血緣的變更情況,然後把這些變更載入到圖中。

  除此之外,血緣中涉及的後設資料會冗餘一份,並儲存到圖裡。

  3. 在血緣儲存方面(見上圖右邊部分),除了應用於圖資料庫之外,血緣本身也會依賴後設資料的儲存,如 Mysql 以及索引類儲存。

  4. 在血緣消費層面,第一版只支援透過API 進行消費。

  最後總結該版本的三個關鍵點:

  血緣資料每天以離線方式全量更新。

  透過對比圖來判斷血緣更新操作,後面將為大家詳細解答為什麼要透過對比的方式。

  冗餘一份後設資料儲存到圖資料庫中。

  儲存模型  

  圖中上半部分為表級血緣,只包括一種型別節點,即表節點,如說 Hive 表、 ClickHouse 表以及其他表。

  圖中下半部分為欄位血緣圖,第一版主要是提供構建血緣的基本能力,因此用彼此分離的兩張圖來實現。由於血緣中後設資料進行了冗餘,每個圖裡面的每個節點裡面都儲存表相關的後設資料,包括業務資訊以及其他資訊。

  除此之外,我們會預先計算一些統計資訊,儲存到圖的節點中,如當前節點下游總節點數量、下游層級數量等。

  採用預先計算的目的是為了“用空間換時間”,在產品對外展示的功能上可能要露出資料資訊,如果從圖裡實時查詢可能影響效能,因此採用空間換時間的方式來支援產品的展示。

  2. 第二版血緣架構:血緣價值逐步體現,使用場景拓寬

  血緣架構  

  經過1年的使用,血緣在資料資產中的價值逐步體現,且不斷有應用場景落地,由此我們進行了第二版本升級。升級點具體包括:

  第一,去除第一版本中後設資料冗餘。後設資料冗餘在圖提升了效能,但是可能導致 Metadata Store 的後設資料不一致,給使用者帶來困擾。

  第二,去掉了預計算的統計資訊。隨著血緣的資料量增多,預計算的資訊透出不能給很好輔助使用者完成業務判斷,且導致任務負擔重。比如,即使知道某一節點的下游資料量,還是要拉出所有節點才能進一步分析或決策。

  第三,支援一條全新鏈路,在新增鏈路上,我們把血緣快照檔案匯入離線數倉,主要應用於兩個場景:

  離線分析場景或全量分析場景。

  基於離線數倉的血緣資料實現資料

  監控

  儘早發現血緣異常情況。

  因此,從第二版開始,資料血緣新增了很多離線消費方式。

  儲存模型  

  第二個版本引入了全新血緣儲存模型(如上圖所示),並將第一個版本兩張圖融合成一張圖,解決了無法透過表遍歷欄位血緣的問題。

  除此之外,第二個版本還引入了任務型別節點,服務於以下三種遍歷場景:

  單純遍歷資料血緣

  即從資料節點到資料節點。

  資料血緣和任務血緣混合方式

  單純

  任務之間血緣關係

  3. 第三版血緣架構:血緣成為資料發揮價值的重要基礎能力

  血緣架構  

  2021年初,火山引擎DataLeap資料血緣迭代到第三版,也成為公司內部資料發揮價值的重要基礎能力。

  服務於業務方對資料高質量要求,第三版升級點如下:

  血緣資料來源: 除了支援兩個平臺之外,還支援包括報表、第三方使用者畫像等其他平臺 。

  血緣任務: 之前版本只支援每天定時執行的離線排程方式,第三版引入實時消費方式,支援實時解析血緣,並提取通用邏輯,複用離線血緣任務和實時血緣任務。

  血緣解析:不同型別任務需要使用不同解析邏輯。在之前版本中,Hive SQL 任務和Flink SQL任務的解析邏輯是整合到血緣任務中。從第三版開始,我們把解析服務拆解成可配置的外掛,實現了外掛化。當某一種任務型別的血緣解析邏輯需要調整的時候,只用改動其中一個解析服務,其他解析服務不受影響,同時也讓血緣任務更好維護。

  後設資料儲存統一:只依賴圖資料庫和索引儲存,同時支援從系統中把所有相關的資料匯出離線數倉。

  實時消費: 血緣發生變更的資訊會被同步到訊息佇列。

  血緣的驗證模組: 使用方對血緣資料質量有高要求,因此第三版引入新的血緣的驗證模組。

  驗證的前提是要有引擎埋點資料,該埋點資料能清楚知道某一個任務具體讀取資料情況、寫入資料情況

  在離線數倉中,透過埋點資料與血緣資料中對比,生成血緣資料質量報表。

  資料質量報表對血緣消費者開放,消費者能夠清晰瞭解每個血緣鏈路準確性和覆蓋情況。

  血緣標準化接入: 即讓使用者快速接入資料,不用每一種血緣接入都重複寫邏輯。

  儲存模型  

  第三版血緣儲存模型相對於前兩版的升級點如下:

  以任務為中心

  黃色圓圈為任務節點,資料加工邏輯產生血緣,因此我們把資料加工邏輯抽象為任務節點,血緣的建立則以任務為媒介,任務成為血緣中心。也就是說,表1、表2、表3之間的血緣,是透過任務 a 完成構建。假設沒有任務 a ,則三個表之間的血緣也不存在。

  表血緣和欄位血緣模型統一

  在欄位血緣之間沒有具體任務的情況下,我們會抽象出虛擬的任務來統一模型。由此,任務和任務之間的血緣採用新的邊來表示依賴關係。

  重要特性

  增量更新  

  在實時血緣基礎上,我們還支援增量更新能力,即當某一個任務的加工邏輯發生變化時,只需要更新圖中一小部分。

  血緣建立: 資料加工邏輯上線或開始生效,將被抽象為圖資料庫的操作,即建立一個任務節點和對應的資料節點,並建立兩者之間的邊。上圖例子為表1、表2和任務的邊,以及任務和表3之間的邊。

  血緣刪除:資料的加工邏輯發生了下線、刪除或不生效。 先在圖裡面查詢該任務節點,把任務節點以及關聯血緣相關的邊刪除。血緣儲存模型以任務為中心,因此表1、表2和表3之間的血緣關係也同步消失,這部分血緣即被刪除。

  血緣更新:任務本身沒有發生上線或下線,但計算邏輯發生變化。 例如,原本血緣關係是表1、表2生成表3,現在變成了表2、表4生成表3。我們需要做的如下:

  解析出最新血緣狀態,即表2、表4到表3的血緣關係,與當前血緣狀態做對比(主要對比該任務 a 相關的邊),上圖例子是入邊發生變化,那麼刪除其中一條邊,構建另外一條邊,即可完成該任務節點的血緣更新。

  如果面臨以上血緣關係變化,但是沒有該任務節點,應該執行哪些操作來更新血緣?由於只有血緣最新狀態和當前狀態,沒有任務節點去獲取最小單位的血緣關係,所以只能進行全量血緣或全圖對比,才能得出邊的變化情況,再更新到圖資料庫中。如果不進行全量血緣或全圖對比,無法知曉如何刪除條和建立條,導致血緣無法更新。這也是前兩個版本需要進行血緣快照對比的原因。

  血緣標準化  

  在火山引擎DataLeap中,通常把血緣資料接入抽象成一個 ETL 。

  首先,血緣資料來源,即第三方平臺血緣相關的資料,通常是一個資料加工邏輯或者稱為任務。接著,對這些任務完成 KeyBy 操作,並與資料資產平臺的任務資訊做對比,確定如何進行任何建立、刪除和更新。

  在再完成過濾操作之後, 由Lineage Parser 對建立、更新等任務進行血緣解析,得出血緣結果之後會生成表示圖相關操作的Event,最終透過Sink 把資料寫入到資料資產平臺中。

  上圖綠色和藍色分別表示:

  藍色:對不同血緣接入過程的邏輯一致,可抽象出來並複用。

  綠色:不同血緣的實現情況不一樣。例如,某一個平臺為拉取資料,另外一個平臺透過其他方式獲取資料,導致三個部分不一樣,因此我們抽取特殊部分,複用共同部分。除此之外,我們還提供通用 SDK,串聯整個血緣接入流程,使得接入新的血緣時,只需要實現綠色元件。

  目前,位元組跳動內部業務已經可以使用 SDK 輕鬆接入血緣。

  資料血緣質量-覆蓋率  

  當血緣發展到一定階段,業務方不止關心血緣覆蓋情況、支援情況,還關心血緣資料質量情況。因此,第三版本透出血緣質量相關指標——覆蓋率和準確率。

  覆蓋率:血緣覆蓋的資料資產數佔關注的資產數量佔比。

  關注的資料資產一般指,有生產任務或有生產行為的資產。上圖虛線圓圈,如 Table 9,使用者建立該表後沒有生產行為,因此也不會產生血緣,在計算中將被剔除掉。上圖實線圓圈,表示有生產行為或有任務讀取,則被認為是關注的資產。關注的資料資產被血緣覆蓋的佔比,即覆蓋率。

  以上圖為例,在10張表中,由於有任務與Table 1 ~ 8關聯,因此判定有血緣。Table 10,它與Task-D之間的連線是虛線,表示本來它應該有血緣,但是實際上血緣任務沒把這個血緣關係解析出來,那麼我們就認為這個 Table 10是沒有被血緣覆蓋的。整體上被血緣覆蓋的資產就是表1 ~ 8。除了Table 9之外,其他的都是關注的資產,那麼血緣覆蓋的資產佔比就是8/9。也就是圖上藍色的這第8個除以藍色的8個加上 Table 10,就是9個,所以這個覆蓋率就是88%。

  資料血緣質量-準確率  

  覆蓋血緣不一定是正確的,所以我們還定義了準確率指標,即血緣準確的任務數/同型別的任務數。

  舉個例子,假設任務 c的血緣應該是 Table 5、Table6生成 Table 7,但實際上被遺漏,沒有被解析(虛線表示),導致任務 c 的血緣不準確。也存在其他情況缺失或多餘情況,導致血緣不準確。

  在上圖中,同型別任務包含4個,即 a、b、c、d。那麼,準確的血緣解析只有 a、b,因此準確率佔比為2/4 = 50%。

  在火山引擎DataLeap中,由於血緣來源是任務,因此我們以任務的視角來看待血緣準確率。

  血緣質量-位元組現狀  

  在覆蓋率部分,目前 Hive 和 ClickHouse 後設資料覆蓋度較高,分別達到98%、96%。對於實時後設資料,如Kafka ,相關 Topic覆蓋70%,其他後設資料則稍低。

  在準確率部分,我們區分任務型別做準確性解析。如 DTS 資料整合任務達到99%以上,Hive SQL 任務、 Flink SQL 任務是97%、81% 左右。

  血緣架構對比  

  上圖為三個版本對比情況:

  血緣的消費方式

  :第一版只支援 API 的方式,使用者需要在資料資產平臺上檢視血緣資訊;第二版支援離線數倉,讓使用者可以全量分析血緣;第三版支援訊息佇列,使使用者可以獲取血緣增量的變化。

  增量更新:

  第三版開始支援增量更新。

  血緣任務:

  第二個版本開始支援任務血緣,第三個版本支援資料質量。

  後設資料儲存統一:

  第三版進行了後設資料架構升級,使得後設資料和血緣儲存在同一個地方。

  新血緣接入耗時:

  前兩個版本大概需要花費 7-10 天左右。第三版本引入標準化,外部業務方或位元組內部用標準化流程,實現 3、4 天左右完成開發、測試、上線。

  未來展望

  第一,持續對架構和流程進行精簡。 目前,血緣任務分為離線和實時兩部分,但沒有完全統一。在外掛化、橫向擴充套件等方面也需要加強。

  第二,生態化支援。 目前支援公司內部的後設資料,未來計劃擴充對開源或外部後設資料的支援。在血緣標準化方面,提供一站式資料血緣能力,作為基礎能力平臺為業務方提供服務。

  第三,提升資料質量。 除了血緣數量,還需要持續提升質量。同時由於資料鏈路複雜,導致鏈路問題排查異常困難,未來我們也會支援快速診斷。

  最後,支援智慧化場景。 結合元數倉等資料,提供包含關鍵鏈路梳理在內的智慧化能力。目前,當業務方發現資料有問題之後,主要透過按照血緣資料一個一個排查方式解決,導致效率低下。未來,我們將考慮透出血緣關鍵鏈路,提升排查效率。

來自 “ 位元組跳動技術團隊 ”, 原文作者:DataLeap以亮;原文連結:http://server.it168.com/a2023/0228/6791/000006791614.shtml,如有侵權,請聯絡管理員刪除。

相關文章