簡介： 作者：沐遠(yuǎn)、明惠

背景

數(shù)據(jù)湖當(dāng)前在國內(nèi)外是比較熱的方案，MarketsandMarkets市場調(diào)研顯示預(yù)計數(shù)據(jù)湖市場規(guī)模在2024年會從2019年的79億美金增長到201億美金。一些企業(yè)已經(jīng)構(gòu)建了自己的云原生數(shù)據(jù)湖方案，有效解決了業(yè)務(wù)痛點；還有很多企業(yè)在構(gòu)建或者計劃構(gòu)建自己的數(shù)據(jù)湖，Gartner 2020年發(fā)布的報告顯示目前已經(jīng)有39%的用戶在使用數(shù)據(jù)湖，34%的用戶考慮在1年內(nèi)使用數(shù)據(jù)湖。隨著對象存儲等云原生存儲技術(shù)的成熟，一開始大家會先把結(jié)構(gòu)化、半結(jié)構(gòu)化、圖片、視頻等數(shù)據(jù)存儲在對象存儲中。當(dāng)需要對這些數(shù)據(jù)進(jìn)行分析時，發(fā)現(xiàn)缺少面向分析的數(shù)據(jù)管理視圖，在這樣的背景下業(yè)界在面向云原生數(shù)據(jù)湖的元數(shù)據(jù)管理技術(shù)進(jìn)行了廣泛的探索和落地。

一、元數(shù)據(jù)管理面臨的挑戰(zhàn)

1、什么是數(shù)據(jù)湖

Wikipedia上說數(shù)據(jù)湖是一類存儲數(shù)據(jù)自然/原始格式的系統(tǒng)或存儲，通常是對象塊或者文件，包括原始系統(tǒng)所產(chǎn)生的原始數(shù)據(jù)拷貝以及為了各類任務(wù)而產(chǎn)生的轉(zhuǎn)換數(shù)據(jù)，包括來自于關(guān)系型數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)（行和列）、半結(jié)構(gòu)化數(shù)據(jù)（如CSV、日志、XML、JSON）、非結(jié)構(gòu)化數(shù)據(jù)（如email、文檔、PDF、圖像、音頻、視頻）。

從上面可以總結(jié)出數(shù)據(jù)湖具有以下特性：

• 數(shù)據(jù)來源：原始數(shù)據(jù)、轉(zhuǎn)換數(shù)據(jù)
• 數(shù)據(jù)類型：結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)、二進(jìn)制
• 數(shù)據(jù)湖存儲：可擴(kuò)展的海量數(shù)據(jù)存儲服務(wù)

2、數(shù)據(jù)湖分析方案架構(gòu)

當(dāng)數(shù)據(jù)湖只是作為存儲的時候架構(gòu)架構(gòu)比較清晰，在基于數(shù)據(jù)湖存儲構(gòu)建分析平臺過程中，業(yè)界進(jìn)行了大量的實踐，基本的架構(gòu)如下：

?

主要包括五個模塊：

• 數(shù)據(jù)源：原始數(shù)據(jù)存儲模塊，包括結(jié)構(gòu)化數(shù)據(jù)(Database等)、半結(jié)構(gòu)化(File、日志等)、非結(jié)構(gòu)化(音視頻等)
• 數(shù)據(jù)集成：為了將數(shù)據(jù)統(tǒng)一到數(shù)據(jù)湖存儲及管理，目前數(shù)據(jù)集成主要分為三種形態(tài)。第一種為直接通過外表的方式關(guān)聯(lián)元數(shù)據(jù)；第二種為基于ETL、集成工具、流式寫入模式，這種方式直接處理數(shù)據(jù)能夠感知Schema，在寫入數(shù)據(jù)的過程中同時創(chuàng)建元數(shù)據(jù)；第三種為文件直接上傳數(shù)據(jù)湖存儲，需要事后異步構(gòu)建元數(shù)據(jù)
• 數(shù)據(jù)湖存儲：目前業(yè)界主要使用對象存儲以及自建HDFS集群
• 元數(shù)據(jù)管理：元數(shù)據(jù)管理，作為連接數(shù)據(jù)集成、存儲和分析引擎的總線
• 數(shù)據(jù)分析引擎：目前有豐富的分析引擎，比如Spark、Hadoop、Presto等，他們通常通過對接元數(shù)據(jù)來獲得數(shù)據(jù)的Schema及路徑；同時比如Spark也支持直接分析存儲路徑，在分析過程中進(jìn)行元數(shù)據(jù)的推斷

我們可以看到元數(shù)據(jù)管理是數(shù)據(jù)湖分析平臺架構(gòu)的總線，面向數(shù)據(jù)生態(tài)要支持豐富的數(shù)據(jù)集成工具對接，面向數(shù)據(jù)湖存儲要進(jìn)行完善的數(shù)據(jù)管理，面向分析引擎要能夠提供可靠的元數(shù)據(jù)服務(wù)。

?

3、元數(shù)據(jù)管理面臨的挑戰(zhàn)

元數(shù)據(jù)管理如此重要，但是當(dāng)前開源的方案不夠成熟，經(jīng)常會聽到大家關(guān)于元數(shù)據(jù)管理相關(guān)的討論，比如：

• 有10來個數(shù)據(jù)存儲系統(tǒng)，每種都去對接適配，每次都要配置賬密、路徑，真麻煩，有沒有統(tǒng)一的視圖？
• 一個有200個字段的CSV文件，手動寫出200個字段的DDL真的好累？JSON添加了字段每次都需要手動處理下嗎？
• 我的業(yè)務(wù)數(shù)據(jù)，是否有被其他同學(xué)刪庫跑路的風(fēng)險？
• 分區(qū)太多了，每次分析在讀取分區(qū)上居然占用了那么多時間？
• .....

4、業(yè)界數(shù)據(jù)湖元數(shù)據(jù)管理現(xiàn)狀

上面這些是大家在對數(shù)據(jù)湖進(jìn)行管理分析時遇到的典型問題。這些問題其實都可以通過完善的元數(shù)據(jù)管理系統(tǒng)來解決，從元數(shù)據(jù)管理的視角可以總結(jié)為：

• 如何構(gòu)建數(shù)據(jù)的統(tǒng)一管理視圖：面向多種數(shù)據(jù)源需要有一套統(tǒng)一的數(shù)據(jù)管理模型，比如通過JDBC連接數(shù)據(jù)庫、通過云賬號授權(quán)管理對象存儲文件、一套Serde管理處理不同的數(shù)據(jù)格式處理方式等。
• 如何構(gòu)建多租戶的權(quán)限管理：如果全域數(shù)據(jù)都使用數(shù)據(jù)湖方案管理，企業(yè)多部門研發(fā)人員共同使用數(shù)據(jù)湖挖掘價值，但是缺少有效的數(shù)據(jù)租戶及權(quán)限隔離，會產(chǎn)生數(shù)據(jù)風(fēng)險；
• 如何自動化的構(gòu)建元數(shù)據(jù)：通過ETL模式的數(shù)據(jù)集成工具寫入數(shù)據(jù)湖存儲時，對應(yīng)工具知道數(shù)據(jù)Schema可以主動建元數(shù)據(jù)，這樣就需要元數(shù)據(jù)服務(wù)有完善的開放接口。但是在某些場景數(shù)據(jù)文件直接上傳到OSS存儲，且文件量巨大、數(shù)據(jù)動態(tài)增長變化；這種情況需要有一套被動推斷提取元數(shù)據(jù)的服務(wù)，做到Schema感知以及增量識別。
• 如何提供面向分析的優(yōu)化能力：比如海量分區(qū)的高效加載等。

?

針對這些問題業(yè)界在做了大量的探索和實踐：

• Hive Metastore：在Hadoop生態(tài)為了構(gòu)建統(tǒng)一的管理視圖，用戶會在自己的Hadoop集群搭建HMS服務(wù)。
• AWS Glue Meta：提供多租戶的統(tǒng)一數(shù)據(jù)湖元數(shù)據(jù)管理服務(wù)，配套Serverless的元數(shù)據(jù)爬取技術(shù)生成元數(shù)據(jù)。相關(guān)功能收費。
• Aliyun DLA Meta: Meta兼容Hive Metastore，支持云上15+種數(shù)據(jù)數(shù)據(jù)源（OSS、HDFS、DB、DW）的統(tǒng)一視圖，提供開放的元數(shù)據(jù)訪問服務(wù)，引入多租戶、元數(shù)據(jù)發(fā)現(xiàn)、對接HUDI等能力。DLA Meta追求邊際成本為0，免費提供使用。下面也將重點介紹DLA Meta的相關(guān)技術(shù)實現(xiàn)。

?

二、云原生數(shù)據(jù)湖的元數(shù)據(jù)管理架構(gòu)

為了解決上面這些挑戰(zhàn)，阿里云云原生數(shù)據(jù)湖分析服務(wù)DLA的元數(shù)據(jù)管理，支持統(tǒng)一的多租戶元數(shù)據(jù)管理視圖；數(shù)據(jù)模型兼容Hive Metastore；提供阿里云OpenAPI、Client、JDBC三種開放模式；同時提供元數(shù)據(jù)自動發(fā)現(xiàn)服務(wù)一鍵異步構(gòu)建元數(shù)據(jù)。下面是各個模塊的介紹：

• 統(tǒng)一元數(shù)據(jù)視圖：支持15+中數(shù)據(jù)源，OSS、HDFS、DB、DW等；并兼容Hive Metastore的數(shù)據(jù)模型，比如Schema、View、UDF、Table、Partition、Serde等，友好對接Spark、Hadoop、Hudi等生態(tài)；
• 豐富的開放模式：支持阿里云OpenAPi、Client、JDBC三種接口開放模式，方便生態(tài)工具及業(yè)務(wù)集成DLA Meta，比如可以開發(fā)Sqoop元數(shù)據(jù)插件對接OpenAPI，同步數(shù)據(jù)時構(gòu)建元數(shù)據(jù)；目前開源Apache Hudi支持通過JDBC方式對接DLA Meta；DLA內(nèi)置的Serverless Spark、Presto、Hudi支持通過Client模式對接DLA Meta；
• 支持多租戶及權(quán)限控制：基于UID的多租戶機(jī)制進(jìn)行權(quán)限的隔離，通過GRANT&REVOKE進(jìn)行賬號間的權(quán)限管理。
• 支持水平擴(kuò)展：為了滿足海量元數(shù)據(jù)的管理，服務(wù)本身是可以水平擴(kuò)展，同時底層使用RDS&PolarDB的庫表拆分技術(shù)，支持存儲的擴(kuò)展。
• 元數(shù)據(jù)發(fā)現(xiàn)服務(wù)：當(dāng)數(shù)據(jù)入湖時沒有關(guān)聯(lián)元數(shù)據(jù)，可以通過元數(shù)據(jù)發(fā)現(xiàn)服務(wù)一鍵自動關(guān)聯(lián)元數(shù)據(jù)。

?

可以看出在對接多種數(shù)據(jù)源以及數(shù)據(jù)集成方式方面提供了友好的開放性，目前Apache Hudi原生對接了DLA Meta；在分析生態(tài)方面支持業(yè)界通用的數(shù)據(jù)模型標(biāo)準(zhǔn)(Hive Metastore)；同時服務(wù)本身具備多租戶、可擴(kuò)展的能力滿足企業(yè)級的需求。

?

三、元數(shù)據(jù)管理核心技術(shù)解析

下面主要介紹DLA Meta關(guān)于元數(shù)據(jù)多租戶、元數(shù)據(jù)發(fā)現(xiàn)、海量分區(qū)管理三方面的技術(shù)實踐，這幾塊也是目前業(yè)界核心關(guān)注和探索的問題。

1、元數(shù)據(jù)多租戶管理

在大數(shù)據(jù)體系中，使用Hive MetaStore （下面簡稱HMS）作為元數(shù)據(jù)服務(wù)是非常普遍的使用方法。DLA 作為多租戶的產(chǎn)品，其中一個比較重要的功能就是需要對不同用戶的元數(shù)據(jù)進(jìn)行隔離，而且需要擁有完整的權(quán)限體系；HMS 本身是不支持多租戶和權(quán)限體系。阿里云DLA 重寫了一套Meta 服務(wù)，其核心目標(biāo)是兼容 HMS、支持多租戶、支持完整的權(quán)限體系、同時支持存儲各種數(shù)據(jù)源的元數(shù)據(jù)。

?

多租戶實現(xiàn)

為了實現(xiàn)多租戶功能，我們把每張庫的元數(shù)據(jù)和阿里云的UID 進(jìn)行關(guān)聯(lián)，而表的元數(shù)據(jù)又是和庫的元信息關(guān)聯(lián)的。所以基于這種設(shè)計每張庫、每張表都是可以對應(yīng)到具體的用戶。當(dāng)用戶請求元數(shù)據(jù)的時候，除了需要傳進(jìn)庫名和表名，還需要將請求的阿里云UID 帶進(jìn)來，再結(jié)合上述關(guān)聯(lián)關(guān)系就可以拿到相應(yīng)用戶的元數(shù)據(jù)。每個元數(shù)據(jù)的API 都有一個UID 參數(shù)，比如如果我們需要通過getTable 獲取某個用戶的表信息，整個流程如下：

上面的ACCOUNT 是DLA 中存儲用戶賬戶信息的表；DBS 和TBLS 是用于存儲元數(shù)據(jù)的表。虛線代表他們之間的關(guān)聯(lián)關(guān)系。

權(quán)限體系

我們知道，一般大型的企業(yè)會存在多個不同部門，或者一個比較大的部門需要區(qū)分出不同的用戶，這些用戶之間又需要共享一些資源。為了解決這個問題，DLA 將阿里云UID 作為主賬號，DLA userName 作為子賬號來區(qū)別每個用戶，同一個阿里云UID 下面的不同子用戶訪問的資源是有限制的，比如主賬號用戶可以看到所有的元數(shù)據(jù)；而一般用戶只能看到一部分。為了解決這個問題，DLA Meta 實現(xiàn)了一套完整的權(quán)限體系，用戶可以通過GRANT/REVOKE 對用戶進(jìn)行相關(guān)的權(quán)限操作。

?

DLA Meta 中所有對外的元數(shù)據(jù)API 都是有權(quán)限校驗的，比如Create Database 是需要有全局的Create 或All 權(quán)限的。只有權(quán)限校驗通過才可以進(jìn)行下一步的操作。目前DLA Meta 權(quán)限控制粒度是做到表級別的，可以對用戶授予表級別的權(quán)限；當(dāng)然，列粒度、分區(qū)粒度的權(quán)限我們也是可以做到的，目前還在規(guī)劃中。下面是我們權(quán)限校驗的處理流程：

?

由于DLA Presto可以兼容MySQL 權(quán)限操作相關(guān)，為了降低用戶的使用成本，當(dāng)前DLA Meta 的權(quán)限是與MySQL 權(quán)限是兼容的，所以如果你對MySQL 的權(quán)限體系比較了解，那么這些知識是可以直接運用到DLA 的。

2、元數(shù)據(jù)發(fā)現(xiàn)Schema推斷技術(shù)

元數(shù)據(jù)發(fā)現(xiàn)的定位：為OSS等存儲上面的數(shù)據(jù)文件自動發(fā)現(xiàn)和構(gòu)建表、字段、分區(qū)，并感知新增表&字段&分區(qū)等元數(shù)據(jù)信息，方便計算與分析。

從上圖可以看出，元數(shù)據(jù)發(fā)現(xiàn)的輸入是一個父目錄，下面可以包含百萬級別OSS的文件，同時這些文件還在增量的添加。輸出為根據(jù)Schema信息進(jìn)行聚合生成數(shù)目為萬級別的表，以及單表萬級別分區(qū)。元數(shù)據(jù)自動發(fā)現(xiàn)引擎主要包括文件Schema識別器、文件表分類器、Meta同步三塊，下面重點介紹Schema識別器、以及文件表分類器。

?

文件Schema識別器：這個模塊主要用來推斷OSS上面文件的格式及字段。對于一個文件完全沒有Schema信息情況下，首先需要推斷出是什么格式，然后還需要推斷出具體的字段。整個模塊包括文件采樣、Schema識別器兩塊。測試表明單個文件的Schema探測需要150ms左右，如果對所有的文件進(jìn)行全量的識別，整個效率會比較低，DLA 元數(shù)據(jù)發(fā)現(xiàn)有一套采樣的技術(shù)，減少文件識別的數(shù)量。具體的Schema識別器由一組Schema推斷的策略組成，面對一個沒有任何先驗信息的文件，通過逐個匹配CSV、JSON、Parquet等推斷器的方式來進(jìn)行識別，每種推斷器在效率和準(zhǔn)確性上面做了大量優(yōu)化，比如CSV內(nèi)部包含了30+種根據(jù)表頭、分隔符、轉(zhuǎn)義、引用組合的策略，同時字段的識別使用數(shù)據(jù)行采樣的方式保證準(zhǔn)確率的情況下，減少遠(yuǎn)程IO讀取。

文件分類器：由于文件在OSS上面是按照目錄存儲的，當(dāng)通過Schema識別器識別出了葉子節(jié)點目錄下面的Schema情況后，如果每個葉子節(jié)點目錄創(chuàng)建一張表，表會很多，管理復(fù)雜且難以分析。因此需要有一套文件分類器來聚合生成最終的表。且支持增量文件的Schema變更，比如添加字段、添加分區(qū)等。下面是整個分類算法過程，根據(jù)目錄樹形的結(jié)構(gòu)，第一步先深度遍歷并結(jié)合“文件Schema識別器”在每個節(jié)點聚合子節(jié)點的Schema是否兼容，如果兼容則把子目錄向上合并為分區(qū)，如果不兼容則每個子目錄創(chuàng)建一張表。經(jīng)過第一步后每個節(jié)點是否可以創(chuàng)建表、分區(qū)信息，以及合并后的Schema都會存儲在節(jié)點上面；第二步再次遍歷可以生成對應(yīng)的Meta創(chuàng)建事件。

這種通用的算法可以識別任意目錄擺放，但是由于面向海量分區(qū)的場景，事先不知道分區(qū)目錄是否可以聚合，這樣每個目錄都需要采樣識別，且在聚合時如果某個分區(qū)和其他分區(qū)兼容度達(dá)不到要求，會拆分生成大量的表，在這種場景下性能一般。如果用戶的OSS目錄結(jié)構(gòu)按照典型的數(shù)倉結(jié)構(gòu)，庫、表、分區(qū)模式規(guī)劃，那么在分區(qū)識別及表識別上面會有固定的規(guī)則，這樣可以對上面的算法遍歷過程剪枝，分區(qū)間的采樣率進(jìn)一步減少，且容錯率更高。數(shù)倉模式的目錄規(guī)劃需要如下：

3、海量分區(qū)處理技術(shù)

分區(qū)投影

在大數(shù)據(jù)場景中，分區(qū)是用于提升性能非常常見的方法，合理劃分分區(qū)有利于計算引擎過濾掉大量無用的數(shù)據(jù)從而提升計算性能。但是如果分區(qū)非常多，比如單表數(shù)百萬的分區(qū)，那么計算引擎從元數(shù)據(jù)服務(wù)查詢分區(qū)所需要的時間就會上升，從而使得查詢的整體時間變長。比如我們客戶有張表有130多萬分區(qū)，一個簡單的分區(qū)過濾查詢元數(shù)據(jù)訪問這塊就花了4秒以上的時間，而剩下的計算時間卻不到1秒！

?

針對這個問題，我們設(shè)計開發(fā)出了一種叫做“分區(qū)映射”的功能，分區(qū)映射讓用戶指定分區(qū)的規(guī)則，然后具體每個SQL查詢的分區(qū)會直接通過SQL語句中的查詢條件結(jié)合用戶創(chuàng)建表時候指定的規(guī)則直接在計算引擎中計算出來，從而不用去查詢外部的元數(shù)據(jù)，避免元數(shù)據(jù)爆炸帶來的性能問題。經(jīng)測試，上述場景下，利用分區(qū)投影生成分區(qū)需要的時間降為1秒以下，大大提升查詢效率。

基于OSS的Metatable技術(shù)

可以看到DLA的分區(qū)投影技術(shù)降低了海量分區(qū)情況下，訪問Meta服務(wù)的時間開銷，該技術(shù)通過計算側(cè)計算分區(qū)的方法來規(guī)避掉海量分區(qū)的訪問。DLA目前基于Apache Hudi實現(xiàn)DLA Lakehouse，提供高效的湖倉。其中在海量分區(qū)處理這塊，Apache Hudi將表的海量分區(qū)映射信息存儲在一個OSS上面的Object里面，這樣通過讀取若干個Object文件可以獲取所有的分區(qū)信息，規(guī)避訪問Meta服務(wù)的開銷。下面介紹DLA Lakehouse基于Hudi的Metatable技術(shù)：

從上圖可以看到DLA Meta中會存儲庫、表、分區(qū)的信息，使用當(dāng)前方案OSS上面分區(qū)目錄對應(yīng)的分區(qū)信息會存儲在DLA Meta服務(wù)中，當(dāng)分析引擎訪問這張表的時候，會通過DLA Meta服務(wù)讀取大量的分區(qū)信息，這些分區(qū)信息會從底層的RDS中讀出，這樣會有一定的訪問開銷。如果使用到DLA Lakehouse方案，可以將大量的分區(qū)映射信息單獨存儲在基于OSS對象的Hudi Metatable中，Metatable底層基于HFile支持更新刪除，通過KV存儲方式提高分區(qū)查詢效率。這樣分析引擎在訪問分區(qū)表的時候，可以只在Meta中讀取庫、表輕量的信息，分區(qū)信息可以通過讀取OSS的對象獲取。目前該方案還在規(guī)劃中，DLA線上還不支持。

?

四、云原生數(shù)據(jù)湖最佳實踐

最佳實踐，以DLA為例子。DLA致力于幫助客戶構(gòu)建低成本、簡單易用、彈性的數(shù)據(jù)平臺，比傳統(tǒng)Hadoop至少節(jié)約50%的成本。其中DLA Meta支持云上15+種數(shù)據(jù)數(shù)據(jù)源（OSS、HDFS、DB、DW）的統(tǒng)一視圖，引入多租戶、元數(shù)據(jù)發(fā)現(xiàn)，追求邊際成本為0，免費提供使用。DLA Lakehouse基于Apache Hudi實現(xiàn)，主要目標(biāo)是提供高效的湖倉，支持CDC及消息的增量寫入，目前這塊在加緊產(chǎn)品化中。DLA Serverless Presto是基于Apache PrestoDB研發(fā)的，主要是做聯(lián)邦交互式查詢與輕量級ETL。DLA支持Spark主要是為在湖上做大規(guī)模的ETL，并支持流計算、機(jī)器學(xué)習(xí)；比傳統(tǒng)自建Spark有著300%的性價比提升，從ECS自建Spark或者Hive批處理遷移到DLA Spark可以節(jié)約50%的成本。基于DLA的一體化數(shù)據(jù)處理方案，可以支持BI報表、數(shù)據(jù)大屏、數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)、IOT分析、數(shù)據(jù)科學(xué)等多種業(yè)務(wù)場景。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的深度 | 面向云原生数据湖的元数据管理技术解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。