一、背景和目標(biāo)

騰訊歐拉數(shù)據(jù)平臺(tái)，是一款基于 DataOps 理念，實(shí)現(xiàn)生產(chǎn)即治理的一站式數(shù)據(jù)平臺(tái)，主要包括三個(gè)子產(chǎn)品：

• 首先是資產(chǎn)工廠，負(fù)責(zé)整體的數(shù)倉(cāng)建設(shè)、數(shù)倉(cāng)模型的開(kāi)發(fā)。
• 第二塊是歐拉的治理引擎，負(fù)責(zé)全鏈路成本的數(shù)據(jù)治理。
• 第三塊是數(shù)據(jù)發(fā)現(xiàn)，負(fù)責(zé)元數(shù)據(jù)的管理。

數(shù)據(jù)血緣是歐拉的一個(gè)子模塊，直接服務(wù)于以上三個(gè)子產(chǎn)品，也是本次分享的主題。

為什么要做數(shù)據(jù)血緣？主要有兩個(gè)原因，一個(gè)是現(xiàn)狀不能滿(mǎn)足血緣數(shù)據(jù)需求，另一個(gè)是希望以血緣為基礎(chǔ)做更多的事情。

之前公司內(nèi)部另外一個(gè) BG 負(fù)責(zé)引擎的開(kāi)發(fā)，我們只能拿到 yarn 日志和 hook 的相關(guān)信息，所以只能拿到離線數(shù)倉(cāng)內(nèi)部表級(jí)別的數(shù)據(jù)血緣，拿不到埋點(diǎn)日志下發(fā)到管道再接入離線數(shù)倉(cāng)這種鏈路血緣，因此整體覆蓋度不夠。另外，血緣的粒度不夠細(xì)，我們之前拿到的是表級(jí)別的血緣，但需要字段級(jí)的血緣。同時(shí)，接口服務(wù)功能較少，有一些限流的限制。還有一個(gè)比較重要的問(wèn)題是缺少血緣圖譜挖掘計(jì)算模型，包括算法庫(kù)。

我們還希望能夠以血緣為基礎(chǔ)做更多的事情，包括全鏈路的數(shù)據(jù)治理、指標(biāo)的全鏈路觀測(cè)、血緣的成本洞察，以及基于血緣的一些數(shù)倉(cāng)開(kāi)發(fā)。這些問(wèn)題和需求共同催生了歐拉數(shù)據(jù)血緣的建設(shè)。

血緣的建設(shè)包括兩個(gè)方面，首先是提升數(shù)據(jù)血緣的廣度，涵蓋從數(shù)據(jù)生產(chǎn)、數(shù)據(jù)加工，到數(shù)據(jù)應(yīng)用的全鏈路。包括數(shù)據(jù)生產(chǎn)環(huán)節(jié)的騰訊燈塔、大同，數(shù)據(jù)加工環(huán)節(jié)的歐拉平臺(tái)，以及數(shù)據(jù)應(yīng)用環(huán)節(jié)的 DataTalk 報(bào)表、TAB 的 ABtest 等等，已覆蓋 20+ 產(chǎn)品，形成了非常完整的全鏈路資源。

另一方面，提升數(shù)據(jù)血緣的深度，做更精細(xì)化的血緣建設(shè)。除了任務(wù)血緣之外，還有表血緣、字段血緣，目前字段血緣是最深的層級(jí)，而我們?cè)谘邪l(fā)一種更深層級(jí)的血緣，稱(chēng)為數(shù)值血緣。

任務(wù)血緣的主要工作是打通各平臺(tái)產(chǎn)品間的任務(wù)級(jí)別抽象，實(shí)現(xiàn)全鏈路、跨平臺(tái)的完整的任務(wù)血緣關(guān)系圖譜，覆蓋了騰訊內(nèi)部多種離線和實(shí)時(shí)數(shù)據(jù)產(chǎn)品。

表血緣是要打造全鏈路血緣數(shù)據(jù)圖譜，包括各種表級(jí)別的抽象，比如離線 Hive 表、MySQL 關(guān)系庫(kù)的表，還有 OLAP、Impala 等等，消息隊(duì)列也被定義為表級(jí)別的抽象。

在表血緣的基礎(chǔ)上，我們會(huì)把血緣粒度拓展至字段級(jí)別。目前已經(jīng)完成了離線數(shù)倉(cāng)內(nèi)部 SQL 任務(wù)的字段血緣建設(shè)。如果不考慮非 SQL 的任務(wù)（jar 包任務(wù)或 Spark 任務(wù)），字段級(jí)血緣會(huì)產(chǎn)生斷層，我們的策略是以表血緣為基礎(chǔ)，上下游進(jìn)行全量依賴(lài)。假設(shè)下游表的每個(gè)字段都依賴(lài)于上游表的全部字段，可以把整個(gè)字段血緣串起來(lái)，避免中間產(chǎn)生斷層。

數(shù)值血緣是我們內(nèi)部開(kāi)發(fā)的更深層次的血緣?；?SQL 解析后的 AST，分成實(shí)體池、邏輯池和模型池，以這三個(gè)池為基礎(chǔ)，放在圖庫(kù)里，就可以形成一張非常大的AST 粒度的血緣圖譜。覆蓋的產(chǎn)品主要包括 calcite 、NTLR 等。數(shù)值血緣可以幫助我們識(shí)別出加工某個(gè)指標(biāo)所需的全部前置數(shù)據(jù)集合，這是目前我們?cè)谶M(jìn)行的最深粒度的血緣建設(shè)。

數(shù)據(jù)血緣有著非常多的應(yīng)用場(chǎng)景，包括歐拉血緣查詢(xún)服務(wù)，還有很多基線項(xiàng)目、成本分?jǐn)傢?xiàng)目以及各種數(shù)據(jù)治理項(xiàng)。覆蓋的業(yè)務(wù)包括整體 PCG 的 ToC 業(yè)務(wù)，比如 QQ、騰訊視頻、騰訊新聞、騰訊看點(diǎn)、微視、應(yīng)用寶等。

二、項(xiàng)目架構(gòu)

接下來(lái)介紹歐拉數(shù)據(jù)血緣項(xiàng)目架構(gòu)。

我們首先進(jìn)行了選型工作。

第一個(gè)考察的產(chǎn)品是 Apache 的 Atlas，這也是目前使用率最廣的數(shù)據(jù)血緣開(kāi)源產(chǎn)品，但在實(shí)際應(yīng)用中存在著一些問(wèn)題，比如 Atlas 只有表級(jí)血緣，字段血緣不完善，且對(duì)大數(shù)據(jù)引擎的依賴(lài)比較強(qiáng)，關(guān)系擴(kuò)展也比較麻煩，需要比較多的二次開(kāi)發(fā)。

另一些產(chǎn)品，如 OpenMetadata、Datahub，它們對(duì)血緣的支持相對(duì)比較弱，更側(cè)重于元數(shù)據(jù)管理和數(shù)據(jù)發(fā)現(xiàn)的服務(wù)。Metacat、Amundsen 基本上只有數(shù)據(jù)發(fā)現(xiàn)功能。

基于以上原因，我們最終選擇基于騰訊豐富的產(chǎn)品生態(tài)自建血緣架構(gòu)，如 EasyGraph 圖數(shù)據(jù)庫(kù)和成熟的 ES 產(chǎn)品，還有分布式的基于內(nèi)存的 NoSQL 服務(wù) Meepo 等等。

上圖展示了整體的項(xiàng)目架構(gòu)。最底層 UniMeta，是歐拉內(nèi)部的元數(shù)據(jù)管理平臺(tái)，包含數(shù)據(jù)的接入和導(dǎo)出。血緣建設(shè)是基于 UniMeta 接過(guò)來(lái)的一些基礎(chǔ)數(shù)據(jù)，比如 Yarn 日志，我們從中解析出讀表和寫(xiě)表。UniMeta 中還包括經(jīng)常用到的 Hive 的 hook 機(jī)制。我們也會(huì)通過(guò) UniMeta 同步一些產(chǎn)品配置，比如離線表導(dǎo)出到MySQL、Impala、ClickHouse，基本上都是通過(guò)產(chǎn)品配置來(lái)進(jìn)行血緣的解析。還有其它一些產(chǎn)品會(huì)發(fā)來(lái)內(nèi)部血緣的消息隊(duì)列。極端情況下，比如 jar 包任務(wù)，會(huì)有一些手工填報(bào)的血緣。整體上包括離線、實(shí)時(shí)和接口三種數(shù)據(jù)類(lèi)型。

在 UniMeta 基礎(chǔ)之上，有血緣 ETL 邏輯加工，常規(guī)數(shù)倉(cāng)的建模和加工環(huán)節(jié)，包括數(shù)據(jù)清洗、血緣淘汰、血緣融合等。血緣關(guān)系整體上分成兩類(lèi)，一類(lèi)是血緣關(guān)系，即存在實(shí)際數(shù)據(jù)流轉(zhuǎn)關(guān)系；另一種是我們建立的對(duì)應(yīng)關(guān)系，比如表和任務(wù)之間或表和字段之間的對(duì)應(yīng)關(guān)系。

其中有一部分?jǐn)?shù)據(jù)會(huì)通過(guò) SQL 解析框架，進(jìn)行 SQL 層級(jí)的血緣解析，最終把解析好的數(shù)據(jù)輸出到 ETL。SQL 解析框架，底層是我們自研的 SQL 解析引擎，附帶代碼格式化。還有基于 AST 的算法庫(kù)，實(shí)現(xiàn) AST 級(jí)別 SQL 的用戶(hù)操作。

在 ETL 基礎(chǔ)之上，有全鏈路的血緣數(shù)據(jù)質(zhì)量監(jiān)控，會(huì)生成血緣整體的監(jiān)控報(bào)表。目前，表級(jí)血緣的層級(jí)有 40+ 層。這里會(huì)催生一些數(shù)據(jù)治理項(xiàng)，在正常的數(shù)倉(cāng)建模情況下應(yīng)該不會(huì)有這么高的層級(jí)，我們會(huì)把高層級(jí)異常的血緣推送給用戶(hù)，進(jìn)行血緣的壓縮，優(yōu)化整個(gè)數(shù)據(jù)鏈路。另外，還會(huì)對(duì)表的上下游數(shù)量進(jìn)行監(jiān)控。

在血緣基礎(chǔ)之上，基于 GraphX 構(gòu)建了圖算法庫(kù)，因?yàn)檎w的 AST 血源是一個(gè)樹(shù)形結(jié)構(gòu)。我們利用 GraphX 的迭代計(jì)算功能，最終形成精細(xì)化的血緣建設(shè)，包含任務(wù)級(jí)血緣、表級(jí)血緣、字段級(jí)血緣、數(shù)值血緣，還可以自定義血緣圖譜，這些都會(huì)存儲(chǔ)到圖譜數(shù)據(jù)庫(kù)里。

底層的數(shù)據(jù)結(jié)構(gòu)包含 EasyGraph，就是圖數(shù)據(jù)庫(kù)，ES 用于節(jié)點(diǎn)屬性的模糊檢索，MySQL 用來(lái)存儲(chǔ)元數(shù)據(jù)信息，Redis 提供預(yù)計(jì)算的功能，GraphX 把血源的全部下游整體計(jì)算好之后，數(shù)據(jù)以 KV 的形式放在 Redis 里，增加血緣查詢(xún)的效率以及接口訪問(wèn)速度。另外還會(huì)把血緣在離線倉(cāng) TDW 備份。

依托血緣數(shù)據(jù)，以 REST APIS 的形式對(duì)外提供統(tǒng)一的血緣服務(wù)，包括數(shù)據(jù)檢索服務(wù)、血緣查詢(xún)服務(wù)、路徑查詢(xún)服務(wù)。

通過(guò) UniMeta 的智能網(wǎng)關(guān)和權(quán)限管理對(duì)外賦能，目前更多的是血緣在內(nèi)部的應(yīng)用，包括數(shù)據(jù)治理、成本血緣建設(shè)、基線項(xiàng)目、數(shù)倉(cāng)開(kāi)發(fā)、血緣查詢(xún)。

三、模塊化建設(shè)

接下來(lái)介紹每個(gè)子模塊的細(xì)節(jié)。

首先是統(tǒng)一的實(shí)體 UID 規(guī)范。因?yàn)閳D譜包含不同類(lèi)型的節(jié)點(diǎn)，需要設(shè)計(jì)一套統(tǒng)一的 UID 規(guī)范。包含表、字段、任務(wù)、消息隊(duì)列、NoSQL(Redis 或者 Hbase)，還有 HDFS 的路徑和 API 接口，都會(huì)納入到全鏈路的血緣數(shù)據(jù)圖譜里。目前已經(jīng)接入 40 多個(gè)實(shí)體類(lèi)型。

這里設(shè)計(jì)了一套 UID 的生成規(guī)則，參考了 URL 的設(shè)計(jì)理念，其中 product 對(duì)應(yīng)的是 scheme，因?yàn)轵v訊內(nèi)部通過(guò)規(guī)劃產(chǎn)品和運(yùn)營(yíng)產(chǎn)品來(lái)唯一定義一個(gè)項(xiàng)目，所以使用 product 對(duì) UID 進(jìn)行唯一確定。在產(chǎn)品之下會(huì)有各種各樣的類(lèi)型，type 字段對(duì)應(yīng) URL 的 host:port，再通過(guò)屬性來(lái)唯一定義一個(gè)實(shí)體類(lèi)型。在 ID 的基礎(chǔ)之上，基于 MD5 的 hash 算法生成唯一的 UID，再通過(guò) UID 存儲(chǔ)到圖庫(kù)里。

我們還做了點(diǎn)邊解耦的操作，通過(guò)對(duì)點(diǎn)、邊進(jìn)行分別的維護(hù)，點(diǎn)的維護(hù)人和邊的維護(hù)人可以不一樣，這可以保證底層點(diǎn)屬性的統(tǒng)一，避免重復(fù)接入，還可以提供比較好的靈活性和擴(kuò)展性。

下一個(gè)介紹的是血緣的邊建設(shè)。邊建設(shè)采用了化整為零的策略，構(gòu)建原子關(guān)系，例如離線數(shù)倉(cāng)內(nèi)部表和表之間就是原子關(guān)系，表導(dǎo)出到 MySQL 或 ClickHouse 也是一種原子關(guān)系。關(guān)系分為兩種類(lèi)型，一種是存在數(shù)據(jù)流轉(zhuǎn)的關(guān)系，這個(gè)關(guān)系其實(shí)就是普通意義上的血緣關(guān)系，比如任務(wù)血緣、表血緣、字段血緣。另外一種關(guān)系就是對(duì)應(yīng)關(guān)系，比如表和任務(wù)的對(duì)應(yīng)關(guān)系，任務(wù)和實(shí)例的對(duì)應(yīng)關(guān)系。

構(gòu)建了原子關(guān)系之后，就可以對(duì)這些原子關(guān)系進(jìn)行自由的組合去生成自定義的血緣圖譜，并提供了圖譜路徑的查詢(xún)接口，例如右側(cè)自定義血緣的接口，可以通過(guò)任務(wù)找到其下游任務(wù)，再通過(guò)下游任務(wù)找到對(duì)應(yīng)的表，然后再通過(guò)這個(gè)表找到對(duì)應(yīng)的下游表，最后找到對(duì)應(yīng)的 HDFS，形成一種路徑查詢(xún)。

上圖是整體的 SQL 解析框架，目前大部分的大數(shù)據(jù)引擎 SQL 解析都是基于 Calcite 和 Antlr。有這個(gè)信息之后，并不是直接對(duì) SQL 進(jìn)行解析，而是對(duì) Calcite 和 Antlr 生成的語(yǔ)法樹(shù)進(jìn)行轉(zhuǎn)換操作，轉(zhuǎn)換成自研的 AST 語(yǔ)法樹(shù)，會(huì)提供一個(gè)非常方便的轉(zhuǎn)換模塊，相應(yīng)的有一些完善的 debug 機(jī)制，還有類(lèi)似 Calcite 的語(yǔ)法擴(kuò)展功能。

我們 AI 自研的語(yǔ)法結(jié)構(gòu)，相比原生的 Calcite 會(huì)有一些優(yōu)勢(shì)。在某些特定的場(chǎng)景下，我們會(huì)打通和圖庫(kù)的融合，在圖庫(kù)里存儲(chǔ)數(shù)倉(cāng)所有 SQL 任務(wù)，這樣做的好處在于，比如我們有一個(gè) AST 算法庫(kù)，從 SQL 中選擇一個(gè)字段，把所有相關(guān)聯(lián)的邏輯取出來(lái)，再組合成線上可以執(zhí)行的 SQL，就會(huì)形成 AST 級(jí)別的血緣。我們也有基于 AST 對(duì) SQL 的轉(zhuǎn)換，還有代碼可視化的模塊，比如可以按照 PCG 內(nèi)部 SQL 的格式化標(biāo)準(zhǔn)，用戶(hù)不需要再關(guān)注代碼格式，只需要通過(guò)公用的工具來(lái)進(jìn)行格式化，特別是在進(jìn)行 code review 的時(shí)候。我們以 UDF 的形式對(duì)外提供后端的接口服務(wù)，還有 SQL 的可視化服務(wù)。

圖算法庫(kù)是比較有特色的一個(gè)功能，基于 Spark 的 GraphX 來(lái)進(jìn)行圖計(jì)算。目前已經(jīng)落地的場(chǎng)景，包括血緣數(shù)據(jù)探查，例如上下游的最大深度，還有層級(jí)的分布情況以及血緣環(huán)路的檢測(cè)，我們會(huì)進(jìn)行相應(yīng)的檢測(cè)，推送給業(yè)務(wù)進(jìn)行數(shù)據(jù)治理。

此外，還有數(shù)據(jù)治理的挖掘項(xiàng)，包括常見(jiàn)的冷表冷字段的下線，耗時(shí)最長(zhǎng)鏈路的優(yōu)化。

第三塊，我們會(huì)用 GraphX 做血緣的預(yù)計(jì)算，如果只從圖庫(kù)進(jìn)行血緣的上下游查詢(xún)，有時(shí)候它的接口響應(yīng)速度不是那么理想，我們會(huì)用 GraphX 做一個(gè)圖計(jì)算，然后把數(shù)據(jù)放在 Redis 里，提升接口的訪問(wèn)速度。

最后是成本分?jǐn)傢?xiàng)目，后面會(huì)有詳細(xì)介紹。

在構(gòu)建血緣的過(guò)程中，會(huì)做全鏈路血緣數(shù)據(jù)質(zhì)量的監(jiān)控和探查。前文中提到了血緣整體的數(shù)據(jù)監(jiān)控報(bào)表，再來(lái)講一下數(shù)據(jù)一致性的保證，我們采用了 Lambda 架構(gòu)來(lái)構(gòu)建血緣數(shù)據(jù)。在此過(guò)程中，需要保證兩方面的數(shù)據(jù)一致性，第一個(gè)是離線和實(shí)時(shí)數(shù)據(jù)的一致性，因?yàn)閷?shí)時(shí)和離線是分別處理的。第二是需要保證圖庫(kù)和離線數(shù)據(jù)的一致性，離線數(shù)據(jù)在導(dǎo)入圖庫(kù)的時(shí)候可能會(huì)產(chǎn)生數(shù)據(jù)上的偏差。之所以采用 Lambda 架構(gòu)是因?yàn)槟壳把墧?shù)據(jù)仍然以離線數(shù)據(jù)為準(zhǔn)，實(shí)時(shí)的血緣不能覆蓋全部的血緣關(guān)系。

圖計(jì)算和挖掘任務(wù)是依賴(lài)于離線數(shù)據(jù)的，右邊的圖是保證一致性的架構(gòu)。第一步實(shí)時(shí)任務(wù)正常寫(xiě)入 todo。第二個(gè)流程，是來(lái)解決離線和實(shí)時(shí)數(shù)據(jù)的一致性，在 2.1 的時(shí)候，會(huì)向?qū)崟r(shí)任務(wù)發(fā)送消費(fèi)暫停的信號(hào)，實(shí)時(shí)任務(wù)就會(huì)停止寫(xiě)入圖庫(kù)，再用離線數(shù)據(jù)去更新圖庫(kù)里的數(shù)據(jù)，這樣來(lái)保證離線和實(shí)時(shí)數(shù)據(jù)的一致性。第三個(gè)流程是用來(lái)保證圖庫(kù)和離線數(shù)據(jù)的一致性，采用圖庫(kù)數(shù)據(jù)進(jìn)行一個(gè) dump 操作，dump 之后再和離線數(shù)據(jù)進(jìn)行對(duì)比，將差異向圖庫(kù)同步。在第四步，向?qū)崟r(shí)任務(wù)發(fā)送正常消費(fèi)信號(hào)，任務(wù)就可以正常進(jìn)行消費(fèi)。

通過(guò) REST API 對(duì)外提供統(tǒng)一的血緣服務(wù)。首先數(shù)據(jù)檢索是直接基于圖數(shù)據(jù)存儲(chǔ)的 ES 數(shù)據(jù)，目前可以進(jìn)行任務(wù)節(jié)點(diǎn)、表節(jié)點(diǎn)、指標(biāo)的模糊檢索。

實(shí)時(shí)血緣查詢(xún)是基于內(nèi)部 EasyGraph 圖庫(kù)，來(lái)進(jìn)行實(shí)時(shí)的血緣查詢(xún)，包括上下游的多層級(jí)血緣查詢(xún)、血緣可視化的交互與展示，這邊也會(huì)提供預(yù)計(jì)算的血緣查詢(xún)服務(wù)，首先使用 GraphX 進(jìn)行血緣的預(yù)計(jì)算，比如剛才提到有 4 萬(wàn)多個(gè)下游的節(jié)點(diǎn)，如果圖庫(kù)好的話需要幾分鐘，這在產(chǎn)品級(jí)別是不能接受的。這種情況下，我們就會(huì)使用預(yù)計(jì)算的數(shù)據(jù)，響應(yīng)時(shí)間就會(huì)壓縮到幾十毫秒。

在統(tǒng)一血緣服務(wù)基礎(chǔ)之上，會(huì)通過(guò)智能網(wǎng)關(guān)和權(quán)限管理進(jìn)行對(duì)外賦能，另一方面我們用內(nèi)部應(yīng)用直接進(jìn)行調(diào)用。

四、應(yīng)用場(chǎng)景

最后介紹內(nèi)部的應(yīng)用場(chǎng)景，整體分為五大類(lèi)。

• 首先是數(shù)據(jù)治理，血緣最直接的應(yīng)用就是應(yīng)用在數(shù)據(jù)治理上，包括冷表、冷字段、甚至 HDFS 冷數(shù)據(jù)的下線，還有空跑任務(wù)、空跑邏輯的下線，耗時(shí)最長(zhǎng)鏈路的優(yōu)化等等。
• 第二是血緣查詢(xún)，直接面向用戶(hù)進(jìn)行血緣查詢(xún)。
• 第三是數(shù)倉(cāng)開(kāi)發(fā)，支持 SQL 代碼的可視化，邏輯資產(chǎn)管理，低效、無(wú)效代碼的檢測(cè)，因?yàn)槭?AST 級(jí)別的血緣，所以能夠有效地把低效和無(wú)效代碼檢測(cè)出來(lái)。另外，會(huì)基于 AST 的血緣進(jìn)行微數(shù)倉(cāng)相關(guān)的探索。
• 第四是基線項(xiàng)目，對(duì)全鏈路任務(wù)的失敗或者延遲進(jìn)行監(jiān)控。
• 最后是全鏈路血緣成本洞察項(xiàng)目，結(jié)合血緣和成本核算兩塊內(nèi)容。

1. 數(shù)據(jù)治理

數(shù)據(jù)治理，整體按數(shù)據(jù)治理的難度分為淺水區(qū)和深水區(qū)。

淺水區(qū)包含表熱度和字段熱度，低熱度或者無(wú)熱度的冷表下線、冷字段下線和冷數(shù)據(jù)下線。再往下一層會(huì)有空跑任務(wù)的下線和空跑邏輯的下線，如果某個(gè)字段判定為冷字段，那么這個(gè)字段的所有加工邏輯就會(huì)被判斷為空跑邏輯，我們會(huì)把這些信息發(fā)給用戶(hù)，讓用戶(hù)進(jìn)行 SQL 級(jí)別的下線操作。

深水區(qū)包括重復(fù)計(jì)算的判斷，也是基于 AST 級(jí)別的血緣建設(shè)，最終我們希望形成表 ROI、字段 ROI還有指標(biāo) ROI 的建設(shè)，目前還在開(kāi)發(fā)中。

2. 全鏈路血緣成本洞察

之前的成本核算和分?jǐn)偛粔蚓_，我們把中臺(tái)或者上游產(chǎn)品的成本向業(yè)務(wù)分?jǐn)?，目前參照的是用量，但是用量難以準(zhǔn)確反映出下游實(shí)際使用了多少成本。通過(guò)把成本和血緣進(jìn)行結(jié)合，能夠把每個(gè)上游表的成本向每一個(gè)下游節(jié)點(diǎn)進(jìn)行分?jǐn)?，整體構(gòu)成了全鏈路血緣成本的鏈路。

右圖是整體的構(gòu)建思路，首先第一層有 a、b、c、d、e、f 6 個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都有對(duì)應(yīng)的成本，逐層進(jìn)行分?jǐn)偅谝粚?a 節(jié)點(diǎn)會(huì)向它的下游 b 和 c 分別分?jǐn)?100 / 2，會(huì)產(chǎn)生 50 的成本，低的節(jié)點(diǎn)目前就會(huì)有 150 的成本，依次再進(jìn)行第二層、第三層的分?jǐn)?，這樣把所有節(jié)點(diǎn)的成本分?jǐn)偟饺康娜~子節(jié)點(diǎn)。不一定所有的葉子節(jié)點(diǎn)都是我們的成本節(jié)點(diǎn)，例如原子指標(biāo)和派生指標(biāo)，可能派生指標(biāo)的表是基于原子指標(biāo)表來(lái)進(jìn)行開(kāi)發(fā)的，但是原子指標(biāo)和派生指標(biāo)都會(huì)作為成本節(jié)點(diǎn)來(lái)進(jìn)行分?jǐn)偂?/span>

3. 全鏈路成本血緣洞察

這里我們碰到一些問(wèn)題，例如成本節(jié)點(diǎn)如何確定？目前采用的方式是，把所有的葉子節(jié)點(diǎn)判斷為成本節(jié)點(diǎn)，但在實(shí)際業(yè)務(wù)中會(huì)與此不太一致。所以我們也提供了一個(gè)方案，讓用戶(hù)自己來(lái)確定是否是成本節(jié)點(diǎn)，自行進(jìn)行補(bǔ)充和選擇。

第二個(gè)問(wèn)題就是成本逐層向下分?jǐn)倳r(shí)的權(quán)重問(wèn)題，目前我們采用的是向下游平均分?jǐn)偝杀镜姆绞?，各個(gè)子節(jié)點(diǎn)的權(quán)重是 n 分之一，但很多業(yè)務(wù)提出這樣做是有問(wèn)題的，理想的方式是按照下游的實(shí)際使用量，包含字段維度和記錄數(shù)的維度，字段維度就是下游使用了上游表的多少個(gè)字段，然后記錄數(shù)維度就是下游在它的 where 條件中用這個(gè)條件查出來(lái)了多少記錄數(shù)，目前還在研究與開(kāi)發(fā)中。

還有環(huán)路問(wèn)題，稍微有些復(fù)雜，我們考慮了幾種方案。首先把環(huán)路進(jìn)行拆解，從 c 到 a 就不會(huì)去分擔(dān)成本。第二個(gè)方案是是無(wú)限循環(huán)的分?jǐn)偡桨?，它?huì)讓環(huán)路進(jìn)行無(wú)限循環(huán)，最終它會(huì)在每一個(gè)節(jié)點(diǎn)上分?jǐn)偟綗o(wú)限循環(huán)之后的成本，其實(shí)可以通過(guò)無(wú)窮級(jí)數(shù)來(lái)事先預(yù)計(jì)算，不需要無(wú)限循環(huán)，只需要循環(huán)一次，乘以無(wú)窮級(jí)數(shù)的求和的結(jié)果就可以了。不過(guò)我們最終采用的是環(huán)路的整體判斷方案，把 a、b、c 作為環(huán)路的整體，然后再向 d 進(jìn)行分?jǐn)偂?/span>

第四個(gè)是圖計(jì)算的性能問(wèn)題，我們用 GraphX 進(jìn)行圖計(jì)算，迭代次數(shù)過(guò)多，會(huì)有數(shù)據(jù)傾斜的問(wèn)題，我們綜合采用了多種方案來(lái)進(jìn)行性能優(yōu)化。實(shí)際應(yīng)用可以使成本治理，從單點(diǎn)擴(kuò)展到全部鏈路，成本分?jǐn)偟倪壿?，更加符合?shù)據(jù)加工的邏輯。我們可以幫助業(yè)務(wù)直接觀察到自身的成本來(lái)源，幫助上游產(chǎn)品(數(shù)據(jù)中臺(tái))向下游分?jǐn)傋陨淼某杀?。另外我們?huì)針對(duì)單個(gè)節(jié)點(diǎn)，給出對(duì)應(yīng)的成本優(yōu)化建議。最終我們希望以血緣成本為基礎(chǔ)，進(jìn)行數(shù)倉(cāng)的全局優(yōu)化。

4. 基線項(xiàng)目

最后是基線項(xiàng)目，對(duì)整個(gè)任務(wù)鏈條進(jìn)行監(jiān)控和保障。具體實(shí)現(xiàn)過(guò)程為，A、B、C、D 是正常的數(shù)據(jù)鏈路，比如 D 是保障任務(wù)，某一天 B 任務(wù)延遲，導(dǎo)致其下游延遲。在基線項(xiàng)目中有一個(gè)水位線的概念，與 Flink 處理延遲消息的水位線比較類(lèi)似，因?yàn)?B 的延遲導(dǎo)致了 D 的水位線超過(guò)了預(yù)警線，在這種情況下，會(huì)在整個(gè)鏈條上進(jìn)行預(yù)警，這只是單個(gè)任務(wù)。比如 D 任務(wù)可能會(huì)有其他的路徑，它的每一條路徑都會(huì)推高 D 的水位線，如果超過(guò)預(yù)警線就會(huì)進(jìn)行監(jiān)控預(yù)警。

上圖是基線項(xiàng)目的整體結(jié)構(gòu)，可以實(shí)現(xiàn)全鏈路的可追蹤、可預(yù)警和可歸因，比較核心的服務(wù)，例如完成時(shí)間的預(yù)測(cè)、動(dòng)態(tài)最長(zhǎng)路徑的推送、歷史最長(zhǎng)路徑的計(jì)算，會(huì)以?xún)煞N形式推送給用戶(hù)，第一種是企業(yè)微信以文本形式來(lái)推送，第二種是通過(guò)一個(gè)平臺(tái)，以甘特圖的形式展示出全鏈路整體的延遲或者監(jiān)控情況。

以上就是本次分享的內(nèi)容，謝謝大家。

五、問(wèn)答環(huán)節(jié)

Q1：請(qǐng)問(wèn)從頭開(kāi)始血緣關(guān)系建設(shè)的話，是從任務(wù)到字段建設(shè)好，還是從字段到任務(wù)建設(shè)好？

A1：我們推薦從任務(wù)到字段，表血緣需要和任務(wù)血緣進(jìn)行對(duì)齊操作，字段血緣也需要和表血緣進(jìn)行對(duì)齊操作。表血緣的上下游有，它的字段血緣肯定是要有上下游關(guān)系的。還有一個(gè)情況，目前任務(wù)級(jí)血緣是最準(zhǔn)的，因?yàn)槿蝿?wù)血緣是用戶(hù)進(jìn)行線上的任務(wù)增刪改查的操作，下發(fā)的消息或者 MDB 數(shù)據(jù)，所以我們還是推薦從任務(wù)血緣向表血緣和字段血緣進(jìn)行向下建設(shè)。

Q2：怎么評(píng)估血緣的準(zhǔn)確性？

A2：我們有一個(gè)內(nèi)部監(jiān)控，這個(gè)監(jiān)控只能去監(jiān)控解析的成功率和一些比較固定的形式。我們目前采用的方法還是結(jié)合固定監(jiān)控和人工探查。比如字段血緣，其實(shí)目前的解析準(zhǔn)確率已經(jīng)很高了，能達(dá)到 99% 以上，但是 99% 這個(gè)數(shù)值，也是通過(guò)人工選取一些樣例數(shù)據(jù)，對(duì)比解析的結(jié)果和人工判斷的結(jié)果，得到的準(zhǔn)確率。

Q3：在讀寫(xiě)數(shù)據(jù)的時(shí)候用的 JDBC 或者自定義的 data source，怎么把這些血緣串聯(lián)起來(lái)？現(xiàn)在是否支持？

A3：我們目前能夠收集到的就是任務(wù)的配置，但是 JDBC 我們目前還沒(méi)有介入到這一塊，因?yàn)榭赡苌婕暗絡(luò)ar 包任務(wù)。剛才提到 jar 包任務(wù)，我們會(huì)進(jìn)行上下游表級(jí)血緣的全量依賴(lài)，并對(duì)字段級(jí)別進(jìn)行存量依賴(lài)。我們會(huì)分兩個(gè)概念，表級(jí)別的，我們可以通過(guò)配置來(lái)拿到，字段級(jí)別就會(huì)使用表級(jí)別的血緣進(jìn)行上下游的存量依賴(lài)。

Q4：基線項(xiàng)目的用戶(hù)都有哪些角色？

A4：基線項(xiàng)目目前主要面對(duì)的是 DE 和 DS，即數(shù)據(jù)工程師和數(shù)據(jù)分析師，保證任務(wù)和指標(biāo)能夠正常產(chǎn)出。他們會(huì)關(guān)注任務(wù)今天為什么會(huì)延遲，會(huì)逐層地往上找，我們通過(guò)基線項(xiàng)目及時(shí)給他發(fā)一個(gè)預(yù)警，告訴他鏈條中哪一個(gè)節(jié)點(diǎn)出了延遲或者出了問(wèn)題，方便快速地進(jìn)行定位。

Q5：支持 Spark dataframe 的字段血緣嗎？

A5：這個(gè)屬于 jar 包任務(wù)，目前處于全量依賴(lài)的階段，根據(jù)表血源去把字段血源制成全量依賴(lài)，避免字段級(jí)別的血緣突然在某一層斷掉。

Q6：主要用的數(shù)據(jù)結(jié)構(gòu)和算法？

A6：SQL 解析框架用到的數(shù)據(jù)結(jié)構(gòu)和算法會(huì)比較多，因?yàn)檫@個(gè)是純自研的 SQL 解析框架，并且它和普通的 SQL 解析框架還不太一樣，它不是直接去寫(xiě) SQL 的 Parser，而是基于 Calcite 和 Antlr 解析好的 AST 語(yǔ)法樹(shù)，進(jìn)行轉(zhuǎn)換操作，轉(zhuǎn)換到我們自研的語(yǔ)法結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)主要是遞歸和回溯，另外有比較細(xì)節(jié)的算法，處理某個(gè)問(wèn)題節(jié)點(diǎn)會(huì)應(yīng)用到特定的算法。

Q7：歐拉平臺(tái)考慮對(duì)外開(kāi)放嗎？還是只對(duì)內(nèi)？如果對(duì)外開(kāi)放依賴(lài)組件這么多，會(huì)不會(huì)有維護(hù)和運(yùn)維的成本？

A7：據(jù)我了解，是有對(duì)外開(kāi)放規(guī)劃的，而且目前已經(jīng)和多方進(jìn)行了合作。歐拉平臺(tái)有一些模塊集成在騰訊云上，有對(duì)外售賣(mài)。例如治理引擎，對(duì)事后的存量數(shù)據(jù)資產(chǎn)進(jìn)行問(wèn)題的掃描、發(fā)現(xiàn)、推進(jìn)、治理等等。這個(gè)模塊目前在騰訊云上是有對(duì)外開(kāi)放的。歐拉在內(nèi)部的平臺(tái)更加完善，功能也更多，有一些跟內(nèi)部的組件有深度的耦合和依賴(lài)。未來(lái)我們也會(huì)逐步考慮有哪些組件可以抽象出來(lái)，對(duì)外開(kāi)放。