金山云数据湖平台

金山云数据湖平台用的是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 或 Kafka 的 Broker 获取 Schema（列名、类型）。

2. 类型映射：将源数据库的类型（如 MySQL 的 VARCHAR, DATETIME）自动转换为 Hive 支持的类型（如 STRING, TIMESTAMP）。

3. 写入 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 过滤条件和 LIMIT 传给底层数据库，以减少网络传输。

2. 执行计划分发：对于分布式读，Hive 会启动多个 Map 任务。每个任务负责从源数据库的分片（如通过主键范围）并行抽取数据。

3. 格式转换：数据从源协议（如 JDBC 结果集或 Kafka 字节流）转换为内存中的行格式，供 Hive 后续计算。

写操作（以 INSERT INTO 为例）：

1. 写出器（Writer）：Hive 根据表定义的 OutputFormat 调用对应的写入方法。

2. 协议封装：

   • 数据库：通过 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 机制），而金山云给它配上了“驾驶室”和“自动巡航系统”（平台化功能）。