金山雲數據湖平台用的是Hive，可以添加數據源來連接關係型數據庫、MPP數據庫、對象存儲、Kafka，然後同步數據源的元數據，然後通過數據源來讀寫其中的數據（表、文件、消息topic），這些操作是如何實現的？

 

金山雲數據湖平台基於 Hive 構建，其實現“跨源連接、元數據同步、以及統一讀寫”的核心機制主要依賴於 Hive Storage Handlers（存儲處理器）擴展機制，以及金山雲自研的 元數據管理（Metadata Catalog） 服務。

以下是這些操作實現的技術細節：

1. 核心機制：Hive Storage Handler

Hive 本身只能處理 HDFS 上的結構化文件，但它提供了一個標準接口：HiveStorageHandler。通過這個接口，Hive 能夠將非 HDFS 存儲（如數據庫、消息隊列）偽裝成 Hive 的“外部表”。

  • 關係型數據庫/MPP (MySQL, Oracle, Doris 等)：使用

JdbcStorageHandler

  • 。它通過 JDBC 驅動連接目標數據庫，將 SQL 查詢下推（Push-down）到原庫執行，只取回結果。
  • 對象存儲 (KS3/S3)：使用

Hadoop FileSystem

  • 的擴展。將 KS3 路徑映射為 Hive 表的

LOCATION

  • ，利用

S3A

  • Kafka：使用

KafkaStorageHandler

  • 。它將 Kafka 的 Topic 映射為一張流式表，Hive 列對應消息的 Key、Value、Offset 和 Timestamp。

2. 元數據同步的實現原理

當你點擊“同步元數據”時，系統並不是在搬運數據，而是在進行 元數據映射（Mapping）：

  1. 掃描源信息：平台利用連接器（Connector）訪問目標庫的

information_schema

  1. 或 Kafka 的

Broker

  1. 類型映射：將源數據庫的類型（如 MySQL 的

VARCHAR

  1. ,

DATETIME

  1. ）自動轉換為 Hive 支持的類型（如

STRING

  1. ,

TIMESTAMP

  1. ）。
  2. 寫入 Hive Metastore：在數據湖的元數據庫中創建一條記錄，重點在於

STORED BY

示例 SQL（底層執行邏輯）：

CREATE EXTERNAL TABLE remote_mysql_table (id INT, name STRING)
STORED BY 'org.apache.hadoop.hive.jdbc.JdbcStorageHandler'
TBLPROPERTIES (
  "hive.sql.database.type" = "MYSQL",
  "hive.sql.jdbc.url" = "jdbc:mysql://...",
  "hive.sql.table" = "real_table_name"
);

3. 數據讀寫的底層鏈路

讀操作（以 SQL 查詢為例）：

  1. 解析與優化：Hive 解析你的 SQL。如果是查詢關係型數據庫，優化器會嘗試將

WHERE

  1. 過濾條件和

LIMIT

  1. 執行計劃分發：對於分佈式讀，Hive 會啓動多個 Map 任務。每個任務負責從源數據庫的分片（如通過主鍵範圍）並行抽取數據。
  2. 格式轉換：數據從源協議（如 JDBC 結果集或 Kafka 字節流）轉換為內存中的行格式，供 Hive 後續計算。

寫操作（以 INSERT INTO 為例）：

  1. 寫出器（Writer）：Hive 根據表定義的

OutputFormat

  1. 協議封裝：
  • 數據庫：通過 JDBC

Batch Insert

  • 對象存儲：直接將生成的 Parquet/ORC 文件流式寫入 KS3。
  • Kafka：將每一行數據按照指定的 SerDe（序列化/反序列化）工具轉換成 JSON 或 Avro，發送到 Kafka 的 Producer。

4. 架構總覽

組件

作用

Catalog 服務

存儲所有數據源的連接信息和權限策略。

Connector 插件庫

包含 JDBC、S3A、Kafka 等各種驅動，解決通信協議問題。

分佈式計算引擎

(如 Hive on Spark/Tez) 負責實際的數據搬運和轉換。

總結

金山雲通過 “統一元數據建模 + 插件化驅動” 的方式，消除了物理存儲的差異。對用户來説，所有外部系統都像是一個普通的 Hive 庫，用户只需編寫 SQL，底層的 Storage Handler

 

Catalog不是金山自研的，而是Hive自帶的服務吧？

 

你説得非常準確。Catalog 確實是 Hive 3.0+ 引入的標準組件和概念。

在回答你提到的“金山雲實現方式”時，需要區分 開源組件 和 雲平台封裝 兩個層面。我們可以從以下三個維度來拆解：

1. Hive 內部的 Catalog (開源標準)

正如你所指出的，Hive 3.0 之後在元數據層級上增加了 Catalog 層，其結構變為 Catalog -> Database -> Table。

  • 默認 Catalog：通常叫

hive

  • ，指向傳統的 Hive Metastore (HMS)，管理 HDFS 上的表。
  • 功能：它的設計初衷是為了解決多租户隔離，以及為“聯邦查詢”（Federated Querying）提供統一的命名空間。

2. 金山雲平台的“自研”或“增強”部分

雖然底層協議和存儲結構使用的是 Hive Catalog，但作為雲平台，金山雲通常會在 Hive 之上封裝一層管理服務。你看到的“添加數據源”界面，其實是雲平台對 Hive 元數據的自動化管理：

  • 自動化連接器（Connectors）： Hive 原生的

JdbcStorageHandler

  • 需要你手動寫很長的

CREATE TABLE

  • 語句並配置驅動路徑。金山雲平台通常會自研一套數據源註冊界面。當你輸入 MySQL 的 IP/端口/密碼時，後台會自動調用 Hive 的接口完成建表。
  • 元數據自動同步服務： Hive 本身並不具備“定時自動同步外部庫 Schema 變化”的能力。金山雲會運行一個自研的元數據掃描器（Scanner/Crawler），定時對比 MySQL/Kafka 中的 Schema 和 Hive Metastore 中的記錄，發現變化後自動更新

TBLPROPERTIES

  • 。
  • 多引擎適配： 金山雲通常會讓 Spark、Presto、Flink 和 Hive 共享這套 Catalog。這種“一處定義，到處訪問”的統一元數據中心功能，往往是在原生 HMS 基礎上做了高可用增強和接口封裝。

3. 為什麼要用 Catalog 這個詞？

在數據湖平台中，大家習慣稱呼這套東西為 Data Catalog（數據目錄）。

  • 狹義上：指 Hive 3.x 裏的那個 Catalog 數據庫對象。
  • 廣義上：指金山雲提供的“元數據管理控制枱”。它不僅存 Hive 表名，還存了數據血緣、敏感度等級、數據質量規則等 Hive 原生 Catalog 存不下的東西。

總結

Catalog 概念和核心代碼確實是 Hive 自帶的。金山雲的操作是利用了 Hive 的 Catalog 機制作為底層索引，並在其上開發了可視化界面、自動採集工具和跨引擎共享鏈路，從而實現了你看到的“點擊即可連接外部數據源”的功能。

你可以把它理解為：Hive 提供了“發動機”（Catalog 機制），而金山雲給它配上了“駕駛室”和“自動巡航系統”（平台化功能）。