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

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

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

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

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

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

以我的理解,數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖可分別看作是分而治之和無(wú)為而治。

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

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

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

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

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

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

易擴(kuò)展:使用存算分離架構(gòu),可解耦計(jì)算資源和存儲(chǔ)資源的擴(kuò)縮容;可擴(kuò)展支持多樣化的計(jì)算引擎,目前已支持Presto和Spark進(jìn)行計(jì)算分析。

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

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

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

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

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

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

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

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

元模型定義:是對(duì)元數(shù)據(jù)的抽象描述,定義了Hive元模型和通用元模型;

元數(shù)據(jù)采集:支持基于PULL定時(shí)拉取和PUSH主動(dòng)上報(bào)的兩種方式采集元數(shù)據(jù),并對(duì)原始元數(shù)據(jù)進(jìn)行加工處理;

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

元數(shù)據(jù)應(yīng)用:分為在線數(shù)據(jù)目錄和離線數(shù)據(jù)治理兩類功能模塊,在線數(shù)據(jù)目錄可為數(shù)據(jù)湖的計(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ù)庫(kù)來源,同時(shí)也支持半結(jié)構(gòu)化數(shù)據(jù),如Json文本、Log日志等;

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

在整個(gè)架構(gòu)圖中,由黑色箭頭的元數(shù)據(jù)流向可以看出,統(tǒng)一元數(shù)據(jù)是整個(gè)數(shù)據(jù)湖的基石和樞紐,發(fā)揮著承上啟下的關(guān)聯(lián)作用,承上對(duì)接數(shù)據(jù)湖計(jì)算引擎,啟下對(duì)接數(shù)據(jù)湖存儲(chǔ),可通過元數(shù)據(jù)采集從異構(gòu)數(shù)據(jù)源進(jìn)行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ù)沼澤,同時(shí)統(tǒng)一元數(shù)據(jù)可以整合不同的業(yè)務(wù)場(chǎng)景提供統(tǒng)一的數(shù)據(jù)管理視圖,打通各業(yè)務(wù)的數(shù)據(jù)孤島。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

04
功能模塊 – 在線目錄

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Apache Atlas:是基于Hadoop之上的元數(shù)據(jù)管理框架,主要以計(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)平臺(tái)。

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

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

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

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

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

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

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

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

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

本文經(jīng)授權(quán)發(fā)布,不代表增長(zhǎng)黑客立場(chǎng),如若轉(zhuǎn)載,請(qǐng)注明出處:http://gptmaths.com/quan/60699.html

(0)
打賞 微信掃一掃 微信掃一掃 支付寶掃一掃 支付寶掃一掃
上一篇 2022-03-14 13:46
下一篇 2022-03-14 13:59

增長(zhǎng)黑客Growthhk.cn薦讀更多>>

發(fā)表回復(fù)

登錄后才能評(píng)論