第4章 数据治理基础知识面试
数据治理是BI工程师的底层能力护城河。面试中高频考察点包括：数据治理定义与分层、元数据管理工具选型、数据血缘构建与断点修复。本章通过3个问答卡片+1个真实项目案例，帮你快速构建结构化应答体系。
问答卡片 1：数据治理概念与层次
面试问题：请解释数据治理的概念，并说明它和数据管理、数据仓库有什么关系？
考察点：概念清晰度、层次划分能力、对技术与流程的区分认知。
回答框架：定义 → 三要素（人、流程、技术）→ 和数据管理的区别（治理是决策，管理是执行）→ 落点到数据仓库的依赖。
示例回答：数据治理是建立数据资产管理的规范与权责体系，包含制度、组织和技术三大要素。数据管理侧重日常执行，治理侧重决策框架。数据仓库是治理落地的关键场景，通过元数据管理保证ETL链路可追溯。
可能追问：你们公司数据治理的组织结构是怎样的？数据治理委员会如何运作？
问答卡片 2：数据字典与元数据管理
面试问题：数据字典和元数据有什么区别？你在项目中如何管理元数据？
考察点：概念辨析、工具使用经验、元数据自动化采集能力。
回答框架：区分业务元数据（字典）与技术元数据（表结构、血缘）→ 工具选型（Atlas / DataHub / 自研）→ 自动化采集流程。
示例回答：数据字典是业务侧对字段含义和枚举值的定义；元数据包含表结构、分区、ETL依赖等技术信息。我曾在实时数仓项目中使用Apache Atlas自动抓取Hive元数据，并建立字段级血缘，同时结合Wiki维护业务字典。
可能追问：元数据变更后如何保证下游及时感知？如何处理无主表的元数据？
问答卡片 3：数据血缘构建与应用
面试问题：数据血缘如何构建？当血缘链路出现断点你会怎么排查？
考察点：血缘采集原理、断点定位能力、对常用工具的掌握。
回答框架：采集方式（解析SQL/Parser、日志拦截、手动录入）→ 存储（图数据库/关系表）→ 断点排查三步：检查采集任务、验证SQL解析规则、回补历史元数据。
示例回答：血缘主要靠解析ETL中的SQL语句获取表级依赖，使用开源工具SQLLineage做字段级解析。遇到断点，先检查采集Agent是否正常运行，再确认SQL中是否使用了临时表或动态表名导致解析失败，最后手动补全。
可能追问：如果某些表来自上游第三方系统，无法获取SQL，你如何处理？
项目案例：电商订单实时数仓数据血缘治理
| 项目名称 | 电商订单实时数仓数据血缘治理项目 |
| 业务背景 | 某头部电商B2C业务线，订单数仓依赖20+上游微服务，上游表结构变更（字段改名、分区策略调整）频繁，导致ETL链路断裂、报表延迟。 |
| 规模指标 | 日处理订单量2000万+，血缘表数8000+，ETL任务500+，涉及Hive / Flink / Kafka三引擎。 |
| 技术栈 | Apache Atlas（元数据管理）、SQLLineage（字段血缘解析）、Neo4j（血缘存储）、Prometheus + Grafana（监控告警）。 |
| 核心难点 | ①Flink作业使用UDTF导致SQL解析失败；②临时表&动态表名无法自动跟踪；③跨团队变更通知滞后。 |
- 你们如何解决Flink UDTF的血缘解析？——答：对UDTF注册自定义解析器，将输出字段与输入表字段做映射。
- 动态表名（如按天分表）怎么处理？——答：在血缘模型中引入正则匹配或通配符表，运行时解析为实际表。
- 血缘断点自动化修复机制？——答：断点触发告警后，根据上下游元数据历史版本自动回填缺失链路。
“在我曾负责的电商实时数仓项目中，我们面临多系统交错导致血缘断点问题。我通过引入Apache Atlas作为元数据中心，结合自研SQL解析器处理UDTF场景，同时建立变更监控告警机制。最终将断点发现时间从4小时压缩到5分钟内，准确率提升至95%。这个思路可以迁移到任何多数据源、多ETL引擎的数据治理场景中——核心是元数据自动化采集+异常解析补偿+实时告警。”