<meta name="source" content="lake">
背景
數據湖當前在國內外是比較熱的方案，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分析、數據科學等多種業務場景。
本文爲阿里雲原創內容，未經允許不得轉載。