背景
資料湖目前在國内外是比較熱的方案，
MarketsandMarkets市場調研顯示預計資料湖市場規模在2024年會從2019年的79億美金增長到201億美金。一些企業已經建構了自己的雲原生資料湖方案，有效解決了業務痛點；還有很多企業在建構或者計劃建構自己的資料湖，
Gartner 2020年釋出的報告顯示目前已經有39%的使用者在使用資料湖，34%的使用者考慮在1年内使用資料湖。随着對象存儲等雲原生存儲技術的成熟，一開始大家會先把結構化、半結構化、圖檔、視訊等資料存儲在對象存儲中。當需要對這些資料進行分析時，發現缺少面向分析的資料管理視圖，在這樣的背景下業界在面向雲原生資料湖的中繼資料管理技術進行了廣泛的探索和落地。
一、中繼資料管理面臨的挑戰
1、什麼是資料湖
Wikipedia上說資料湖是一類存儲資料自然/原始格式的系統或存儲，通常是對象塊或者檔案，包括原始系統所産生的原始資料拷貝以及為了各類任務而産生的轉換資料，包括來自于關系型資料庫中的結構化資料（行和列）、半結構化資料（如CSV、日志、XML、JSON）、非結構化資料（如email、文檔、PDF、圖像、音頻、視訊）。
從上面可以總結出資料湖具有以下特性：
- 資料來源：原始資料、轉換資料
- 資料類型：結構化資料、半結構化資料、非結構化資料、二進制
- 資料湖存儲：可擴充的海量資料存儲服務
2、資料湖分析方案架構
當資料湖隻是作為存儲的時候架構架構比較清晰，在基于資料湖存儲建構分析平台過程中，業界進行了大量的實踐，基本的架構如下：
主要包括五個子產品：
- 資料源：原始資料存儲子產品，包括結構化資料(Database等)、半結構化(File、日志等)、非結構化(音視訊等)
- 資料內建：為了将資料統一到資料湖存儲及管理，目前資料內建主要分為三種形态。第一種為直接通過外表的方式關聯中繼資料；第二種為基于ETL、內建工具、流式寫入模式，這種方式直接處理資料能夠感覺Schema，在寫入資料的過程中同時建立中繼資料；第三種為檔案直接上傳資料湖存儲，需要事後異步建構中繼資料
- 資料湖存儲：目前業界主要使用對象存儲以及自建HDFS叢集
- 中繼資料管理：中繼資料管理，作為連接配接資料內建、存儲和分析引擎的總線
- 資料分析引擎：目前有豐富的分析引擎，比如Spark、Hadoop、Presto等，他們通常通過對接中繼資料來獲得資料的Schema及路徑；同時比如Spark也支援直接分析存儲路徑，在分析過程中進行中繼資料的推斷
我們可以看到中繼資料管理是資料湖分析平台架構的總線，面向資料生态要支援豐富的資料內建工具對接，面向資料湖存儲要進行完善的資料管理，面向分析引擎要能夠提供可靠的中繼資料服務。
3、中繼資料管理面臨的挑戰
中繼資料管理如此重要，但是目前開源的方案不夠成熟，經常會聽到大家關于中繼資料管理相關的讨論，比如：
- 有10來個資料存儲系統，每種都去對接适配，每次都要配置賬密、路徑，真麻煩，有沒有統一的視圖？
- 一個有200個字段的CSV檔案，手動寫出200個字段的DDL真的好累？JSON添加了字段每次都需要手動處理下嗎？
- 我的業務資料，是否有被其他同學删庫跑路的風險？
- 分區太多了，每次分析在讀取分區上居然占用了那麼多時間？
- .....
4、業界資料湖中繼資料管理現狀
上面這些是大家在對資料湖進行管理分析時遇到的典型問題。這些問題其實都可以通過完善的中繼資料管理系統來解決，從中繼資料管理的視角可以總結為：
- 如何建構資料的統一管理視圖：面向多種資料源需要有一套統一的資料管理模型，比如通過JDBC連接配接資料庫、通過雲賬号授權管理對象存儲檔案、一套Serde管理處理不同的資料格式處理方式等。
- 如何建構多租戶的權限管理：如果全域資料都使用資料湖方案管理，企業多部門研發人員共同使用資料湖挖掘價值，但是缺少有效的資料租戶及權限隔離，會産生資料風險；
- 如何自動化的建構中繼資料：通過ETL模式的資料內建工具寫入資料湖存儲時，對應工具知道資料Schema可以主動建中繼資料，這樣就需要中繼資料服務有完善的開放接口。但是在某些場景資料檔案直接上傳到OSS存儲，且檔案量巨大、資料動态增長變化；這種情況需要有一套被動推斷提取中繼資料的服務，做到Schema感覺以及增量識别。
- 如何提供面向分析的優化能力：比如海量分區的高效加載等。
針對這些問題業界在做了大量的探索和實踐：
- Hive Metastore：在Hadoop生态為了建構統一的管理視圖，使用者會在自己的Hadoop叢集搭建HMS服務。
- AWS Glue Meta：提供多租戶的統一資料湖中繼資料管理服務，配套Serverless的中繼資料爬取技術生成中繼資料。相關功能收費。
- Aliyun DLA Meta: Meta相容Hive Metastore，支援雲上15+種資料資料源（OSS、HDFS、DB、DW）的統一視圖，提供開放的中繼資料通路服務，引入多租戶、中繼資料發現、對接HUDI等能力。DLA Meta追求邊際成本為0，免費提供使用。下面也将重點介紹DLA Meta的相關技術實作。
二、雲原生資料湖的中繼資料管理架構
為了解決上面這些挑戰，阿裡雲雲原生資料湖分析服務DLA的中繼資料管理，支援統一的多租戶中繼資料管理視圖；資料模型相容Hive Metastore；提供阿裡雲OpenAPI、Client、JDBC三種開放模式；同時提供中繼資料自動發現服務一鍵異步建構中繼資料。下面是各個子產品的介紹：
- 統一進制資料視圖：支援15+中資料源，OSS、HDFS、DB、DW等；并相容Hive Metastore的資料模型，比如Schema、View、UDF、Table、Partition、Serde等，友好對接Spark、Hadoop、Hudi等生态；
- 豐富的開放模式：支援阿裡雲OpenAPi、Client、JDBC三種接口開放模式，友善生态工具及業務內建DLA Meta，比如可以開發Sqoop中繼資料插件對接OpenAPI，同步資料時建構中繼資料；目前開源Apache Hudi支援通過JDBC方式對接DLA Meta；DLA内置的Serverless Spark、Presto、Hudi支援通過Client模式對接DLA Meta；
- 支援多租戶及權限控制：基于UID的多租戶機制進行權限的隔離，通過GRANT&REVOKE進行賬号間的權限管理。
- 支援水準擴充：為了滿足海量中繼資料的管理，服務本身是可以水準擴充，同時底層使用RDS&PolarDB的庫表拆分技術，支援存儲的擴充。
- 中繼資料發現服務：當資料入湖時沒有關聯中繼資料，可以通過中繼資料發現服務一鍵自動關聯中繼資料。
可以看出在對接多種資料源以及資料內建方式方面提供了友好的開放性，目前Apache Hudi原生對接了DLA Meta；在分析生态方面支援業界通用的資料模型标準(Hive Metastore)；同時服務本身具備多租戶、可擴充的能力滿足企業級的需求。
三、中繼資料管理核心技術解析
下面主要介紹DLA Meta關于中繼資料多租戶、中繼資料發現、海量分區管理三方面的技術實踐，這幾塊也是目前業界核心關注和探索的問題。
1、中繼資料多租戶管理
在大資料體系中，使用Hive MetaStore （下面簡稱HMS）作為中繼資料服務是非常普遍的使用方法。DLA 作為多租戶的産品，其中一個比較重要的功能就是需要對不同使用者的中繼資料進行隔離，而且需要擁有完整的權限體系；HMS 本身是不支援多租戶和權限體系。阿裡雲DLA 重寫了一套Meta 服務，其核心目标是相容 HMS、支援多租戶、支援完整的權限體系、同時支援存儲各種資料源的中繼資料。
多租戶實作
為了實作多租戶功能，我們把每張庫的中繼資料和阿裡雲的UID 進行關聯，而表的中繼資料又是和庫的元資訊關聯的。是以基于這種設計每張庫、每張表都是可以對應到具體的使用者。當使用者請求中繼資料的時候，除了需要傳進庫名和表名，還需要将請求的阿裡雲UID 帶進來，再結合上述關聯關系就可以拿到相應使用者的中繼資料。每個中繼資料的API 都有一個UID 參數，比如如果我們需要通過getTable 擷取某個使用者的表資訊，整個流程如下：
上面的ACCOUNT 是DLA 中存儲使用者賬戶資訊的表；DBS 和TBLS 是用于存儲中繼資料的表。虛線代表他們之間的關聯關系。
權限體系
我們知道，一般大型的企業會存在多個不同部門，或者一個比較大的部門需要區分出不同的使用者，這些使用者之間又需要共享一些資源。為了解決這個問題，DLA 将阿裡雲UID 作為主賬号，DLA userName 作為子賬号來差別每個使用者，同一個阿裡雲UID 下面的不同子使用者通路的資源是有限制的，比如主賬号使用者可以看到所有的中繼資料；而一般使用者隻能看到一部分。為了解決這個問題，DLA Meta 實作了一套完整的權限體系，使用者可以通過GRANT/REVOKE 對使用者進行相關的權限操作。
DLA Meta 中所有對外的中繼資料API 都是有權限校驗的，比如Create Database 是需要有全局的Create 或All 權限的。隻有權限校驗通過才可以進行下一步的操作。目前DLA Meta 權限控制粒度是做到表級别的，可以對使用者授予表級别的權限；當然，列粒度、分區粒度的權限我們也是可以做到的，目前還在規劃中。下面是我們權限校驗的處理流程：
由于DLA Presto可以相容MySQL 權限操作相關，為了降低使用者的使用成本，目前DLA Meta 的權限是與MySQL 權限是相容的，是以如果你對MySQL 的權限體系比較了解，那麼這些知識是可以直接運用到DLA 的。
2、中繼資料發現Schema推斷技術
中繼資料發現的定位：為OSS等存儲上面的資料檔案自動發現和建構表、字段、分區，并感覺新增表&字段&分區等中繼資料資訊，友善計算與分析。
從上圖可以看出，中繼資料發現的輸入是一個父目錄，下面可以包含百萬級别OSS的檔案，同時這些檔案還在增量的添加。輸出為根據Schema資訊進行聚合生成數目為萬級别的表，以及單表萬級别分區。中繼資料自動發現引擎主要包括檔案Schema識别器、檔案表分類器、Meta同步三塊，下面重點介紹Schema識别器、以及檔案表分類器。
檔案Schema識别器：這個子產品主要用來推斷OSS上面檔案的格式及字段。對于一個檔案完全沒有Schema資訊情況下，首先需要推斷出是什麼格式，然後還需要推斷出具體的字段。整個子產品包括檔案采樣、Schema識别器兩塊。測試表明單個檔案的Schema探測需要150ms左右，如果對所有的檔案進行全量的識别，整個效率會比較低，DLA 中繼資料發現有一套采樣的技術，減少檔案識别的數量。具體的Schema識别器由一組Schema推斷的政策組成，面對一個沒有任何先驗資訊的檔案，通過逐個比對CSV、JSON、Parquet等推斷器的方式來進行識别，每種推斷器在效率和準确性上面做了大量優化，比如CSV内部包含了30+種根據表頭、分隔符、轉義、引用組合的政策，同時字段的識别使用資料行采樣的方式保證準确率的情況下，減少遠端IO讀取。
檔案分類器：由于檔案在OSS上面是按照目錄存儲的，當通過Schema識别器識别出了葉子節點目錄下面的Schema情況後，如果每個葉子節點目錄建立一張表，表會很多，管理複雜且難以分析。是以需要有一套檔案分類器來聚合生成最終的表。且支援增量檔案的Schema變更，比如添加字段、添加分區等。下面是整個分類算法過程，根據目錄樹形的結構，第一步先深度周遊并結合“檔案Schema識别器”在每個節點聚合子節點的Schema是否相容，如果相容則把子目錄向上合并為分區，如果不相容則每個子目錄建立一張表。經過第一步後每個節點是否可以建立表、分區資訊，以及合并後的Schema都會存儲在節點上面；第二步再次周遊可以生成對應的Meta建立事件。
這種通用的算法可以識别任意目錄擺放，但是由于面向海量分區的場景，事先不知道分區目錄是否可以聚合，這樣每個目錄都需要采樣識别，且在聚合時如果某個分區和其他分區相容度達不到要求，會拆分生成大量的表，在這種場景下性能一般。如果使用者的OSS目錄結構按照典型的數倉結構，庫、表、分區模式規劃，那麼在分區識别及表識别上面會有固定的規則，這樣可以對上面的算法周遊過程剪枝，分區間的采樣率進一步減少，且容錯率更高。數倉模式的目錄規劃需要如下：
3、海量分區處理技術
分區投影
在大資料場景中，分區是用于提升性能非常常見的方法，合理劃分分區有利于計算引擎過濾掉大量無用的資料進而提升計算性能。但是如果分區非常多，比如單表數百萬的分區，那麼計算引擎從中繼資料服務查詢分區所需要的時間就會上升，進而使得查詢的整體時間變長。比如我們客戶有張表有130多萬分區，一個簡單的分區過濾查詢中繼資料通路這塊就花了4秒以上的時間，而剩下的計算時間卻不到1秒！
針對這個問題，我們設計開發出了一種叫做“分區映射”的功能，分區映射讓使用者指定分區的規則，然後具體每個SQL查詢的分區會直接通過SQL語句中的查詢條件結合使用者建立表時候指定的規則直接在計算引擎中計算出來，進而不用去查詢外部的中繼資料，避免中繼資料爆炸帶來的性能問題。經測試，上述場景下，利用分區投影生成分區需要的時間降為1秒以下，大大提升查詢效率。
基于OSS的Metatable技術
可以看到DLA的分區投影技術降低了海量分區情況下，通路Meta服務的時間開銷，該技術通過計算側計算分區的方法來規避掉海量分區的通路。DLA目前基于Apache Hudi實作DLA Lakehouse，提供高效的湖倉。其中在海量分區處理這塊，Apache Hudi将表的海量分區映射資訊存儲在一個OSS上面的Object裡面，這樣通過讀取若幹個Object檔案可以擷取所有的分區資訊，規避通路Meta服務的開銷。下面介紹DLA Lakehouse基于Hudi的Metatable技術：
從上圖可以看到DLA Meta中會存儲庫、表、分區的資訊，使用目前方案OSS上面分區目錄對應的分區資訊會存儲在DLA Meta服務中，當分析引擎通路這張表的時候，會通過DLA Meta服務讀取大量的分區資訊，這些分區資訊會從底層的RDS中讀出，這樣會有一定的通路開銷。如果使用到DLA Lakehouse方案，可以将大量的分區映射資訊單獨存儲在基于OSS對象的Hudi Metatable中，Metatable底層基于HFile支援更新删除，通過KV存儲方式提高分區查詢效率。這樣分析引擎在通路分區表的時候，可以隻在Meta中讀取庫、表輕量的資訊，分區資訊可以通過讀取OSS的對象擷取。目前該方案還在規劃中，DLA線上還不支援。
四、雲原生資料湖最佳實踐
最佳實踐，以DLA為例子。DLA緻力于幫助客戶建構低成本、簡單易用、彈性的資料平台，比傳統Hadoop至少節約50%的成本。其中DLA Meta支援雲上15+種資料資料源（OSS、HDFS、DB、DW）的統一視圖，引入多租戶、中繼資料發現，追求邊際成本為0，免費提供使用。DLA Lakehouse基于Apache Hudi實作，主要目标是提供高效的湖倉，支援CDC及消息的增量寫入，目前這塊在加緊産品化中。DLA Serverless Presto是基于Apache PrestoDB研發的，主要是做聯邦互動式查詢與輕量級ETL。DLA支援Spark主要是為在湖上做大規模的ETL，并支援流計算、機器學習；比傳統自建Spark有着300%的成本效益提升，從ECS自建Spark或者Hive批處理遷移到DLA Spark可以節約50%的成本。基于DLA的一體化資料處理方案，可以支援BI報表、資料大屏、資料挖掘、機器學習、IOT分析、資料科學等多種業務場景。
歡迎大家關注我們