3、数据源接入与元数据管理：特征数据源的分类（离线/实时），元数据采集与注册，数据血缘关系的建立

数据源接入，说白了就是搞清楚你的特征到底从哪来。我见过不少团队，特征上线跑得飞快，一出问题就抓瞎——不知道数据源头在哪，不知道中间被谁改过，不知道下游哪些模型在用。嗯，这就是元数据管理和血缘关系没做好。

这一章，我们就来聊聊怎么把数据源管清楚。我会从数据源分类讲起，再到元数据怎么采、怎么注册，最后把血缘关系串起来。

3.1 特征数据源的分类：离线与实时

特征数据源，按时效性分两大类：离线数据源和实时数据源。这两者在接入方式、存储选型、质量监控策略上完全不同。

维度	离线数据源	实时数据源
典型存储	Hive、HDFS、离线数仓（ODS/DWD层）	Kafka、Pulsar、Redis、HBase
更新频率	T+1、小时级	秒级、毫秒级
数据量级	TB~PB级，全量或大分区	MB~GB级，流式增量
接入方式	批处理调度（Spark、MapReduce）	流处理引擎（Flink、Spark Streaming）
质量监控重点	数据完整性、分区空值、跨天一致性	延迟、乱序、吞吐量、数据丢失

我个人习惯，在搭建监控体系之前，先画一张数据源全景图。把每个特征对应的离线表和实时Topic都列出来，标注清楚数据源类型、负责人、存储路径。这一步做扎实了，后面元数据采集才不会漏。

3.2 元数据采集与注册

元数据，就是关于数据的数据。特征元数据至少包含：特征名称、所属实体、数据类型、数据源位置、更新频率、业务含义、负责人。你想想看，如果没有这些信息，一个特征出了问题，你连找谁问都不知道。

我在项目中遇到过，一个团队用Excel管理特征元数据，结果版本混乱，同一个特征在不同模型里含义都不一样。后来我们统一用Atlas + 自研元数据服务，才把这事理顺。

3.2.1 元数据采集的两种方式

• 主动采集（Pull模式）：定时扫描Hive MetaStore、Kafka Topic列表、Redis Key模式，自动提取元数据。适合大规模、自动化场景。
• 被动注册（Push模式）：特征开发者在平台上手动填写或通过API注册特征元数据。适合需要人工审核、补充业务语义的场景。

我建议两种方式结合：主动采集兜底，保证元数据不遗漏；被动注册补充业务信息，比如特征含义、使用场景、负责人。

3.2.2 元数据注册的核心字段

字段	说明	示例
feature_id	全局唯一特征ID	f_001_user_age
feature_name	特征名称	user_age
entity_type	所属实体	user
data_type	数据类型	int
source_type	数据源类型	offline / realtime
source_path	数据源位置	hive://dw.user_profile/age / kafka://topic_user_attr
update_frequency	更新频率	daily / hourly / realtime
owner	负责人	zhangsan@company.com
description	业务含义	用户注册时的年龄

3.3 数据血缘关系的建立

数据血缘，就是特征从源头到最终使用的完整链路。比如：原始日志 → ETL清洗 → 离线特征表 → 特征拼接 → 模型训练。一旦特征质量出问题，血缘能帮你快速定位是哪个环节出了岔子。

我曾经因为没建血缘，排查一个特征异常花了三天。后来发现是上游ETL改了字段名，下游没同步。如果当时有血缘图，十分钟就能定位。

3.3.1 血缘的粒度

• 表级血缘：特征表依赖哪些上游表，被哪些下游任务消费。适合宏观排查。
• 字段级血缘：特征字段从上游哪个字段来，经过什么转换。适合精准定位。

我个人习惯，字段级血缘必须做。因为很多特征异常是字段映射错误导致的，表级血缘根本看不出来。

3.3.2 血缘采集的实现方式

常见的做法是解析SQL和ETL脚本，提取输入输出关系。比如Spark SQL的QueryExecution、Hive的LineageInfo、Flink的Table API都能提供血缘信息。

-- 示例：解析SQL血缘
-- 输入表：dw.user_profile
-- 输出表：feature.user_age
-- 字段映射：dw.user_profile.age -> feature.user_age.age_value

INSERT OVERWRITE TABLE feature.user_age
SELECT user_id, age AS age_value
FROM dw.user_profile
WHERE dt = '${bizdate}'

采集到的血缘数据，可以存入图数据库（如Neo4j）或关系型数据库，方便查询和可视化。

3.3.3 血缘可视化

下面这张图，展示了一个典型特征的血缘链路。从原始日志到最终模型，每个环节都清晰可见。

3.4 数据源接入与元数据管理的落地要点

说了这么多，总结几个我在实战中踩过的坑和沉淀下来的经验：

• 数据源接入必须标准化：统一接入协议、统一命名规范、统一监控埋点。不要给每个数据源单独写接入代码，否则后期维护成本爆炸。
• 元数据是监控的基础：没有元数据，质量监控就是盲人摸象。特征名、数据源、负责人、更新频率，这四个字段必须100%覆盖。
• 血缘要建到字段级：表级血缘只能告诉你“谁依赖谁”，字段级血缘才能告诉你“哪个字段出了问题”。
• 自动化是王道：元数据采集、血缘解析、质量监控，能自动化的就不要手动。手动操作越多，遗漏和错误越多。