騰訊歐拉平台數據血緣架構及套用

導讀 本文將介紹騰訊歐拉數據血緣的建設及套用 。

主要內容包括以下幾個部份：

1. 背景和目標

2. 計畫架構

3. 模組化建設

4. 套用場景

5. 問答環節

分享嘉賓｜ 韓立 騰訊 數據工程師

編輯整理｜彭爽

內容校對｜李瑤

出品社群｜ DataFun

01

背景和目標

騰訊歐拉數據平台，是一款基於 DataOps 理念，實作生產即治理的一站式數據平台，主要包括三個子產品：

數據血緣是歐拉的一個子模組，直接服務於以上三個子產品，也是本次分享的主題。

為什麽要做數據血緣？主要有兩個原因，一個是現狀不能滿足血緣數據需求，另一個是希望以血緣為基礎做更多的事情。

之前公司內部另外一個 BG 負責引擎的開發，我們只能拿到 yarn 日誌和 hook 的相關資訊，所以只能拿到離線數倉內部表級別的數據血緣，拿不到埋點日誌下發到管道再接入離線數倉這種鏈路血緣，因此整體覆蓋度不夠。另外，血緣的粒度不夠細，我們之前拿到的是表級別的血緣，但需要欄位級的血緣。同時，介面服務功能較少，有一些限流的限制。還有一個比較重要的問題是缺少血緣圖譜挖掘計算模型，包括演算法庫。

我們還希望能夠以血緣為基礎做更多的事情，包括全鏈路的數據治理、指標的全鏈路觀測、血緣的成本洞察，以及基於血緣的一些數倉開發。這些問題和需求共同催生了歐拉數據血緣的建設。

血緣的建設包括兩個方面，首先是提升數據血緣的 廣度 ，涵蓋從數據生產、數據加工，到數據套用的全鏈路。包括數據生產環節的騰訊燈塔、大同，數據加工環節的歐拉平台，以及數據套用環節的 DataTalk 報表、TAB 的 ABtest 等等，已覆蓋 20+ 產品，形成了非常完整的全鏈路資源。

另一方面，提升數據血緣的 深度 ，做更精細化的血緣建設。除了任務血緣之外，還有表血緣、欄位血緣，目前欄位血緣是最深的層級，而我們在研發一種更深層級的血緣，稱為數值血緣。

任務血緣的主要工作是打通各平台產品間的任務級別抽象，實作全鏈路、跨平台的完整的任務血緣關系圖譜，覆蓋了騰訊內部多種離線和即時數據產品。

表血緣是要打造全鏈路血緣數據圖譜，包括各種表級別的抽象，比如離線 Hive 表、MySQL 關系庫的表，還有 OLAP、Impala 等等，訊息佇列也被定義為表級別的抽象。

在表血緣的基礎上，我們會把血緣粒度拓展至欄位級別。目前已經完成了離線數倉內部 SQL 任務的欄位血緣建設。如果不考慮非 SQL 的任務（jar 包任務或 Spark 任務），欄位級血緣會產生斷層，我們的策略是以表血緣為基礎，上下遊進行全量依賴。假設下遊表的每個欄位都依賴於上遊表的全部欄位，可以把整個欄位血緣串起來，避免中間產生斷層。

數值血緣是我們內部開發的更深層次的血緣。基於 SQL 解析後的 AST，分成實體池、邏輯池和模型池，以這三個池為基礎，放在圖柯瑞，就可以形成一張非常大的AST 粒度的血緣圖譜。覆蓋的產品主要包括 calcite 、NTLR 等。數值血緣可以幫助我們辨識出加工某個指標所需的全部前置數據集合，這是目前我們在進行的最深粒度的血緣建設。

數據血緣有著非常多的套用場景，包括歐拉血緣查詢服務，還有很多基線計畫、成本分攤計畫以及各種數據治理項。覆蓋的業務包括整體 PCG 的 ToC 業務，比如 QQ、騰訊視訊、騰訊新聞、騰訊看點、微視、套用寶等。

02

計畫架構

接下來介紹歐拉數據血緣計畫架構。

我們首先進行了選型工作。

第一個考察的產品是 Apache 的 Atlas，這也是目前使用率最廣的數據血緣開源產品，但在實際套用中存在著一些問題，比如 Atlas 只有表級血緣，欄位血緣不完善，且對大數據引擎的依賴比較強，關系擴充套件也比較麻煩，需要比較多的二次開發。

另一些產品，如 OpenMetadata、Datahub，它們對血緣的支持相對比較弱，更側重於後設資料管理和數據發現的服務。Metacat、Amundsen 基本上只有數據發現功能。

基於以上原因，我們最終選擇基於騰訊豐富的產品生態自建血緣架構，如 EasyGraph 圖資料庫和成熟的 ES 產品，還有分布式的基於記憶體的 NoSQL 服務 Meepo 等等。

上圖展示了整體的計畫架構。最底層 UniMeta，是歐拉內部的後設資料管理平台，包含數據的接入和匯出。血緣建設是基於 UniMeta 接過來的一些基礎數據，比如 Yarn 日誌，我們從中解析出讀表和寫表。UniMeta 中還包括經常用到的 Hive 的 hook 機制。我們也會透過 UniMeta 同步一些產品配置，比如離線表匯出到MySQL、Impala、ClickHouse，基本上都是透過產品配置來進行血緣的解析。還有其它一些產品會發來內部血緣的訊息佇列。極端情況下，比如 jar 包任務，會有一些手工填報的血緣。整體上包括離線、即時和介面三種數據型別。

在 UniMeta 基礎之上，有血緣 ETL 邏輯加工，常規數倉的建模和加工環節，包括數據清洗、血緣淘汰、血緣融合等。血緣關系整體上分成兩類，一類是血緣關系，即存在實際數據流轉關系；另一種是我們建立的對應關系，比如表和任務之間或表和欄位之間的對應關系。

其中有一部份數據會透過 SQL 解析框架，進行 SQL 層級的血緣解析，最終把解析好的數據輸出到 ETL。SQL 解析框架，底層是我們自研的 SQL 解析引擎，附帶程式碼格式化。還有基於 AST 的演算法庫，實作 AST 級別 SQL 的使用者操作。

在 ETL 基礎之上，有全鏈路的血緣數據品質監控，會生成血緣整體的監控報表。目前，表級血緣的層級有 40+ 層。這裏會催生一些數據治理項，在正常的數倉建模情況下應該不會有這麽高的層級，我們會把高層級異常的血緣推播給使用者，進行血緣的壓縮，最佳化整個數據鏈路。另外，還會對表的上下遊數量進行監控。

在血緣基礎之上，基於 GraphX 構建了圖演算法庫，因為整體的 AST 血源是一個樹形結構。我們利用 GraphX 的叠代計算功能，最終形成精細化的血緣建設，包含任務級血緣、表級血緣、欄位級血緣、數值血緣，還可以自訂血緣圖譜，這些都會儲存到圖譜資料庫裏。

底層的數據結構包含 EasyGraph，就是圖資料庫，ES 用於節點內容的模糊檢索，MySQL 用來儲存後設資料資訊，Redis 提供預計算的功能，GraphX 把血源的全部下遊整體計算好之後，數據以 KV 的形式放在 Redis 裏，增加血緣查詢的效率以及介面存取速度。另外還會把血緣在離線倉 TDW 備份。

依托血緣數據，以 REST APIS 的形式對外提供統一的血緣服務，包括數據檢索服務、血緣查詢服務、路徑查詢服務。

透過 UniMeta 的智慧閘道器和許可權管理對外賦能，目前更多的是血緣在內部的套用，包括數據治理、成本血緣建設、基線計畫、數倉開發、血緣查詢。

03

模組化建設

接下來介紹每個子模組的細節。

首先是統一的實體 UID 規範。因為圖譜包含不同型別的節點，需要設計一套統一的 UID 規範。包含表、欄位、任務、訊息佇列、NoSQL(Redis 或者 Hbase)，還有 HDFS 的路徑和 API 介面，都會納入到全鏈路的血緣數據圖譜裏。目前已經接入 40 多個實體型別。

這裏設計了一套 UID 的生成規則，參考了 URL 的設計理念，其中 product 對應的是 scheme，因為騰訊內部透過規劃產品和營運產品來唯一定義一個計畫，所以使用 product 對 UID 進行唯一確定。在產品之下會有各種各樣的型別，type 欄位對應 URL 的 host:port，再透過內容來唯一定義一個實體型別。在 ID 的基礎之上，基於 MD5 的 hash 演算法生成唯一的 UID，再透過 UID 儲存到圖柯瑞。

我們還做了點邊解耦的操作，透過對點、邊進行分別的維護，點的維護人和邊的維護人可以不一樣，這可以保證底層點內容的統一，避免重復接入，還可以提供比較好的靈活性和擴充套件性。

下一個介紹的是血緣的邊建設。邊建設采用了化整為零的策略，構建原子關系，例如離線數倉內部表和表之間就是原子關系，表匯出到 MySQL 或 ClickHouse 也是一種原子關系。關系分為兩種型別，一種是存在數據流轉的關系，這個關系其實就是普通意義上的血緣關系，比如任務血緣、表血緣、欄位血緣。另外一種關系就是對應關系，比如表和任務的對應關系，任務和例項的對應關系。

構建了原子關系之後，就可以對這些原子關系進行自由的組合去生成自訂的血緣圖譜，並提供了圖譜路徑的查詢介面，例如右側自訂血緣的介面，可以透過任務找到其下遊任務，再透過下遊任務找到對應的表，然後再透過這個表找到對應的下遊表，最後找到對應的 HDFS，形成一種路徑查詢。

上圖是整體的 SQL 解析框架，目前大部份的大數據引擎 SQL 解析都是基於 Calcite 和 Antlr。有這個資訊之後，並不是直接對 SQL 進行解析，而是對 Calcite 和 Antlr 生成的語法樹進行轉換操作，轉換成自研的 AST 語法樹，會提供一個非常方便的轉換模組，相應的有一些完善的 debug 機制，還有類似 Calcite 的語法擴充套件功能。

我們 AI 自研的語法結構，相比原生的 Calcite 會有一些優勢。在某些特定的場景下，我們會打通和圖庫的融合，在圖柯瑞儲存數倉所有 SQL 任務，這樣做的好處在於，比如我們有一個 AST 演算法庫，從 SQL 中選擇一個欄位，把所有相關聯的邏輯取出來，再組合成線上可以執行的 SQL，就會形成 AST 級別的血緣。我們也有基於 AST 對 SQL 的轉換，還有程式碼視覺化的模組，比如可以按照 PCG 內部 SQL 的格式化標準，使用者不需要再關註程式碼格式，只需要透過公用的工具來進行格式化，特別是在進行 code review 的時候。我們以 UDF 的形式對外提供後端的介面服務，還有 SQL 的視覺化服務。

圖演算法庫是比較有特色的一個功能，基於 Spark 的 GraphX 來進行圖計算。目前已經落地的場景，包括血緣數據探查，例如上下遊的最大深度，還有層級的分布情況以及血緣環路的檢測，我們會進行相應的檢測，推播給業務進行數據治理。

此外，還有數據治理的挖掘項，包括常見的冷表冷欄位的下線，耗時最長鏈路的最佳化。

第三塊，我們會用 GraphX 做血緣的預計算，如果只從圖庫進行血緣的上下遊查詢，有時候它的介面響應速度不是那麽理想，我們會用 GraphX 做一個圖計算，然後把數據放在 Redis 裏，提升介面的存取速度。

最後是成本分攤計畫，後面會有詳細介紹。

在構建血緣的過程中，會做全鏈路血緣數據品質的監控和探查。前文中提到了血緣整體的數據監控報表，再來講一下數據一致性的保證，我們采用了 Lambda 架構來構建血緣數據。在此過程中，需要保證兩方面的數據一致性，第一個是離線和即時數據的一致性，因為即時和離線是分別處理的。第二是需要保證圖庫和離線數據的一致性，離線數據在匯入圖庫的時候可能會產生數據上的偏差。之所以采用 Lambda 架構是因為目前血緣數據仍然以離線數據為準，即時的血緣不能覆蓋全部的血緣關系。

圖計算和挖掘任務是依賴於離線數據的，右邊的圖是保證一致性的架構。第一步即時任務正常寫入 todo。第二個流程，是來解決離線和即時數據的一致性，在 2.1 的時候，會向即時任務發送消費暫停的訊號，即時任務就會停止寫入圖庫，再用離線數據去更新圖柯瑞的數據，這樣來保證離線和即時數據的一致性。第三個流程是用來保證圖庫和離線數據的一致性，采用圖庫數據進行一個 dump 操作，dump 之後再和離線數據進行對比，將差異向圖庫同步。在第四步，向即時任務發送正常消費訊號，任務就可以正常進行消費。

透過 REST API 對外提供統一的血緣服務。首先數據檢索是直接基於圖數據儲存的 ES 數據，目前可以進行任務節點、表節點、指標的模糊檢索。

即時血緣查詢是基於內部 EasyGraph 圖庫，來進行即時的血緣查詢，包括上下遊的多層級血緣查詢、血緣視覺化的互動與展示，這邊也會提供預計算的血緣查詢服務，首先使用 GraphX 進行血緣的預計算，比如剛才提到有 4 萬多個下遊的節點，如果圖庫好的話需要幾分鐘，這在產品級別是不能接受的。這種情況下，我們就會使用預計算的數據，響應時間就會壓縮到幾十毫秒。

在統一血緣服務基礎之上，會透過智慧閘道器和許可權管理進行對外賦能，另一方面我們用內部套用直接進行呼叫。

04

套用場景

最後介紹內部的套用場景，整體分為五大類。

1. 數據治理

數據治理，整體按數據治理的難度分為淺水區和深水區。

淺水區包含表熱度和欄位熱度，低熱度或者無熱度的冷表下線、冷欄位下線和冷數據下線。再往下一層會有空跑任務的下線和空跑邏輯的下線，如果某個欄位判定為冷欄位，那麽這個欄位的所有加工邏輯就會被判斷為空跑邏輯，我們會把這些資訊發給使用者，讓使用者進行 SQL 級別的下線操作。

深水區包括重復計算的判斷，也是基於 AST 級別的血緣建設，最終我們希望形成表 ROI、欄位 ROI還有指標 ROI 的建設，目前還在開發中。

2. 全鏈路血緣成本洞察

之前的成本核算和分攤不夠精確，我們把中台或者上遊產品的成本向業務分攤，目前參照的是用量，但是用量難以準確反映出下遊實際使用了多少成本。透過把成本和血緣進行結合，能夠把每個上遊表的成本向每一個下遊節點進行分攤，整體構成了全鏈路血緣成本的鏈路。

右圖是整體的構建思路，首先第一層有 a、b、c、d、e、f 6 個節點，每個節點都有對應的成本，逐層進行分攤，第一層 a 節點會向它的下遊 b 和 c 分別分攤 100 / 2，會產生 50 的成本，低的節點目前就會有 150 的成本，依次再進行第二層、第三層的分攤，這樣把所有節點的成本分攤到全部的葉子節點。不一定所有的葉子節點都是我們的成本節點，例如原子指標和衍生指標，可能衍生指標的表是基於原子指標表來進行開發的，但是原子指標和衍生指標都會作為成本節點來進行分攤。

3. 全鏈路成本血緣洞察

這裏我們碰到一些問題，例如成本節點如何確定？目前采用的方式是，把所有的葉子節點判斷為成本節點，但在實際業務中會與此不太一致。所以我們也提供了一個方案，讓使用者自己來確定是否是成本節點，自行進行補充和選擇。

第二個問題就是成本逐層向下分攤時的權重問題，目前我們采用的是向下遊平均分攤成本的方式，各個子節點的權重是 n 分之一，但很多業務提出這樣做是有問題的，理想的方式是按照下遊的實際使用量，包含欄位維度和記錄數的維度，欄位維度就是下遊使用了上遊表的多少個欄位，然後記錄數維度就是下遊在它的 where 條件中用這個條件查出來了多少記錄數，目前還在研究與開發中。

還有環路問題，稍微有些復雜，我們考慮了幾種方案。首先把環路進行拆解，從 c 到 a 就不會去分擔成本。第二個方案是是無限迴圈的分攤方案，它會讓環路進行無限迴圈，最終它會在每一個節點上分攤到無限迴圈之後的成本，其實可以透過無窮級數來事先預計算，不需要無限迴圈，只需要迴圈一次，乘以無窮級數的求和的結果就可以了。不過我們最終采用的是環路的整體判斷方案，把 a、b、c 作為環路的整體，然後再向 d 進行分攤。

第四個是圖計算的效能問題，我們用 GraphX 進行圖計算，叠代次數過多，會有數據傾斜的問題，我們綜合采用了多種方案來進行效能最佳化。實際套用可以使成本治理，從單點擴充套件到全部鏈路，成本分攤的邏輯，更加符合數據加工的邏輯。我們可以幫助業務直接觀察到自身的成本來源，幫助上遊產品(數據中台)向下遊分攤自身的成本。另外我們會針對單個節點，給出對應的成本最佳化建議。最終我們希望以血緣成本為基礎，進行數倉的全域最佳化。

4. 基線計畫

最後是基線計畫，對整個任務鏈條進行監控和保障。具體實作過程為，A、B、C、D 是正常的數據鏈路，比如 D 是保障任務，某一天 B 任務延遲，導致其下遊延遲。在基線計畫中有一個水位線的概念，與 Flink 處理延遲訊息的水位線比較類似，因為 B 的延遲導致了 D 的水位線超過了預警線，在這種情況下，會在整個鏈條上進行預警，這只是單個任務。比如 D 任務可能會有其他的路徑，它的每一條路徑都會推高 D 的水位線，如果超過預警線就會進行監控預警。

上圖是基線計畫的整體結構，可以實作全鏈路的可追蹤、可預警和可歸因，比較核心的服務，例如完成時間的預測、動態最長路徑的推播、歷史最長路徑的計算，會以兩種形式推播給使用者，第一種是企業微信以文本形式來推播，第二種是透過一個平台，以甘特圖的形式展示出全鏈路整體的延遲或者監控情況。

以上就是本次分享的內容，謝謝大家。

05

問答環節

Q1 ：請問從頭開始血緣關系建設的話，是從任務到欄位建設好，還是從欄位到任務建設好？

A1：我們推薦從任務到欄位，表血緣需要和任務血緣進行對齊操作，欄位血緣也需要和表血緣進行對齊操作。表血緣的上下遊有，它的欄位血緣肯定是要有上下遊關系的。還有一個情況，目前任務級血緣是最準的，因為任務血緣是使用者進行線上的任務增刪改查的操作，下發的訊息或者 MDB 數據，所以我們還是推薦從任務血緣向表血緣和欄位血緣進行向下建設。

Q2 ：怎麽評估血緣的準確性？

A2：我們有一個內部監控，這個監控只能去監控解析的成功率和一些比較固定的形式。我們目前采用的方法還是結合固定監控和人工探查。比如欄位血緣，其實目前的解析準確率已經很高了，能達到 99% 以上，但是 99% 這個數值，也是透過人工選取一些樣例數據，對比解析的結果和人工判斷的結果，得到的準確率。

Q3 ：在讀寫數據的時候用的 JDBC 或者自訂的 data source，怎麽把這些血緣串聯起來？現在是否支持？

A3：我們目前能夠收集到的就是任務的配置，但是 JDBC 我們目前還沒有介入到這一塊，因為可能涉及到jar 包任務。剛才提到 jar 包任務，我們會進行上下遊表級血緣的全量依賴，並對欄位級別進行存量依賴。我們會分兩個概念，表級別的，我們可以透過配置來拿到，欄位級別就會使用表級別的血緣進行上下遊的存量依賴。

Q4 ：基線計畫的使用者都有哪些角色？

A4：基線計畫目前主要面對的是 DE 和 DS，即數據工程師和數據分析師，保證任務和指標能夠正常產出。他們會關註任務今天為什麽會延遲，會逐層地往上找，我們透過基線計畫及時給他發一個預警，告訴他鏈條中哪一個節點出了延遲或者出了問題，方便快速地進行定位。

Q5 ：支持 Spark dataframe 的欄位血緣嗎？

A5：這個屬於 jar 包任務，目前處於全量依賴的階段，根據表血源去把欄位血源制成全量依賴，避免欄位級別的血緣突然在某一層斷掉。

Q6 ：主要用的數據結構和演算法？

A6：SQL 解析框架用到的數據結構和演算法會比較多，因為這個是純自研的 SQL 解析框架，並且它和普通的 SQL 解析框架還不太一樣，它不是直接去寫 SQL 的 Parser，而是基於 Calcite 和 Antlr 解析好的 AST 語法樹，進行轉換操作，轉換到我們自研的語法結構。數據結構主要是遞迴和回溯，另外有比較細節的演算法，處理某個問題節點會套用到特定的演算法。

Q7 ：歐拉平台考慮對外開放嗎？還是只對內？如果對外開放依賴元件這麽多，會不會有維護和運維的成本？

A7：據我了解，是有對外開放規劃的，而且目前已經和多方進行了合作。歐拉平台有一些模組整合在騰訊雲上，有對外售賣。例如治理引擎，對事後的存量數據資產進行問題的掃描、發現、推進、治理等等。這個模組目前在騰訊雲上是有對外開放的。歐拉在內部的平台更加完善，功能也更多，有一些跟內部的元件有深度的耦合和依賴。未來我們也會逐步考慮有哪些元件可以抽象出來，對外開放。

以上就是本次分享的內容，謝謝大家。

分享嘉賓

INTRODUCTION

韓立

騰訊

數據工程師

在大數據領域有多年的工作經驗，現在騰訊負責歐拉數據產品旗下的數據血緣模組，包含數據生產端、數據加工鏈路和數據套用端的完整的全鏈路血緣，涉及後設資料采集、血緣解析、分層建設、血緣圖譜搭建、血緣資料探勘等多個環節 。

活動推薦

往期推薦

點個 在看 你最好看