分享嘉賓：吳怡雯?騰訊 高級工程師

編輯整理：田長遠

出品平臺：DataFunTalk

導讀：大家好，今天分享的主題是騰訊數據湖的元數據治理實踐，跟大家一起聊聊騰訊云上DLC數據湖計算產品中統一元數據的設計思路和實踐經驗，希望能給大家帶來一些參考。

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

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

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

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

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

以騰訊數據湖計算DLC為例，數據湖的整體優勢可以分為：高效性、低成本、易擴展。

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

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

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

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

騰訊數據湖的整體架構如下圖所示，可以簡單理解為3+2架構，由數據湖的三大基本組成要素和兩大關聯模塊構成。

首先來看數據湖的三大基本組成要素：

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

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

統一元數據：提供云上統一的在線數據目錄和離線數據治理能力，主要有四個部分構成：

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

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

元數據存儲：根據不同元數據的數據結構和用途，選擇存放在不同類型的數據庫中，目前使用了關系型數據庫、索引數據庫、圖數據庫；

元數據應用：分為在線數據目錄和離線數據治理兩類功能模塊，在線數據目錄可為數據湖的計算引擎提供Schema管理功能，而離線數據治理可為數據湖提供資產管理能力。

兩大關聯模塊包括：

異構數據源：為數據湖提供生產資料來源，支持結構化數據，如騰訊云上EMR HIve，CDB、CDW等數據庫來源，同時也支持半結構化數據，如Json文本、Log日志等；

入湖構建：為數據湖提供便捷的數據入湖集成能力，基于Iceberg表格式和Flink，可實現全量和增量的數據導入集成功能。

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

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

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

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

系統服務架構如右圖所示，基于分層微服務、k8s容器化、CICD持續集成和部署實現云原生的服務架構，統一元數據的服務分為三層：

基礎服務：與數據庫存儲對接，提供基礎的元數據管理能力，包括核心服務、數據源服務、血緣服務、調度服務；

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

業務服務：提供HTTP接口與具體的業務產品交互，根據每個業務的獨特性，可分別提供不同的業務服務。

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

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

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

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

業務租戶與元數據租戶的映射關系，可以分為兩類的劃分：

縱向劃分：可用于公有云場景，從縱向對元數據租戶進行合并劃分，一個業務租戶對應一個云上產品，每個產品之間元數據是邏輯隔離的，而從騰訊云賬號這個更高維度，又可對多個業務產品進行孤島元數據的打通；

橫向劃分：可用于私有云場景，從橫向對元數據租戶進行共享及拆分，一個業務租戶對應一個公司部門，所有部門都共享一個私有化集群和元數據租戶，部門之間通過DB維度進行隔離，則中間表維護部門、元數據租戶和DB名稱的關系。

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

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

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

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

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

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

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

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

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

簡化后的數據模型，可以減少大量的數據庫關聯查詢，而全新的實現邏輯，從根源上減少了冗余API的調用并進行執行邏輯優化；持久層框架由更靈活的Mybatis替代JDO，支持基于數據庫的讀寫分離。該圖展示了100次接口重復調用下，庫、表、分區的各接口的耗時對比，可以看出重構后Metastore的耗時遠低于原生Hive Metastore耗時。

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

查詢優化器是SQL引擎的重點核心能力，常見的優化器有基于規則的RBO優化器和基于代價的CBO優化器，其中CBO優化器可通過感知數據來調整執行計劃，在大數據領域更受歡迎。CBO的要素由統計信息和代價模型構成，為加速計算優化，統一元數據提供多引擎通用的統計元數據功能，支持表、分區、字段級別的統計元數據，具體各級別的統計信息如下表所示。

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

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

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

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

Lyft Amundsen：最近比較熱門的元數據管理系統之一，由lyft開源的數據發現平臺。

基于業界方案調研，可以總結出以下規律：

開源的數據治理產品也在不斷迭代更新：從單體服務到分層服務，到以消息驅動為主，很多主流的元數據管理系統，會采用消息中間件來解耦數據采集和數據加工，使得系統更具通用性。新增的異構數據源，僅需按照規定的消息格式發送元數據到消息中間件，元數據就可以被系統進行加工處理；

完整的數據治理系統可以分為四個基本模塊：元模型定義、元數據采集、元數據加工及存儲、元數據應用；

數據治理服務常用的基礎組件有：關系型數據庫，用于元數據存儲；索引數據庫，用于數據檢索的；圖數據庫，用于關聯數據存儲，如數據血緣或者元數據實體；消息中間件，用于解耦元數據操作；調度引擎，用于執行采集任務。

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

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

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