一、騰訊大數據處理套件

TBDS的全稱是騰訊大數據處理套件，它是一個基于 Hadoop 生態以及 MPP 生態的大數據平臺。我們主要有以下的四種應用場景：大數據的批流的處理，云原生的數據湖，湖倉一體，以及國產化的數據中臺。

下面是我們的一些客戶，大家可以看到種類非常多，有金融類的、產業類的，還有傳媒以及政府。不同用戶的業務場景差別非常大，數據規模、集群規模的差別也非常大。他們對于大數據如何使用，對于數據服務的要求也非常的不一樣。

下圖是金融場景的一個典型的技術方案：業務數據通過實時鏈路和離線鏈路進入大數據平臺。在大數據平臺中有兩種類型的集群。第一類是事件中心集群，也可以叫實時計算中心集群；經過 Kafka、Flink數據處理之后再進入 Hive和 Elasticsearch，然后對外圍的系統提供數據服務。另一類是離線計算集群，主要負責數據的批處理。

整個大數據平臺是基于 Hadoop生態搭建的；得益于 Hadoop生態的繁榮，基本上每種特定的需求都可以找到合適的計算存儲組件來滿足。

除了 Hadoop，我們還提供基于 MPP的技術方案，它對于中小體量的客戶更加合適。基于 MPP的來搭建數據平臺，實時鏈路以及離線鏈路的數據都進入 MPP，然后來統一加工處理，最后也是由 MPP統一對外提供數據服務。

Hadoop還是 MPP？這兩個生態之間的對比，其實業界已經討論非常多了。隨著各自的發展，我相信相關的討論也會一直持續下去。例如對 Iceberg這樣的數據湖表格式的支持，目前無論是 Spark還是 ClickHouse，都在做軍備競賽，現在的結論過兩三個月可能就過時了。

但是有一點是肯定的，沒有一個單獨的生態，能夠解決所有用戶的所有問題。這種情況會持續很長的一段時間。即便現在已經是 2024 年了，很多客戶他們的數據平臺已經持續建設了很長的一段時間，多種集群、多種類型、多種版本的大數據系統，它們的共存是我們會經常遇到的一個問題。所以必然我們會遇到這么一個問題：如何來處理數據孤島--不同的系統之間的數據該如何互通。

二、如何處理數據孤島

我們都知道，如果是要做數據遷移、做 ETL，是一件成本非常高的事情。有的時候可以接受，但有的時候是很難去承擔這樣的成本的。

目前其實已經有一個可以跑通的技術方案，就是利用 Hive Metastore 作為統一的元數據中心。在圖的右邊是 MPP 的服務，在使用外表的模式下，它們可以使用 Hive Metastore 作為數據來源。左邊是 Hadoop 生態下的計算引擎，它們基本上都會默認使用 Hive Metastore 作為它們的元數據服務。

在這樣一個統一的元數據服務的情況下，再加上支持如 Iceberg 這樣的表格式，提供統一的元數據的格式，基本上問題可以得到解決。這也是目前很多私有化場景下湖倉一體、湖上建倉的技術基礎。

在上面的方案中，Hive Metastore 是絕對的核心，然而 Hive Metastore 本身還是有很多的局限性的。首先 Hive Metastore 是一個單純的元數據技術和服務，基本上沒有任何的治理能力。其次它的元數據模型完全是關系型的數據庫模型，對于像 Message、Topic、文件，以及 AI 模型這類半結構化、非結構化的數據基本是不匹配的。而且它的服務設計也沒有考慮到要承擔如此重要的任務，所以有很明顯的單點瓶頸。

在一個多集群的場景下面，它的方案會非常的復雜，但至少它還是可以跑的。那么數據孤島看上去是有方案了，但是權限怎么辦？Hadoop，還有 Hive Metastore，它本身也有一套比較簡陋的權限模型，但是基本沒有計算引擎來使用它，更別說 MPP 引擎了。

因此，如果沒有一個統一的權限中心，單個資源的授權就需要在每一個子系統上面再重復地授權一遍，步驟非常繁瑣，并且很容易出錯。在 Hadoop生態下，Ranger是一個權限中心，它的機制是有點像 OPA （open policy agent），整個權限策略被 Manager統一的管理，然后各個計算引擎使用各自的 Plugin 進行授權。但是它的權限模型存在一定的問題。最重要的問題是它頂層設計的概念并不是以數據來劃分的，而是以服務組件來劃分的，不同的組件，如果要訪問同樣的數據，那么需要重復的授權，而且這只是當前 Hadoop生態的一個方案，MPP生態基本是沒有權限管理。

我們其實也看到主流的云廠商基本提供了相關的產品來解決數據孤島以及權限孤島的問題。這樣的解決方案一般都會被包裝成為數據湖產品的一部分，例如 AWS的 Lake Formation，Databricks的 Unity Catalog，此外 Microsoft和 Google也有自己的產品。但是對于這樣的商業公司所主導的產品，他們也有自己的局限性。

首先是對于計算引擎的支持比較少，也缺少私有云、尤其是非云化環境的部署方案。并且它們對于云廠商本身的依賴程度非常深。

因此，我們需要一個更加統一、更加清晰、同時也更加開放的產品，來更好地解決數據孤島以及權限孤島的問題。騰訊云和Datastrato一起，基于 Gravitino 的開源社區來合作，希望能夠解決這樣的問題。

三、Gravitino 能做什么

我來簡單的介紹一下 Gravitino，它是一個使用 Apache License v2.0許可證的開源統一元數據服務，全面支持公有云、私有云以及非云環境的部署。它可以為多種的數據源提供統一的元數據視圖，并且提供了標準的 SDK，可以開放的支持多種計算引擎的接入。

此外很重要的一點是，Gravitino提供了一個統一的、開放的權限管控機制。統一指的是統一的授權：對于所有的數據源，可以使用統一的模型和流程來進行授權；開放指的是開放的接入：對于數據源可以使對于各種計算引擎包括 MPP，以及存儲，都能接入這樣的權限模型，完成權限的管控。

四、Gravitino 的統一權限模型

對于數據系統來說，它的權限設計至關重要。但是現在的大部分企業的數據系統有很多種類型，有 MPP類型，也有一些在線的例如 MySQL、PostgreSQL這樣的數據庫，以及 Hadoop上的 HDFS、Spark、Hive等的大數據組件。這些的數據系統帶來了異構的數據棧，對于目前的一些權限的設計，就很難有統一的權限入口來做統一的管理。

對于企業來說，這樣的情況對于它構建自己的數據生態帶來了很大的不便。為此，在計算機系統里有這樣一句話：沒有任何問題不是可以通過加一層來解決的。在去年的時候，我們公司開源了 Gravitino這樣一款元數據管理軟件，用于解決這種跨數據棧的元數據管理。我為大家主要講一下 Gravitino的權限模型。

首先我介紹一下權限模型，業界比較常見的權限模型有 ABAC、RBAC等等，但是目前還是以 RBAC為主。Gravitino在這塊兒也是采用了 RBAC的權限模型。

首先我們可以看出這張圖里有幾個概念，第一個概念就是 Metalake。第二個是 Role，第三個是 User。

對于 Metalake 來說，我們可以把它看作是一個組織；一般來說，一個企業就是一個 Metalake，它只有一個組織。在 Metalkae 下面會掛載 Role 以及 User。

Role主要是我們權限模型中用來管理權限的核心概念，它會綁定具體的一些權限。Role是實體的具體的某些權限的集合。在實際的使用的過程中會把 Role授權給 User，Role和 User是多對多的關系，可以去進行比較靈活的綁定。

講完了權限模型，我介紹一下統一權限的系統架構。Gravitino的權限大概可以分為兩部分：第一部分是，它對于自身會有內建的鑒權，主要負責對于自身管理的一部分的元數據進行鑒權，比如說 Metalake 的一些鑒權，比如說自有的一些數據實體的鑒權。同時它還提供了強大的插件機制，用來對接一些外部系統的權限。

目前權限插件會有四類，第一類是 Native Catalog的權限插件，主要用于大數據生態的權限鑒權，這主要是考慮了一些用戶，他們不想引入類似于 Ranger這種額外的大數據權限管理組件，進行簡便的一些數據權限的管理。

第二類是正就像前面徐瀟所說的，在大數據體系當中，Ranger是一個比較主流的權限管理系統。這里會提供 Ranger的 Catalog的權限鑒權的插件，然后通過它來去對大數據的體系進行整體的權限管控。

第三類是對于 MPP、數據庫這類系統，它們一般會提供 JDBC 接口。我們會對這樣的系統來提供 JDBC Catalog鑒權的插件，來對這樣的系統進行權限的管控。

第四類是對于很多的云上的生態，比如 AWS、Azure，它們會有像 IAM這樣的權限管理系統。對于這種我們會提供云的 Cloud Catalog的鑒權插件。

整體的來說，Gravitino是通過自建的鑒權機制，以及結合豐富的外部鑒權插件機制，來實現對權限機制的統一。

在這個過程中 Gravitino對外暴露 RESTful的 API接口，然后將用戶的各種權限設置的請求，通過自身的邏輯以及模型的轉換，通過插件透傳給下游的各種不同的數據生態，從而達到讓 Gravitino成為權限入口的效果。

接下來可以看這張圖，來結合具體的例子給大家分享 Gravitino的授權過程。

可以看到，左邊是認證 Server，會支持三種認證服務。第一種是 OAuth的認證，第二種是 Kerberos認證，Kerberos認證在大數據的生態用得會比較多一點；第三種是 IAM 認證，對于云的系統 IAM會使用得比較多。

整體會提供對用戶的認證，然后是數據授權的過程。Gravitino 在參與的過程中會有三個角色：第一個角色是Service Admin，它的職責其實比較簡單，就是創建 Metalake；第二個角色是 MetalakeAdmin，主要對 Metalake下面的 Role的創建和管理，以及對各種權限的 Role的創建，并把這些 Role和具體的 User進行綁定。第三個角色是普通 User，他可能是新加入的 User，負責具體的數據實體的創建，例如創建 Catalog、數據庫、表，然后讀取這些表。

在這個過程中，我們可以簡單來看一下簡單的創建 Catalog和之后創建表的過程。第一步是 Service Admin會去創建 Metalake，之后 Metalake admin會去創建 Role，然后創建需要具體使用的 User，然后去創建 Catalog，然后開通了Catalog的 Manager Role，去把 Catalog Manager Role賦予給 new user。New user就可以具體創建 Catalog，例如可以創建 Hive Catalog，創建 MySQL Catalog。這個時候 Metalake admin可以去創建 Hive的 Schema Manager，把Schema Manager授予給 new user，然后 new user就可以創建 Schema。之后 Metalake admin可以創建Hive Table的 Manager role，再把 Hive Table的 Manager role授予給 new user，就可以具體去去創建 Hive Table。

對于 MySQL也是同樣的，會去創建Catalog、Table。當 Hive catalog 以及 MySQLCatalog和 HiveTable都創建完之后，具體的 new user就可以讀取這兩個表。