4. Data Catalog元数据摄取管道

元数据摄取管道是Data Catalog的“进料系统”。如果采集不完整、不及时或版本混乱，后续的搜索、血缘、权限治理都会建立在错误的数据之上。本节围绕Hive、MySQL、Kafka、对象存储四类典型数据源，说明如何构建一条可自动化运行、支持增量同步、并能处理冲突的元数据摄取链路。

一、四类数据源的元数据特征与采集方式

不同数据源暴露元数据的方式差异很大，采集器必须按源类型选择接口，而不是用统一方式硬拉。

• Hive：元数据集中在Hive Metastore（HMS），可通过HMS Thrift API或直接读取其后端RDBMS获取库、表、字段、分区、存储格式、SerDe等信息。表结构变更通常由DDL触发，适合按事件或按快照比对采集。
• MySQL：通过information_schema中的TABLES、COLUMNS、STATISTICS等视图获取表、字段、类型、索引、注释。MySQL不提供元数据变更事件，需要周期性轮询并用版本字段或哈希比对识别变化。
• Kafka：元数据来自Broker的Topic配置、分区副本分布、消费组位点，以及Schema Registry中的Avro/Protobuf/JSON Schema。Topic和Schema变更可通过AdminClient与Registry API获取，Schema版本天然带递增ID，适合增量拉取。
• 对象存储：S3、OSS、HDFS等本身只有对象键、大小、ETag、最后修改时间，没有表结构。通常结合Hive外部表、Iceberg/Hudi表格式或路径约定，把“目录+文件”映射为逻辑数据集，再抽取分区与Schema。

采集器应把每个源抽象为统一的“元数据实体”：库/命名空间、表/Topic/数据集、字段/Schema、分区、血缘关系。统一实体模型是后续增量比对和冲突解决的基础。

二、增量同步：从全量快照到变化捕获

全量拉取在源规模大时既慢又浪费。增量同步的核心是“只处理变化”，常见有三种实现路径。

1. 版本号/时间戳水位法。采集器为每个源维护一个水位（watermark），例如MySQL记录上次最大UPDATE_TIME，Kafka记录上次Schema ID，HMS记录上次事件ID。每次只拉取水位之后的数据。注意MySQL的UPDATE_TIME在部分引擎或批量DDL下可能不更新，因此需要配合内容哈希兜底。

2. 内容哈希比对法。对每个实体计算规范化后的哈希，例如把表名、字段名、类型、注释按固定顺序拼接后取SHA-256。采集时只比较哈希，不同则视为变更。这种方式不依赖源是否提供可靠时间戳，但需要保存上一版哈希，适合Hive和对象存储。

3. 事件驱动法。HMS可通过事件监听或审计日志捕获DDL；Kafka Schema Registry提供版本递增；Iceberg/Hudi的元数据文件本身带快照ID。事件驱动延迟最低，但需要处理事件丢失和重复投递，通常用“事件+定期全量校验”双保险。

# 增量采集水位示例（伪配置）
source: mysql_prod
watermark_field: UPDATE_TIME
last_watermark: "2025-03-01 10:00:00"
hash_fields: [table_schema, table_name, column_name, data_type, column_comment]
batch_size: 500
on_conflict: priority_then_timestamp

三、冲突解决：同一实体被多个源描述时怎么办

冲突在真实环境中很常见：Hive表有字段注释，MySQL同名表也有注释，两者不一致；Kafka Topic的Schema版本与下游表结构不一致；对象存储路径被两个团队登记为不同数据集。冲突解决不是简单覆盖，而是要有明确规则和可追溯记录。

• 来源优先级：按业务权威性排序，例如HMS作为数仓表结构的权威源，MySQL作为业务库权威源，Kafka Registry作为消息Schema权威源。同一属性只由权威源写入，其他源作为补充。
• 时间戳优先：当两个源优先级相同，取last_modified更新的一方，但要求时钟可信，否则改用采集时间。
• 字段级合并：表级冲突可拆到字段级。例如表描述取HMS，字段注释取MySQL，分区信息取对象存储扫描结果，避免整表覆盖。
• 人工审核队列：对无法自动判定的冲突（如类型不一致、字段删除），写入待审核表，附带两个来源的快照和差异，由数据Owner确认后再合并。

四、调度与可观测性

摄取管道通常按“分钟级事件 + 小时级轮询 + 每日全量校验”三层调度。事件层处理HMS DDL和Schema变更；轮询层处理MySQL和对象存储；每日全量校验用于发现漏采和漂移。关键指标包括：各源采集延迟、增量实体数、冲突数、审核队列积压、写入失败率。当采集延迟超过阈值或冲突数突增时，应触发告警，而不是等下游发现表结构对不上才排查。

把以上环节串起来，一条可用的摄取管道应做到：源适配器可插拔、统一模型可扩展、增量水位可恢复、冲突规则可配置、变更历史可追溯。这样Data Catalog才能持续反映真实数据资产，而不是一次性的静态快照。