考察点
这题考的是治理工具层的实操认知。面试官想确认你分得清技术/业务/操作元数据，知道数据目录的核心能力是「让人找得到、看得懂、敢用」，以及主流开源方案的架构差异。追问常落在血缘怎么采、DataHub 和 Atlas 怎么选。
参考答案
数据目录解决的真问题
数据团队一大隐性成本是「找数」：想知道有没有一张表存了某字段、这字段什么意思、出问题影响谁，全靠问人。数据目录（Data Catalog）就是把元数据组织成可搜索、可浏览、带上下文的产品，让找数从「问人」变「搜索」。
元数据三类划分
- 技术元数据：库表结构、字段类型、分区、文件位置、血缘关系。这类可以全自动采集。
- 业务元数据：表和字段的业务含义、指标口径、数据 owner、敏感级别。机器采不到，靠流程和激励让人填，这是目录建设最难的部分。
- 操作元数据：调度依赖、任务运行记录、访问热度、质量监控结果。从调度系统和审计日志来。
数据目录的核心能力
搜索（按表名/字段名/标签）、血缘图（表级+字段级，上游下游影响面）、owner 与文档（每张表有人负责、有说明）、标签与分类分级（挂敏感级别、业务域）、热度统计（谁在用、用多少，为下线决策提供依据）。这五块齐了才算目录，缺血缘的只能叫表清单。
DataHub vs Atlas 架构对比
| 维度 | DataHub | Apache Atlas |
|---|---|---|
| 出身 | LinkedIn 开源，社区活跃 | Hortonworks 系，Hadoop 生态老牌 |
| 架构 | 元数据图模型，存储用 MySQL/ES/Kafka，push/pull 双模式 ingestion | 基于 HBase/Solr/Kafka，靠 Hive hook 等钩子推送 |
| 血缘 | 支持表级和字段级，UI 好 | 表级血缘成熟，字段级看 hook 支持 |
| 生态 | Spark/Flink/Airflow/dbt/Looker 等连接器全 | 深度绑定 Hive/HBase/Kafka/Storm，Hadoop 栈内体验好 |
| 扩展性 | 元数据模型是代码定义的 aspect，扩展要写代码 | 类型系统可自定义实体类型，配置化程度高 |
经验结论：新一代多引擎栈（Spark/Flink/Trino/dbt 混用）选 DataHub，连接器多、UI 现代、社区迭代快；纯 Hadoop 老栈、已经在用 Ranger（两者天然一家，权限标签联动）选 Atlas 成本低。
落地的几个现实问题
一是采集要覆盖全链路：Hive Metastore 同步、Spark/Flink 任务 SQL 解析出血缘、BI 报表的血缘（很多团队漏了这层，导致「表到报表」的链路断了）。二是业务元数据的冷启动：强制核心表 owner 补文档，把「无 owner 无文档」的表列入治理看板晾晒，比行政命令有效。三是血缘准确性要度量：抽样核对解析出的血缘和实际调度依赖，SQL 里动态拼表名、临时表中转这类场景解析器经常漏，要靠调度依赖兜底。四是目录建了没人用的死穴：把目录搜索入口嵌进 BI 和取数工具，让人在日常工作流里顺手用，而不是多开一个系统。
可能的追问
- 字段级血缘怎么做？ 答解析 SQL 的 AST，跟踪 select 表达式里字段的映射（含函数加工），工具如 SQLLineage、OpenLineage；复杂场景（UDF、动态 SQL）解析不了要降级为表级血缘。
- 元数据变更怎么实时同步？ 答 DataHub 用 Kafka 做元数据变更事件流，hook 或轮询把变更推成事件，消费者更新图存储；Atlas 类似，靠 hook 推 Kafka 再入 HBase。
- OpenLineage 了解吗？ 答它是血缘采集的开放标准，Marquez 是参考实现，DataHub 等都在兼容，趋势是各家引擎直接吐标准血缘事件，替代各家自研 hook。