作者 | 勇幸，小米計算平台負責人
導讀：業界一直希望統一元數據，從而實現多産品間的一致體驗：無論是數據開發、數據消費還是數據治理，所有用戶都能基于一套元數據體系，采用相同的資源描述方式，這無疑能極大地提升用戶體驗。然而真正做到 “多雲多數據源多引擎” 下的元數據統一，是非常難的，首先面臨的是組織障礙，很多大廠也並未真正實現 “資源坐標統一、權限統一、資産一體化”，這些問題本身就很有挑戰。得益于開源與組織時機，小米基于 HMS 與 Metacat 實現了元數據的統一，也借此實現了將 7 個數據平台統一爲 1 個平台。隨著湖倉與 AI 的發展，統一元數據面臨新的挑戰，尤其是 Data AI 資産一體化，Metacat 很難滿足需要，小米希望借助 Gravitino 替代 HMS 與 Metacat，真正實現元數據的多場景統一，從而獲得元數據在湖倉與 AI 方面的持續叠代。
背景和概要介紹
小米公司是一家以智能手機、智能硬件和電動汽車爲核心的消費電子和智能制造公司，通過物聯網平台相互連接。截至 2023 年，根據 Canalys 的數據，小米在全球智能手機市場中排名前三，並連續第五年被列爲《財富》全球 500 強企業。
小米雲計算平台團隊致力于爲小米業務提供可靠和安全的數據計算與處理能力。我們積極參與許多開源項目，涵蓋存儲、計算、資源調度、消息隊列、數據湖等領域。通過深耕這些先進技術，團隊取得了重大成就，包括入圍小米百萬美金技術獎決賽。
Gravitino [1] 是一個高性能、地理分布式的聯合元數據湖開源項目，管理不同來源、類型和區域的元數據，支持 Hive，Iceberg，MySQL，Fileset，Messaging 等類型的數據目錄（不斷增加中），爲用戶提供 Data 和 AI 資産的統一元數據訪問。
本文重點介紹小米使用 Gravitino 的情況，爲未來的工作規劃與解決方案提供指引。如下所示，有三個關鍵點，期待與 Gravitino 共同成長並爲業務提供更好的數據資産管理能力：
統一元數據的管理集成 Data 和 AI 資産管理統一用戶權限管理1. 統一元數據的管理
隨著多區域或多雲部署的引入，數據孤島問題變得更加突出。在不同地區或雲服務提供商之間維護數據的統一視圖變得具有挑戰性。這對于小米來說確實如此。Gravitino 爲這些挑戰提供了解決方案 [2]，並幫助打破數據孤島。它旨在解決多雲架構下的數據管理、治理和分析問題。
Gravitino 在小米數據平台中的位置
下圖中 Gravitino 具有以下我們需要的特性（以綠色和黃色突出顯示）：
統一的元數據湖：作爲一個統一的數據目錄，它支持多種數據源、計算引擎和數據平台，用于數據開發、管理和治理。實時性和一致性：實時獲取元數據以確保 SSOT（單一真相來源）。動態注冊：支持在使用中動態添加 / 修改數據目錄，無需重新啓動服務，這使得維護和升級比以前容易得多。多引擎支持：不僅支持數據引擎，如 Trino、Apache Spark、Apache Flink（開發中），還支持 AI/ML 框架，如 Tensorflow、PyTorch和 Ray*。多存儲支持 *：支持 Data 和 AI 特定領域的存儲，包括 HDFS/Hive、Iceberg、RDBMS，以及 NAS/CPFS、JuiceFS 等。生態友好 *：支持使用外部 Apache Ranger 進行權限管理，外部事件總線進行審計和通知，以及外部的 Schema Registry 進行消息目錄的管理。注：* 功能仍在積極開發中
統一元數據湖，統一管理
隨著數據源類型的日益豐富，計算引擎如 Trino、Spark 和 Flink 需要爲每個引擎維護一個很長的數據源目錄列表。這引入了許多重複和複雜的維護工作。
爲了在多個數據源和計算引擎之間建立聯系，通常期望在一個地方管理所有種類的數據目錄，然後使用統一的服務來公開這些元數據。在這種情況下，Gravitino 非常有用，因爲它提供了一個統一的元數據湖，標准化了數據目錄操作，並統一了所有元數據管理和治理。
用戶場景
用戶可以使用三級坐標：catalog.schema.entity 來描述所有數據，並用于數據集成、聯合查詢等。令人興奮的是，引擎不再需要維護複雜和繁瑣的數據目錄，這將 O(M*N) 的複雜度簡化爲 O(M+N)。
注：M 代表引擎的數量，N 代表數據源的數量。
此外，我們可以使用一種簡單統一的語言來進行數據集成和聯合查詢:
Apache Spark: 使用 Gravitino Spark 連接器從 Apache Hive 寫入 Apache Doris
INSERT INTO doris_cluster_a.doris_db.doris_tableSELECT goods_id, goods_name, priceFROM hive_cluster_a.hive_db.hive_tableTrino: 使用 Gravitino Trino 連接器在 Hive 和 Apache Iceberg 之間進行查詢。
SELECT *FROM hive_cluster_b.hive_db.hive_table aJOIN iceberg_cluster_b.iceberg_db.iceberg_table bON a.name = b.name2. 集成 Data 和 AI 資産管理
在大數據領域，我們通過數據血緣、訪問度量和生命周期管理，對表格（或者結構化）數據的管理有了長足的發展。然而，在 AI 領域，非表格數據一直是數據管理和治理最具挑戰性的方面，包括 HDFS 文件、NAS 文件和其它格式。
AI 資産管理的挑戰
在機器學習領域，讀寫文件的過程非常靈活。用戶可以使用各種格式，如 Thrift-Sequence、Thrift-Parquet、Parquet、TFRecord、JSON、文本等。此外，他們還可以利用多種編程語言，包括 Scala、SQL、Python 等。爲了管理我們的 AI 資産，我們需要考慮到這些多樣化的使用，並確保適應性和兼容性。
與表格數據管理類似，非表格數據也需要適應各種引擎和存儲，包括像 PyTorch 和 TensorFlow 這樣的框架，以及各種存儲接口，如文件集的 FileSystem、實例磁盤的 FUSE、容器存儲的 CSI 等。
非表格數據管理架構
我們的目標是通過利用 Gravitino 建立 AI 資産管理能力，其核心技術在下圖中概述。
非表格數據目錄管理：實現 AI 資産的審計，並確保文件路徑規範的保證；文件接口支持：確保與各種文件接口的無縫兼容性；Hadoop 文件系統：通過 GVFS（Gravitino 虛擬文件系統）實現與 Hadoop 文件系統的兼容性。CSI 驅動程序：支持容器存儲內文件的讀寫。FUSE 驅動程序：使物理機器磁盤上的文件讀寫成爲可能。AI 資産生命周期管理：爲非表格數據實現 TTL（Time-to-Live，生存時間）管理。
用戶場景
我們希望用戶從原始方式到新方法的遷移過程將是直接和無縫的。實際上，過渡只涉及兩個步驟：
在 Gravitino 基礎數據平台上創建文件集 Catalog 並配置 TTL；
用新方式（gvfs:// 路徑）替換原始文件路徑。
以 Spark 讀取 HDFS 文件爲例：
// 1.Structured data - Parquetval inputPath = "hdfs://cluster_a/database/table/date=20240309"val df = spark.read.parquet(inputPath).select()...val outputPath = "hdfs://cluster_a/database/table/date=20240309/hour=00"df.write().format("parquet").mode(SaveMode.Overwrite).save(outputPath)// 2.Semi-structured data - JsoninputPath = "hdfs://cluster_a/database/table/date=20240309_${date-7}/xxx.json"val fileRDD = sc.read.json(inputPath)// 3.Unstructured data - Textval inputPath = "hdfs://cluster_a/database/table/date=20240309_12"val fileRDD = sc.read.text(inputPath)通過利用 Gravitino，我們創建了一個指向原始 HDFS 的文件集“myfileset”，然後我們可以將原始的 hdfs://xxx 替換爲新的 gvfs://fileset/xxx 方法，爲用戶提供一種無縫直觀的升級方式。用戶將不再需要關心實際的存儲位置。
// 1.Structured data - Parquetval inputPath = "gvfs://fileset/myfileset/database/table/date=20240309"val df = spark.read.parquet(inputPath).select()...val outputPath = "gvfs://fileset/myfileset/database/table/date=20240309/hour=00"df.write().format("parquet").mode(SaveMode.Overwrite).save(outputPath)// 2.Semi-structured data - JsoninputPath = "gvfs://fileset/myfileset/database/table/date=20240309_${date-7}/xxx.json"val fileRDD = sc.read.json(inputPath)// 3.Unstructured data - Textval inputPath = "gvfs://fileset/myfileset/database/table/date=20240309_12")val fileRDD = sc.read.text(inputPath)如前所述，文件讀寫表現出很大的靈活性，它也適應了多樣化的引擎。這裏就不舉更多例子了，總體原則仍然是用戶應該能夠以最小的修改來管理和治理非表格數據。
AI 資産管理內的許多挑戰需要探索和開發工作。它包括指定文件路徑的深度和日期，支持數據共享，探索基于數據湖如 Iceberg 的非表格數據讀寫解決方案。這些將是我們近期的關注重點。
3. 統一用戶權限管理
元數據和用戶權限信息如此緊密相關，將它們放在一起管理是再好不過的。元數據服務還需要整合與用戶權限相關能力，以驗證資源操作。我們期望通過利用 Gravitino 在我們的數據平台上實現這一點。
多系統集成的統一認證挑戰
爲了爲用戶提供無縫的數據開發體驗，數據平台通常需要與各種存儲和計算系統集成。然而，這種集成經常導致管理多個系統和賬戶的挑戰。
用戶需要在不同系統中使用不同賬戶進行身份驗證，如 HDFS（Kerberos）、Doris（用戶名 / 密碼）和 Talos（AK/SK - 小米 IAM 賬戶）。這種分散的身份驗證和授權流程顯著減慢甚至可能阻礙開發。
爲了解決這個問題，簡化不同賬戶系統的複雜性並建立統一的授權框架是構建一站式數據開發平台的關鍵一步，以提高數據開發的效率。
基于工作空間的統一用戶權限
小米的數據平台圍繞工作空間概念設計，並采用 RBAC（基于角色的訪問控制）權限模型。Gravitino 允許我們在工作空間內生成所謂的“小賬號”（實際資源賬戶，如 HDFS-Kerberos），有效地將用戶與 Kerberos、用戶名 / 密碼和 IAM/AKSK 賬戶的複雜性隔離開來。以下是這種設置的關鍵組件：
工作空間: 工作空間是數據平台內最小的操作單元，包含所有相關資源。角色：工作空間內的身份，如管理員、開發人員和訪客。每個角色被授予訪問工作空間資源的不同權限。資源：工作空間內的資源，如 catalog.database.table，得益于統一元數據，資源可以抽象爲三級坐標。權限：權限決定了用戶在工作空間內操作資源的控制水平，包括管理員、寫入和讀取。Token：用于識別工作空間內個體的唯一 ID。身份驗證：API 操作使用令牌進行身份驗證，而 IAM 身份在登錄後通過 UI 操作傳遞。授權：通過 Apache Ranger 管理，授予已認證的工作空間角色必要的權限。小賬號：每個工作空間都有一套專用的代理賬戶來訪問資源，如 HDFS（Kerberos）或 Apache Doris（用戶名 / 密碼）。當引擎訪問底層資源時，它無縫地使用相應的小賬號身份驗證進行每個資源的操作。然而，整個過程對用戶來說是透明的，用戶只需要關注管理工作空間權限（通過利用 Gravitino 等同于資源權限）。用戶場景
下圖展示了用戶在我們的數據平台上創建和訪問資源的簡要過程：
所有用戶只知道工作空間身份和工作空間權限。在創建工作空間時，會自動創建一套工作空間代理小賬號。每當在工作空間內創建或導入資源時，相應的代理小賬號將被授權必要的資源權限。當用戶嘗試讀取或寫入資源時，系統會驗證他們的工作空間權限。如果工作空間權限檢查成功，引擎將使用小賬號對資源執行所需的讀取或寫入操作。
總 結
在這篇博客中，我們展示了小米正在使用 Gravitino 完成的三個重要場景——大部分關鍵工作已經完成，剩余的正在進行中並取得了良好進展。我們對所有上述場景在小米的成功落地充滿信心，以更好地支持業務進行數據資産管理，同時我們很高興成爲 Gravitino 社區的一部分，共同創造統一元數據湖的潛在事實標准。
參考鏈接：
[1] https://github.com/datastrato/gravitino/
[2] https://datastrato.ai/blog/gravitino-unified-metadata-lake/
