吳怡雯：騰訊數(shù)據(jù)湖元數(shù)據(jù)治理實踐｜?DataFunTalk

導(dǎo)讀：大家好，今天分享的主題是騰訊數(shù)據(jù)湖的元數(shù)據(jù)治理實踐，跟大家一起聊聊騰訊云上DLC數(shù)據(jù)湖計算產(chǎn)品中統(tǒng)一元數(shù)據(jù)的設(shè)計思路和實踐經(jīng)驗，希望能給大家?guī)硪恍﹨⒖肌?/p>

本文的內(nèi)容主要包括四部分：首先是對什么是數(shù)據(jù)湖進行背景概述，介紹騰訊數(shù)據(jù)湖的整體架構(gòu)，以及統(tǒng)一元數(shù)據(jù)模塊的詳細架構(gòu)實現(xiàn)；第二部分介紹騰訊云上元數(shù)據(jù)多租戶的設(shè)計模式，最后介紹統(tǒng)一元數(shù)據(jù)的兩大核心能力：在線數(shù)據(jù)目錄和離線數(shù)據(jù)治理的功能。

01
什么是數(shù)據(jù)湖

隨著Snowflake公司股價高歌猛進和各大云廠商的推廣，數(shù)據(jù)湖已成為近2、3年來大數(shù)據(jù)領(lǐng)域的新貴之一，而什么是數(shù)據(jù)湖，數(shù)據(jù)湖與數(shù)據(jù)倉庫之間的競爭和融合，各家云廠商和數(shù)據(jù)平臺都有自己的解讀。從定義來看，數(shù)據(jù)倉庫是1990年由數(shù)倉之父Bill Inmon提出，是面向主題的、集成的、相對穩(wěn)定的、反映歷史的數(shù)據(jù)集合，為上層提供管理決策；而數(shù)據(jù)湖概念最早是2010年由Pentaho CTO James Dixon提出，是存儲各類自然格式數(shù)據(jù)的系統(tǒng)，提供數(shù)據(jù)ETL操作。

以我的理解，數(shù)據(jù)倉庫和數(shù)據(jù)湖可分別看作是分而治之和無為而治。

數(shù)據(jù)倉庫：具有標準的數(shù)據(jù)模型和數(shù)據(jù)分層，包括ODS操作數(shù)據(jù)層，CDM通用數(shù)據(jù)模型層，ADS數(shù)據(jù)應(yīng)用層，而每層又可以進行細分；數(shù)據(jù)倉庫僅支持結(jié)構(gòu)化數(shù)據(jù)，在寫入數(shù)據(jù)文件時，必須提前定義好數(shù)據(jù)的Schema結(jié)構(gòu)；數(shù)據(jù)倉庫的整體數(shù)據(jù)質(zhì)量較高，但隨之而來的構(gòu)建成本較大且僅支持特定計算引擎。

數(shù)據(jù)湖：無需提前設(shè)計好數(shù)據(jù)模型和數(shù)據(jù)分層，支持結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，在數(shù)據(jù)讀取操作時，才需要確定出數(shù)據(jù)的Schema結(jié)構(gòu)；相比于數(shù)據(jù)倉庫，數(shù)據(jù)湖的整體數(shù)據(jù)質(zhì)量較低，但其構(gòu)建成本較小，且支持多樣化的計算引擎進行數(shù)據(jù)分析。

以騰訊數(shù)據(jù)湖計算DLC為例，數(shù)據(jù)湖的整體優(yōu)勢可以分為：高效性、低成本、易擴展。

高時效：可基于表格式，使用Iceberg提供行級數(shù)據(jù)操作，可將傳統(tǒng)的大數(shù)據(jù)數(shù)倉時延從小時級別降低到分鐘級別；可基于存儲緩存，使用Alluxio提供本地的分層存儲，加速計算。

低成本：相比于傳統(tǒng)的HDFS，騰訊云上對象存儲COS的計費更加低廉，用戶只需為實際存儲的數(shù)據(jù)買單，天然適合云原生場景。提供數(shù)據(jù)湖Serverless計算能力，可基于云上EKS對計算資源進行動態(tài)擴縮容，讓用戶無需購買整套EMR集群就能實現(xiàn)海量的數(shù)據(jù)分析。

易擴展：使用存算分離架構(gòu)，可解耦計算資源和存儲資源的擴縮容；可擴展支持多樣化的計算引擎，目前已支持Presto和Spark進行計算分析。

數(shù)據(jù)湖在靈活性的優(yōu)勢下，也需要更好的管理能力，包括數(shù)據(jù)建模能力和數(shù)據(jù)治理能力，而各廠商也紛紛提出湖倉一體的概念，將數(shù)據(jù)湖和數(shù)據(jù)倉庫進行整合，更好的根據(jù)實際需求尋找兩者的平衡。

02
騰訊數(shù)據(jù)湖和騰訊統(tǒng)一元數(shù)據(jù)治理框架

騰訊數(shù)據(jù)湖的整體架構(gòu)如下圖所示，可以簡單理解為3+2架構(gòu)，由數(shù)據(jù)湖的三大基本組成要素和兩大關(guān)聯(lián)模塊構(gòu)成。

首先來看數(shù)據(jù)湖的三大基本組成要素：

數(shù)據(jù)湖存儲：提供海量異構(gòu)數(shù)據(jù)的存儲能力，具備低成本、高可用、可彈性伸縮。DLC基于騰訊云對象存儲COS作為主要數(shù)據(jù)湖存儲，搭配Alluxio進行數(shù)據(jù)編排和分層緩存，同時也支持云上EMR HDFS擴展存儲；

數(shù)據(jù)湖計算：以Serverless無服務(wù)的形式提供高效敏捷的計算分析。DLC支持基于Presto實現(xiàn)即席分析，基于Spark實現(xiàn)數(shù)據(jù)ETL批處理、基于騰訊SuperSQL實現(xiàn)聯(lián)邦跨源分析；

統(tǒng)一元數(shù)據(jù)：提供云上統(tǒng)一的在線數(shù)據(jù)目錄和離線數(shù)據(jù)治理能力，主要有四個部分構(gòu)成：

元模型定義：是對元數(shù)據(jù)的抽象描述，定義了Hive元模型和通用元模型；

元數(shù)據(jù)采集：支持基于PULL定時拉取和PUSH主動上報的兩種方式采集元數(shù)據(jù)，并對原始元數(shù)據(jù)進行加工處理；

元數(shù)據(jù)存儲：根據(jù)不同元數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)和用途，選擇存放在不同類型的數(shù)據(jù)庫中，目前使用了關(guān)系型數(shù)據(jù)庫、索引數(shù)據(jù)庫、圖數(shù)據(jù)庫；

元數(shù)據(jù)應(yīng)用：分為在線數(shù)據(jù)目錄和離線數(shù)據(jù)治理兩類功能模塊，在線數(shù)據(jù)目錄可為數(shù)據(jù)湖的計算引擎提供Schema管理功能，而離線數(shù)據(jù)治理可為數(shù)據(jù)湖提供資產(chǎn)管理能力。

兩大關(guān)聯(lián)模塊包括：

異構(gòu)數(shù)據(jù)源：為數(shù)據(jù)湖提供生產(chǎn)資料來源，支持結(jié)構(gòu)化數(shù)據(jù)，如騰訊云上EMR HIve，CDB、CDW等數(shù)據(jù)庫來源，同時也支持半結(jié)構(gòu)化數(shù)據(jù)，如Json文本、Log日志等；

入湖構(gòu)建：為數(shù)據(jù)湖提供便捷的數(shù)據(jù)入湖集成能力，基于Iceberg表格式和Flink，可實現(xiàn)全量和增量的數(shù)據(jù)導(dǎo)入集成功能。

在整個架構(gòu)圖中，由黑色箭頭的元數(shù)據(jù)流向可以看出，統(tǒng)一元數(shù)據(jù)是整個數(shù)據(jù)湖的基石和樞紐，發(fā)揮著承上啟下的關(guān)聯(lián)作用，承上對接數(shù)據(jù)湖計算引擎，啟下對接數(shù)據(jù)湖存儲，可通過元數(shù)據(jù)采集從異構(gòu)數(shù)據(jù)源進行Schema數(shù)據(jù)結(jié)構(gòu)爬取，而數(shù)據(jù)的Schema信息又可以為入湖構(gòu)建提供基本的元數(shù)據(jù)資料。元數(shù)據(jù)中的Schema管理和數(shù)據(jù)治理，提升和保證了數(shù)據(jù)湖的數(shù)據(jù)質(zhì)量，避免陷入數(shù)據(jù)沼澤，同時統(tǒng)一元數(shù)據(jù)可以整合不同的業(yè)務(wù)場景提供統(tǒng)一的數(shù)據(jù)管理視圖，打通各業(yè)務(wù)的數(shù)據(jù)孤島。

下面來看騰訊統(tǒng)一元數(shù)據(jù)的模塊詳細架構(gòu)，其中系統(tǒng)邏輯架構(gòu)如圖所示，有兩大核心功能：在線數(shù)據(jù)目錄和離線數(shù)據(jù)治理。

在線目錄：提供元數(shù)據(jù)Schema管理能力，可類比Hive Metastore或AWS Glue 組件，對接計算引擎提供元數(shù)據(jù)信息。根據(jù)具體的使用場景和服務(wù)定位，我們放棄了更具靈活性但又更復(fù)雜的元元模型管理，定義了兩類：Hive數(shù)據(jù)模型和通用數(shù)據(jù)模型。Hive數(shù)據(jù)模型參考原生Hive的數(shù)據(jù)結(jié)構(gòu)設(shè)計，通過定義DB、表、UDF Function、字段、分區(qū)、存儲描述，使得在線目錄功能盡可能與SQL-on-Hadoop的計算引擎無縫對接；而通用模型通過定義DB、表、字段，可適配基本的數(shù)據(jù)治理能力。

離線治理：提供豐富的元數(shù)據(jù)管理應(yīng)用，包括數(shù)據(jù)地圖、數(shù)據(jù)字典、數(shù)據(jù)檢索、表/字段級別血緣、類目管理、標簽管理、生命周期管理等功能。除在線和離線核心功能外，多租戶管理實現(xiàn)混合云場景的通用租戶設(shè)計，使得統(tǒng)一元數(shù)據(jù)可適配不同場景。

系統(tǒng)服務(wù)架構(gòu)如右圖所示，基于分層微服務(wù)、k8s容器化、CICD持續(xù)集成和部署實現(xiàn)云原生的服務(wù)架構(gòu)，統(tǒng)一元數(shù)據(jù)的服務(wù)分為三層：

基礎(chǔ)服務(wù)：與數(shù)據(jù)庫存儲對接，提供基礎(chǔ)的元數(shù)據(jù)管理能力，包括核心服務(wù)、數(shù)據(jù)源服務(wù)、血緣服務(wù)、調(diào)度服務(wù)；

組件服務(wù)：以服務(wù)進程的形式提供組件化功能，僅調(diào)用基礎(chǔ)服務(wù)提供的接口，不與數(shù)據(jù)庫直接對接，包括引擎直連組件、數(shù)據(jù)目錄組件、消息處理組件；

業(yè)務(wù)服務(wù)：提供HTTP接口與具體的業(yè)務(wù)產(chǎn)品交互，根據(jù)每個業(yè)務(wù)的獨特性，可分別提供不同的業(yè)務(wù)服務(wù)。

這樣的分層設(shè)計，保證基礎(chǔ)服務(wù)和組件服務(wù)的通用性，盡可能與個性化業(yè)務(wù)場景解耦。同時在團隊開發(fā)實踐中，也便于不同團隊協(xié)作，業(yè)務(wù)團隊可快速的參與到具體的業(yè)務(wù)開發(fā)中。

03
租戶設(shè)計：介紹騰訊云上的元數(shù)據(jù)租戶

元數(shù)據(jù)中多層級的租戶設(shè)計是整個系統(tǒng)的基本框架與靈魂，所有的實現(xiàn)邏輯都會以此為基礎(chǔ)進行疊加。雖然這個領(lǐng)域模型看起來比較樸素和簡單，但在設(shè)計之初，我們團隊內(nèi)部討論了蠻久才最終確定的。抽象出元數(shù)據(jù)租戶和業(yè)務(wù)租戶兩個層級維度的租戶級別，來架構(gòu)元數(shù)據(jù)的基本能力和滿足不同的業(yè)務(wù)需求，如聯(lián)邦多Catalog管理，多業(yè)務(wù)的元數(shù)據(jù)打通。

元數(shù)據(jù)租戶是系統(tǒng)中的最小租戶粒度，可涵蓋完備的元數(shù)據(jù)Schema信息，不同元數(shù)據(jù)租戶是相互獨立隔離的。一個元數(shù)據(jù)租戶可類比為一個Hive Metastore，元數(shù)據(jù)租戶與數(shù)據(jù)庫DB是一對多的關(guān)系。一個騰訊云賬號下對應(yīng)多個元數(shù)據(jù)租戶，可以適配多Catalog管理場景。為便于計算引擎和外部服務(wù)的接口調(diào)用，同個騰訊云賬號下，可定義不重名的元數(shù)據(jù)命名空間作為別名來使用，與元數(shù)據(jù)租戶一一對應(yīng)。元數(shù)據(jù)租戶是抽象邏輯概念，可支持不同的元數(shù)據(jù)類型，如Hive、MySQL等。

業(yè)務(wù)租戶的設(shè)計初衷是為了解耦通用元數(shù)據(jù)與具體業(yè)務(wù)的強關(guān)聯(lián)關(guān)系，使得底層元數(shù)據(jù)租戶與具體的業(yè)務(wù)是無關(guān)的，由業(yè)務(wù)租戶承擔具體業(yè)務(wù)場景的關(guān)聯(lián)與維護。數(shù)據(jù)源一般由業(yè)務(wù)使用方提供的，因此設(shè)計為與業(yè)務(wù)租戶相關(guān)，一個業(yè)務(wù)租戶可對應(yīng)多個數(shù)據(jù)源。需要特別關(guān)注的是：元數(shù)據(jù)租戶與業(yè)務(wù)租戶本身沒有直接且明確的關(guān)聯(lián)關(guān)系，它們的關(guān)系由中間映射表維護，該映射關(guān)系是靈活的，由具體的業(yè)務(wù)邏輯決定的，不同業(yè)務(wù)場景使用的中間映射表不同，新增一種新業(yè)務(wù)類型，僅需擴展中間映射關(guān)系表。

業(yè)務(wù)租戶與元數(shù)據(jù)租戶的映射關(guān)系，可以分為兩類的劃分：

縱向劃分：可用于公有云場景，從縱向?qū)υ獢?shù)據(jù)租戶進行合并劃分，一個業(yè)務(wù)租戶對應(yīng)一個云上產(chǎn)品，每個產(chǎn)品之間元數(shù)據(jù)是邏輯隔離的，而從騰訊云賬號這個更高維度，又可對多個業(yè)務(wù)產(chǎn)品進行孤島元數(shù)據(jù)的打通；

橫向劃分：可用于私有云場景，從橫向?qū)υ獢?shù)據(jù)租戶進行共享及拆分，一個業(yè)務(wù)租戶對應(yīng)一個公司部門，所有部門都共享一個私有化集群和元數(shù)據(jù)租戶，部門之間通過DB維度進行隔離，則中間表維護部門、元數(shù)據(jù)租戶和DB名稱的關(guān)系。

04
功能模塊 – 在線目錄

下面我們進入統(tǒng)一元數(shù)據(jù)的第一個核心功能模塊：在線數(shù)據(jù)目錄。在業(yè)界方案中，Hive Metastore是Hadoop生態(tài)圈中數(shù)據(jù)目錄管理的事實標準，為SQL on Hadoop的分析計算引擎提供通用的Schema管理能力。在DLC數(shù)據(jù)湖計算場景中，為保證計算引擎與統(tǒng)一元數(shù)據(jù)能夠最小成本的無縫對接，我們首先考慮的是如何進行Hive Metastore的改造實現(xiàn)，提供保持一致的Metastore RPC接口，讓計算引擎對底層元數(shù)據(jù)的服務(wù)形態(tài)零感知。

首先來大致回顧Hive執(zhí)行的流程：由Driver觸發(fā)SQL解析，Compiler編譯器進行編譯解析獲取邏輯計劃對象，會基于Hive Metastore RPC接口獲取Schema元數(shù)據(jù)信息，用于校驗和豐富邏輯計劃對象。邏輯計劃轉(zhuǎn)換為可執(zhí)行的物理計劃，由Execution Engine執(zhí)行引擎觸發(fā)執(zhí)行，其中若涉及元數(shù)據(jù)變更操作，會調(diào)用Hive Metastore RPC接口進行元數(shù)據(jù)變更，并最終將元數(shù)據(jù)信息持久化到RDBMS。Hive Metastore是典型的單租戶設(shè)計，不同用戶之間Schema無法完全隔離，無支持創(chuàng)建重名數(shù)據(jù)庫。Hive Metastore的內(nèi)部設(shè)計要點是基于HMSHandler類完全實現(xiàn)IHMSHandler類定義的RPC接口，HMSHandler基于RawStore類從配置中加載持久層的數(shù)據(jù)庫連接信息并初始化，最終數(shù)據(jù)元數(shù)據(jù)讀寫操作由RawStore基于JDO框架實現(xiàn)。

為擴展和支持Hive Metastore實現(xiàn)多租戶的能力，業(yè)界有不同的實現(xiàn)方案，主要分為兩類。

方案一：以騰訊多租戶OMS的實現(xiàn)為例，通過侵入修改Hive Metatsore的源碼，在HMSHandler連接RawStore之間新增路由管理器，從RPC連接的Session配置獲取連接標識，根據(jù)標識，從映射DB中獲取具體的JDBC連接信息并初始化，最終由對應(yīng)的MultiStore完成元數(shù)據(jù)讀寫操作，多租戶實現(xiàn)可理解為多個連接存儲MultiStore。

方案二：以Expedia公司的WD(Waggle Dance)實現(xiàn)為例，在Hive Metastore之外增加路由管理服務(wù)，用戶調(diào)用路由服務(wù)提供的RPC接口，通過配置從映射DB中，將RPC請求路由轉(zhuǎn)發(fā)到真正的Hive Metastore上，多租戶實現(xiàn)可理解為多個Hive Metastore。雖然方案二對原生Hive Metastore侵入性較小，但也增多了一層請求鏈路。

以上兩種方案都不適用于公有云數(shù)據(jù)湖場景。首先，兩種多租戶方案底層都是通過綁定獨立的數(shù)據(jù)庫連接實現(xiàn)，一個租戶即為一個獨立的數(shù)據(jù)庫連接，需要進行大量的數(shù)據(jù)庫連接管理；其次，公有云場景會存在很多長尾試用用戶，大量的非活躍用戶會造成數(shù)據(jù)庫資源的浪費；最后，兩種方案都與Hive Metastore的數(shù)據(jù)模型和實現(xiàn)邏輯強綁定，對于實現(xiàn)數(shù)據(jù)治理功能，存在很硬性的限制條件。

我們最終選擇的實現(xiàn)方案是重新實現(xiàn)Hive Metastore RPC接口，大致的實現(xiàn)流程如圖所示：新增自定義Handler類繼承IHMSHandler，完全重新實現(xiàn)Thrift文件RPC接口。內(nèi)部增加RPC認證鑒權(quán)操作，并最終對外提供RPC Server服務(wù)。自定義Handler主要負責處理Metastore邏輯和數(shù)據(jù)轉(zhuǎn)換操作，真正的元數(shù)據(jù)持久化通過服務(wù)間RPC調(diào)用最終由元數(shù)據(jù)基礎(chǔ)服務(wù)完成。在線目錄除提供完全兼容Hive Metastore的RPC接口外，還提供了HTTP接口供不同的產(chǎn)品使用。該實現(xiàn)方案雖然具有很強的靈活性，但整體實現(xiàn)和維護成本偏高，并不適合所有場景。

目前自研的元數(shù)據(jù)Metastore構(gòu)建在Hive 2.3.7版本之上，RPC文件定義的接口總數(shù)有167個，已實現(xiàn)接口數(shù)79個，主要包括六類：數(shù)據(jù)庫、數(shù)據(jù)表、分區(qū)、自定義UDF、統(tǒng)計元數(shù)據(jù)、事務(wù)鎖，已具備無縫對接多引擎的能力。我們已上線并適配使用的引擎有PrestoDB、Spark、Flink、Iceberg、Alluxio。每個引擎所使用到的接口范圍如上表所示，藍色橫線代表該引擎不會調(diào)用這類RPC接口。

因為選擇使用完全重寫的方案，我們可以基于Metastore進行深度優(yōu)化。對于數(shù)據(jù)模型，我們在Hive Metastore的原生模型之上進行二次抽象和簡化，核心模型由12個減少到6個，主要的改造包括：① 去除PARAMS表：將KV的配置參數(shù)關(guān)聯(lián)表以Json字符串的形式作為數(shù)據(jù)模型的一個字段；② 統(tǒng)一模型：將分區(qū)字段與非分區(qū)字段統(tǒng)一成一個數(shù)據(jù)模型；③ 簡化SDS：簡化存儲描述SDS相關(guān)聯(lián)的數(shù)據(jù)模型；④ 租戶維護：DB和Table之上增加了元數(shù)據(jù)租戶的字段維護。

簡化后的數(shù)據(jù)模型，可以減少大量的數(shù)據(jù)庫關(guān)聯(lián)查詢，而全新的實現(xiàn)邏輯，從根源上減少了冗余API的調(diào)用并進行執(zhí)行邏輯優(yōu)化；持久層框架由更靈活的Mybatis替代JDO，支持基于數(shù)據(jù)庫的讀寫分離。該圖展示了100次接口重復(fù)調(diào)用下，庫、表、分區(qū)的各接口的耗時對比，可以看出重構(gòu)后Metastore的耗時遠低于原生Hive Metastore耗時。

對于在線數(shù)據(jù)目錄，除了提供Schema管理外，還提供了通用的統(tǒng)計元數(shù)據(jù)，為CBO優(yōu)化器助力。首先簡要回顧下SQL的解析執(zhí)行流程，SQL語句經(jīng)過詞法/語法和語義解析后，獲得樸素的邏輯算子樹，經(jīng)過查詢優(yōu)化器的代數(shù)邏輯優(yōu)化，獲取其中最短執(zhí)行路徑的邏輯算子樹，最后邏輯算子樹轉(zhuǎn)換為物理算子樹并提交執(zhí)行引擎。

查詢優(yōu)化器是SQL引擎的重點核心能力，常見的優(yōu)化器有基于規(guī)則的RBO優(yōu)化器和基于代價的CBO優(yōu)化器，其中CBO優(yōu)化器可通過感知數(shù)據(jù)來調(diào)整執(zhí)行計劃，在大數(shù)據(jù)領(lǐng)域更受歡迎。CBO的要素由統(tǒng)計信息和代價模型構(gòu)成，為加速計算優(yōu)化，統(tǒng)一元數(shù)據(jù)提供多引擎通用的統(tǒng)計元數(shù)據(jù)功能，支持表、分區(qū)、字段級別的統(tǒng)計元數(shù)據(jù)，具體各級別的統(tǒng)計信息如下表所示。

多引擎通用統(tǒng)計元數(shù)據(jù)的實現(xiàn)流程大致如下：Hive、Spark、Presto支持ANALYZE語句，通過執(zhí)行ANALYZE分布式任務(wù)，計算出統(tǒng)計元數(shù)據(jù)，計算引擎調(diào)用元數(shù)據(jù)Metastore接口持久化統(tǒng)計元數(shù)據(jù)。但存在的一個問題：不同的計算引擎使用的統(tǒng)計元數(shù)據(jù)讀寫接口可能不同。元數(shù)據(jù)Metastore作為中轉(zhuǎn)層，會根據(jù)計算引擎類型進行轉(zhuǎn)換處理，使得統(tǒng)計元數(shù)據(jù)對于不同引擎都是通用性。如Presto計算出的統(tǒng)計元數(shù)據(jù)，在Spark執(zhí)行SQL，可直接獲取對應(yīng)統(tǒng)計信息進行CBO優(yōu)化，而無需再次ANALYZE計算。

05
功能模塊 – 數(shù)據(jù)治理

最后進入統(tǒng)一元數(shù)據(jù)的第二個核心功能模塊：離線數(shù)據(jù)治理。針對元數(shù)據(jù)治理，各類開源方案在業(yè)界層出不窮，這里列舉了幾個業(yè)內(nèi)比較流行的元數(shù)據(jù)管理組件：

Apache Atlas：是基于Hadoop之上的元數(shù)據(jù)管理框架，主要以計算引擎Hook的方式，來獲取元數(shù)據(jù)信息，并提供基本的元數(shù)據(jù)應(yīng)用管理；

LinkedIn DataHub：是LinkedIn Warehows的前身，提供元數(shù)據(jù)搜索及集成功能；

Lyft Amundsen：最近比較熱門的元數(shù)據(jù)管理系統(tǒng)之一，由lyft開源的數(shù)據(jù)發(fā)現(xiàn)平臺。

基于業(yè)界方案調(diào)研，可以總結(jié)出以下規(guī)律：

開源的數(shù)據(jù)治理產(chǎn)品也在不斷迭代更新：從單體服務(wù)到分層服務(wù)，到以消息驅(qū)動為主，很多主流的元數(shù)據(jù)管理系統(tǒng)，會采用消息中間件來解耦數(shù)據(jù)采集和數(shù)據(jù)加工，使得系統(tǒng)更具通用性。新增的異構(gòu)數(shù)據(jù)源，僅需按照規(guī)定的消息格式發(fā)送元數(shù)據(jù)到消息中間件，元數(shù)據(jù)就可以被系統(tǒng)進行加工處理；

完整的數(shù)據(jù)治理系統(tǒng)可以分為四個基本模塊：元模型定義、元數(shù)據(jù)采集、元數(shù)據(jù)加工及存儲、元數(shù)據(jù)應(yīng)用；

數(shù)據(jù)治理服務(wù)常用的基礎(chǔ)組件有：關(guān)系型數(shù)據(jù)庫，用于元數(shù)據(jù)存儲；索引數(shù)據(jù)庫，用于數(shù)據(jù)檢索的；圖數(shù)據(jù)庫，用于關(guān)聯(lián)數(shù)據(jù)存儲，如數(shù)據(jù)血緣或者元數(shù)據(jù)實體；消息中間件，用于解耦元數(shù)據(jù)操作；調(diào)度引擎，用于執(zhí)行采集任務(wù)。

以Atlas為例，元模型定義在Core模塊Type System中實現(xiàn)；元數(shù)據(jù)采集在Integration集成模塊接收元數(shù)據(jù)Hook消息并生產(chǎn)到消息中間件；元數(shù)據(jù)加工及存儲在Core模塊處理，基于Graph Engine持久化；元數(shù)據(jù)應(yīng)用在Apps模塊中使用；使用Kafka作為消息中間件，使用ES索引數(shù)據(jù)庫進行數(shù)據(jù)檢索；使用JanusGraph圖數(shù)據(jù)庫進行元數(shù)據(jù)實體存儲，而血緣消息也作為其中一類元數(shù)據(jù)實體。

下表展示了各個開源系統(tǒng)與騰訊元數(shù)據(jù)治理功能的對比，其中騰訊元數(shù)據(jù)的項目代號為Hybris，可以看出騰訊統(tǒng)一元數(shù)據(jù)已具備豐富的數(shù)據(jù)治理能力。除功能的完整性對比外，按照我們的以往經(jīng)驗，開源的數(shù)據(jù)治理系統(tǒng)在實際業(yè)務(wù)中很難直接的使用起來，因為數(shù)據(jù)治理是與業(yè)務(wù)領(lǐng)域和形態(tài)密切相關(guān)，直接使用具有一定抽象性且通用的開源系統(tǒng)，只能獲取比較基礎(chǔ)的數(shù)據(jù)治理能力，很難得到業(yè)務(wù)相關(guān)的數(shù)據(jù)價值。若與業(yè)務(wù)結(jié)合，則需要對開源系統(tǒng)進行深度改造的二次開發(fā)，因此在數(shù)據(jù)治理部分我們也選擇完全自研。

數(shù)據(jù)治理的整體架構(gòu)：在公有云場景，由調(diào)度引擎觸發(fā)離線采集調(diào)度任務(wù)，通過PULL定時拉取的爬蟲方式采集異構(gòu)數(shù)據(jù)源的元數(shù)據(jù)信息，并將元數(shù)據(jù)發(fā)送到消息中間件；元數(shù)據(jù)Core中的元數(shù)據(jù)管理和血緣管理通過消息消費獲取對應(yīng)的元數(shù)據(jù)進行加工處理，并將元數(shù)據(jù)持久化到數(shù)據(jù)庫。除離線采集外，也提供了直接數(shù)據(jù)源引擎獲取實時元數(shù)據(jù)和進行庫表管理的操作。最終由元數(shù)據(jù)應(yīng)用功能提供多樣化的治理功能。

今天的分享就到這里，謝謝大家。