資料湖統一後設資料與許可權

一、 後設資料與許可權背景介紹

開源後設資料體系由來、演進及問題

開源大資料體系是指以 Hadoop 為中心的生態系統，而目前 Hive 是開源數倉的事實標準。

關於大資料的由來和發展，要追溯到谷歌在2003 年發表的論文，論文中提出了 HDFS 和 MapReduce 兩個元件。HDFS 元件最早用於解決網頁儲存問題，它可以部署在大量廉價的機器上，提供極佳的硬體容錯能力以及儲存的擴充套件性。MapReduce 的初衷是解決搜尋引擎中大規模網頁資料的並行化處理問題。同時它也是比較通用的並行處理框架，可用於處理很多大資料場景。

雖然 HDFS 和 MapReduce 很好地解決了大資料儲存和大規模資料並行處理的問題，但依然存在幾個缺點：

第一，程式設計門檻較高。傳統的數倉工程師接觸的程式設計介面一般是 SQL ，但 MapReduce 框架有一定的程式設計能力要求。

第二，HDFS 上儲存的是檔案和目錄，並沒有儲存後設資料，也無法進行查詢。因此即使知道檔案的結構，也無法對檔案的內容方式變化進行管理，導致程式本身可能喪失穩定性。

基於以上痛點，以雅虎為代表的公司提出了 Apache Pig，提供 SQL-like 語言，該語言的編譯器會把類 SQL 的資料分析請求轉換為一系列經過最佳化處理的 MapReduce 運算，遮蔽了 MapReduce 細節，可以很輕鬆高效地處理資料；而以 Facebook 為代表的公司提出 Hive 的解決方案，在 HDFS 上提供了一層資料抽象，遮蔽了檔案系統及程式設計模型的細節，極大降低了數倉開發人員的門檻。透過對資料及檔案系統到後設資料的抽象，能夠非常方便地進行資料共享、檢索以及檢視資料變更歷史。這一層的後設資料抽象即如今大家所熟知的 Database、Table 、Partition和 Function ，同時在後設資料上又衍生出了非常接近 SQL 語言的 HiveQL。同時後續的 Hive3.0 版本新增了 catalog 的功能，Hive4.0版本新增了 Connectors 功能。依託於後設資料, 計算引擎可以很好地進行歷史的追溯。除了追溯歷史 schema 變更外，後設資料還有一個重要功能是保護資料（不做不相容的變更）。

Hive3.0實現的 catalog 功能，主要基於以下兩個場景：

① 多個系統之間可能需要 MetaStore 後設資料的 Namespace，期望能夠達到一定的隔離。比如 Spark 有自己的 catalog ，Hive 也有自己的 catalog，不同的 catalog 上可以有不同的鑑權、運營策略。

② 可以對接外部系統的 catalog。

Hive4.0的 Connectors 主要是定義資料 DataSource，其他引擎對接 Hive 後設資料後，即可透過該介面識別 DataSource 的資訊，方便其他引擎做查詢。

目前 Hive上幾乎已經支援了 Hadoop 生態的所有計算引擎，因此它也已經成為開源數倉的事實標準。但它依然存在一些問題，比如雖然支援了 schema 的衍變，但是並不能透過 Time-Travel 的方式查詢資料變化的歷史快照，雖然有 ACID 新特性，但與 Hive 引擎的深度繫結導致無法很好地移植到其他引擎上。

另外， ACID 特性主要使用 rename 的方式做 isolation 隔離，在做檔案 Compaction 及在儲存分離等場景容易出現問題，比如 rename 過程在雲端儲存上的效能問題。開源社群針對這些點衍化出了一些資料湖的格式，在不同程度上解決了 ACID 的問題。

資料湖格式擁有自己的後設資料，同時會將自身的後設資料註冊到 Hive Metastore中。資料湖格式的後設資料與 Hive 後設資料形成補充，並沒有脫離整體 Hive 後設資料的檢視，其他引擎依然可以透過 Hive Metastore 這一套後設資料管理體系訪問資料湖格式上的資料。

但 Hive Metastore 上並沒有多租戶的能力，同時受限於單個後設資料庫的能力瓶頸，有些公司會部署多套 Metastore，這很容易形成資料孤島，所以也有一些公司提出瞭解決方案，比如 Waggle-Dance 及 Multiple Hive Metastore 方案等。 另外因為 HiveMetaStore 使用 Thrift 協議的介面，所以內部引擎和自研引擎對接 Hive Metastore 時，必須對接 Metastore 的協議以及依賴相應的客戶端 ，這種依賴還是比較重的。

另外，Metastore 在設計後設資料儲存時高度去冗餘，因此會帶來一些 Metadata Fetch 的效能問題。

開源的 Waggle-Dance 方案後端有多個 Metastore，每個 Metastore 有自己的 Database 儲存。Waggle-Dance 模組實現了 Hive Metastore 後端完整的 Thrift 協議，能夠無縫對接到其它引擎，解決現有的 Metastore 瓶頸問題，比如單個 DB 儲存量、單個 Metastore 效能問題等。

但是 Waggle-Dance 解決多租戶的方案存在命名衝突問題，需要提前做 Database 和 Metastore 的命名規劃。因為 Waggle-Dance 路由的模組有一個 Database 到後端 Metastore 路由表。如果是 Hive 3.0，可以透過 catalog 這一層路由的對映設計來解決。

另外，Waggle-Dance 可能會帶來 Thrift 介面協議的衝突，比如後端可能存在多個 Hive Metastore 的版本或有多個不同 client 的版本。因此中間層的路由元件可能需要相容不同的版本，就可能會出現協議的相容性問題。

許可權控制體系介紹

除了後設資料外，後設資料和資料訪問的安全性也非常重要 。企業的資料安全性必須依賴於完善的許可權體系。許可權的基本三要素包括主體、客體和操作。ACL 建立在基礎三要素之上，對應到後設資料上為：某個人對某個表有什麼樣的操作許可權。ACL 存在一定的缺陷，比如後續如果許可權比較多會難以管理，因此又發展出 RBAC 和 PBAC 許可權。

以入住酒店為例解釋 ACL、RBAC 和 PBAC 三者的區別：比如住客入住酒店後會得到一把房門鑰匙，得到進入某個房間的許可權，即相當於 ACL ；而針對某一樓層有一個樓層管理員，可以管理所有房間，即相當於 RBAC，在 ACL 上面增加了一層使用者的角色到許可權的對映，有了角色以後很顯然降低了許可權管理成本；但是如果有比較特殊的需求，比如需要限制某一層的管理員只能在上午 7 點後才有許可權進入房間，即需要 PBAC，它是基於策略的模型，在普通許可權模型的基礎之上支援了許可權條件。

Hive 0.13 提出了 Hive Storage-Based Authorization，它是基於底層儲存的鑑權。該許可權策略的優點在於無論是 meta 操作還是底層檔案儲存操作，都可以獲得統一的許可權檢視。但它是基於目錄和底層檔案的許可權體系，因此無法很好地對映到 SQL 層面許可權操作。同時，因為底層的許可權是檔案，所以無法在資料層面或欄位級別做更細粒度的鑑權，因此它並不支援 Fine-grain control。

基於以上問題，社群提出了 Hive SQL-Standard Based Authorization，即基於 SQL 的標準化鑑權模型，能夠在 SQL 層面支援 Grant 和 Revoke 控制指令。同時可以做相對細粒度的許可權控制，比如可以將搜尋上的很多操作對映到許可權模型上。該模型實現了列級的訪問控制，但沒有實現行級的許可權。

另外，Hive SQL-Standard Based Authorization 雖然具有 SQL 層面的許可權，但並不包含儲存系統的許可權。因此做儲存系統的訪問或實操層面訪問時，無法獲得統一的許可權檢視。且該模式不支援資料湖格式。

後來，某商業公司推出了 Apache Ranger(Sentry)，面向所有大資料開源生態元件，對底層的檔案系統 YARN、Hive、Spark、Kafka 提供了中心化的許可權控制方案。同時支援在 SQL 層面進行 Grant、Revoke，比此前的模型增加了更細粒度的許可權，比如行級過濾、列級許可權控制，同時在許可權上還具備 exception policy 及其他能力。

但 Apache Ranger 也存在一些問題。因為 PBAC 模型的許可權是事先定好的，不依賴物件的存在與否。比如使用者對某表有 select 許可權，表被刪除後又被重新建出，而該使用者仍然擁有許可權，這並不合理。另外，雖然 ranger 可以使用在很多大資料元件之上，但僅限於 Hive 的 HiveServer，而 Hive Metastore 上並沒有許可權控制，所以它面臨的問題在於 Hive Metastore 提供的後設資料訪問介面和在之上提供的許可權介面存在分離。

因此，總結來看，資料湖管理面臨的挑戰包含以下幾個方面：

在後設資料服務層面，開源版本沒有多租戶的能力，擴充套件性、穩定性以及效能方面都存在問題，對接多個計算引擎難度大。

資料安全層面，許可權控制方案複雜，成熟度低，無法覆蓋所有計算引擎，且為開放儲存，許可權難以控制。

資料治理層面，開源社群目前沒有非常好的資料管理工具。無法很好地根據後設資料分析現有的儲存成本，也無法做很好的生命週期管理。雖然Hive4.0已經增加了一些特性，比如可以做 partition 的自動發現 以及對 partition 做一定的生命週期管理，但整體上依然沒有很好的治理手段。

查詢效能層面，儲存計算分離架構的讀寫效能受頻寬控制，原始資料未經過最佳化因而查詢效能低，且缺少索引、統計等加速手段。

阿里雲針對上述問題和挑戰，實現了一套面向資料湖領域的後設資料、安全、治理、加速的解決方案：

• 全託管免運維的統一後設資料中心

統一後設資料中心脫胎於阿里雲內部久經考驗的後設資料底座，無縫對接多種開源計算引擎和自研的內部引擎，同時依託於阿里雲的資料湖構建與管理DLF產品提供了後設資料的發現、遷移、備份的能力。

• 企業級許可權控制

資料安全方面，支援阿里雲賬號系統，也可以相容開源的 LDAP 賬號體系；提供欄位級別的讀寫許可權控制和 Location 許可權託管。引擎和應用甚至可以對接後設資料 API 和許可權 API ，實現自己的許可權整合或後設資料整合，從而使所有引擎及應用都可以實現對許可權的統一控制。

• 智慧資料管理與最佳化

• 精細化儲存統計與分析
• 自動化資料冷熱判斷與分層

• 多重資料湖加速

• JindoFS 提供資料快取加速
• 自動小檔案合併、資料清理
• 自動Stats計算、查詢最佳化
• 湖格式後設資料服務化

二、阿里雲資料湖統一後設資料服務

阿里雲上資料湖統一後設資料服務架構

阿里雲上資料湖統一後設資料服務（DLF）提供了多租戶、統一資料目錄，支援多引擎的擴充套件與切換。相容了 Hive2.X 與 Hive3.X 協議，能夠實現無縫對接開源與自研的所有計算引擎。同時，所有 API 、SDK 和對接開源引擎的客戶端已經在阿里雲上開源，支援客戶自研引擎、應用或系統整合。

另外，依託於底層儲存的表格儲存，面向海量結構化提供的 service 服務有著非常優秀的彈性伸縮能力，無需擔心擴充套件問題。同時提供了高可用、免運維的能力。

此外，提供統一的許可權控制，使用者只需依靠許可權的配置，無論在 EMR 引擎上、阿里雲的自研引擎上，還是在 DataWorks 等資料開發平臺上，都可以實現多引擎、多管理平臺或多應用的統一許可權管控。能夠支援阿里雲 RAM 以及開源 LDAP 賬號體系。

統一後設資料服務的最下層是資料湖儲存，目前支援物件儲存和檔案儲存。資料服務層提供了兩個基礎服務：第一層是 catalog ，負責管理後設資料，包括 Catalog、Database、Function 和 Table；第二層是許可權服務，包括 ACL 體系、RBAC 和 PBAC，TBAC 正在計劃中（主要針對資源包）。

再上層對接阿里雲閘道器認證體系，支援 RAM 的子賬號鑑權以及許可權策略，可以實現底層後設資料 API 和許可權 API ，之上提供了 SDK 外掛體系。有的雲廠商保留了所有元件，在 Hive Metastore 內部進行封裝來實現開源的無縫對接。其優點在於只需改動 Hive Metastore，其他的引擎都能自動對接到 Hive Metastore 上。而阿里雲沒有選擇 Hive Metastore 方案，主要出於以下幾個考量：

首先， 保留 Hive Metastore 會帶來一定的成本，所有請求都需要進行轉發，會導致效能損耗。同時， Hive Metastore 本身的穩定性會影響整體後設資料服務的穩定性，而且隨著使用者叢集流量的增大，Metastore 也需要擴容。因此阿里雲選擇了在輕量級 SDK 上實現 client 介面並直接嵌入到引擎中，實現開源引擎到 DLF 服務的對接。

阿里雲自研的引擎 MaxCompute、Hologres 以及全託管的 OLAP 引擎也已經完全對接DLF。另外，使用者的後設資料管理應用或開發平臺也可以對接 API。

很多使用者內部的後設資料管理應用透過 JDBC 的方式連線底層的 MySQL ，而這也可能存在問題。比如底層後設資料結構的升級會導致應用也需要改動。另一方面，直接對接JDBC介面查詢底層資料，完全沒有許可權控制。但是如果對接 DLF API ，無論是 API 訪問還是 EMR 訪問，都會經過一層許可權的控制體系，不會洩露許可權。

阿里雲上資料湖統一後設資料基本功能及最佳化

阿里雲提供了多租戶和統一的資料目錄，是以阿里雲賬號進行租戶之間隔離的一種機制。阿里雲賬號下可以建立多個 catalog，提供了 table 級別的 schema 多版本，可以根據版本資料查詢 table schema 的演變過程。同時阿里雲內部各引擎透過支援 DLF，也同時實現了 Iceberg、Hudi、Delta 資料湖格式打通。

此外，在 catalog 上會按租戶的後設資料做分割槽，使用者的儲存不會打在同一個後端儲存的熱點分割槽上。同時，我們實現了 ID 化，方便後續進行軟刪除、非同步刪除等最佳化。同時，在很多請求上實現了非同步化。

IO 方面也進行了部分最佳化。比如做 List partition 時，返回的是同一個表 partition 的所有後設資料，而在大多數場景上 partition 後設資料的 SD 都相同，因此完全可以基於相同的 SD 做共享，進行 partition SD 壓縮，減少網路層的 IO 。

阿里雲上資料湖統一後設資料之穩定性機制

穩定性是另一個比較關鍵的問題。在雲上需要對接所有租戶，因此後設資料服務的升級、灰度、自動恢復能力非常重要。自動恢復能力和彈性伸縮是雲上的標配，都是基於資源排程系統實現。

穩定性機制的底層是阿里雲 Table Store，上層是後設資料服務。後設資料服務有兩個常駐叢集A和B，互為主備關係。在做升級時，將備服務配置為灰度狀態，前端閘道器根據服務的配置策略以及租戶分桶策略採集流量，然後發到灰度服務上，觀察灰度流量是否正常，如果正常則升級到主服務；如果出現問題，則根據配置回滾即可。

升級對使用者側、引擎側完全無感知。即使是服務下線，也會等到主服務的流量歸零才下線，這一層依賴於後設資料自己的閘道器，因此可以實現得更為輕量，比如可以透過切斷心跳的方式實現下線。

三、阿里雲資料湖統一許可權服務

實現資料湖統一許可權服務，首先要解決兩個問題：身份的問題、API 和引擎的訪問許可權一致性問題。

上圖為資料湖統一許可權架構圖。底層為湖上資料及後設資料，上層為資料湖統一鑑權服務，包括閘道器、使用者模型轉換、引擎的鑑權外掛體系和 DLF 資料訪問服務端鑑權。最上層是已經實現以及進行中的資料湖格式、開源引擎、數倉、資料湖構建平臺以及應用。

目前，我們提供了 ACL 和 RBAC 和 PBAC 三種許可權控制相結合的方式，ACL 和 Policy 互相補充。其中 ACL 模式依賴於授權的主體和客體，因此主客體必須存在，支援白名單授權。Policy 同時支援白名單和黑名單。

引擎側與 API 側如何實現統一的鑑權？

如果是使用者持有 AK 或在外部操作上使用管理平臺，則該層級全部透過 DLF SDK/API，在服務端後設資料訪問時會呼叫底下的鑑權引擎。

如果是 EMR 開源叢集，使用者透過 beeline 介面方式、透過 LDAP 認證，再透過 Spark ThriftServer 獲取後設資料。引擎會持有可信的身份，經過可信身份校驗後引擎可以獲取所有後設資料，再由引擎負責使用者模型的轉換，獲取使用者的操作與身份，代理使用者鑑權，將相應的鑑權請求發到服務端，呼叫同樣的服務端鑑權邏輯，最終實現引擎側和 API 層的統一鑑權。

四、資料湖後設資料與許可權展望

未來，資料湖後設資料與許可權將在統一、一致性和效能三個方面持續演進。

①統一後設資料、許可權、生態：雲上的後設資料目錄及集中式許可權管理將會成為標配，引擎、格式和各生態元件、開發平臺對於後設資料、許可權的支援具備一致性。此外，支援非結構化、機器學習場景後設資料模型自定義，這樣其他型別的後設資料也可透過自定義的方式接入到統一的後設資料體系中。

②後設資料加速：比如針對資料湖格式推出定製後設資料 API，為計算層提供給更多面向效能最佳化的方案。

③更靈活的許可權控制及更安全的資料訪問：使用者可以自定義角色許可權、操作許可權。另外資料儲存也可以實現加密，當然這一切都會管理在統一後設資料服務側。

問答

Q：connection 任務與業務任務解耦導致後設資料衝突的問題如何解決？

A：湖格式普遍提供了 MVCC 版本控制體系，透過多版本控制和最後的 commit 能夠解決該問題。

Q：關於半結構化和非結構化的後設資料管理是否有相關實踐經驗？

A：半結構的資料，主要利用 JSON 或一些複雜的資料結構來解決資料存取問題。非結構化的資料大多與機器學習場景相關，後續我們計劃將機器學習的模型對接到後設資料上。

Q：Hive Warehouse Connector 的原理是什麼？

A：Hive Warehouse Connector 是一層外部資料來源的定義。引擎可以透過 Connector 去連結外部資料來源。

Q：如何讓 Spark SQL 利用 Hive 本身的許可權？

A：目前開源社群暫無解決方案。但在阿里雲上，Hive 和 Spark SQL 有一致的鑑權。

Q：湖和倉的後設資料能在一個檢視裡檢視嗎？

A：目前，阿里雲上還未開發此功能，但在一些資料開發平臺上可以，比如 DataWorks。

Q：後設資料服務是每個租戶有獨立的服務例項還是大家共享後設資料服務？

A：是多個租戶共享後設資料服務，包括底層儲存使用同一個 table store 例項，只是儲存在不同的 table store 分割槽上。在同一個租戶內使用 catalog 做 namespace 隔離，每一個 catalog 可以有自己的許可權。

 

Q：DLF與資料湖格式如何配合的？資料多版本在哪一層實現？

A：資料湖格式更多的是以註冊或 meta 同步的方式將後設資料向DLF後設資料同步。資料多版本主要依賴底層的資料湖格式本身的能力。

Q： Hologres的實時指標，如果計算頻率很高，是否會導致壓力過大？

A：Hologres支援高併發的資料服務場景和資料分析場景，不同的場景會選擇透過行存或列存來解決問題。

Q：後設資料消費過程中，為什麼選擇了StructStreaming 而不是Flink？

A：兩者時效性相差不大，選擇StructStreaming主要基於技術棧考慮。

Q：後設資料效能方面是否有benchmark 的指標？

A：目前官網暫未透出。由於儲存有良好的scale能力及計算是無狀態的，因此理論上來說整體QPS也能夠很好的scale out。但是針對單個 table 分割槽數依然存在一定的上限。

Q：生命週期管理中，觸發解凍的因素是什麼？

A：目前還未實現自動觸發，僅支援使用者手動解凍。使用者使用之前，會提供一個入口供選擇是否進行解凍。

瞭解更多：

[1] 資料湖構建Data Lake Formation：

[2] 開源大資料平臺EMR：

[3] 資料湖揭秘—Delta Lake ： https://developer.aliyun.com/article/909818

[4] 資料湖構建—如何構建湖上統一的資料許可權：   https://developer.aliyun.com/article/918403

[5] 關於 Data Lake 的概念、架構與應用場景介紹： https://developer.aliyun.com/article/944650

[6] 資料湖架構及概念簡介：

https://developer.aliyun.com/article/1004847