分类分级与数据血缘 - 面试题

#

★★★

1. 敏感数据识别（PII、PHI、PCI）的自动扫描？

问题

如何通过自动扫描技术识别数据库中的敏感数据，包括个人身份信息（PII）、受保护健康信息（PHI）和支付卡行业数据（PCI）？

考察点

敏感数据分类（PII、PHI、PCI）的识别范围
自动扫描的常用技术手段（正则、NLP、AI 分类）
扫描结果的落地与治理联动

答案

自动扫描的核心思路是"先识别、后分类、再治理"。底层技术通常分三层：第一层是正则表达式与关键词匹配，针对身份证号、手机号、银行卡号、邮箱等有明确格式的字段，用正则（如银行卡 Luhn 校验、身份证 18 位校验）快速命中；第二层是机器学习/自然语言处理，对列名、注释、样本值进行语义推断，识别格式不固定但语义明确的字段（如"患者姓名""家庭住址"）；第三层是规则与字典结合，配置业务字典（如员工表、患者表）提升召回率。识别结果写入元数据平台，打上 PII/PHI/PCI 标签，并联动权限、脱敏与审计。PCI 场景对卡号、CVV、磁条数据有明确合规要求，识别后需限制存储与展示。

解析

单一正则无法覆盖所有敏感类型，需正则+语义+字典的多策略组合；同时要避免误报与漏报，识别引擎应提供置信度并可人工复核，识别结果应可追溯、可增量刷新。

示例代码

-- 用正则识别疑似手机号（中国大陆）的字段
SELECT column_name, table_name
FROM information_schema.columns
WHERE table_schema = 'public'
  AND data_type IN ('varchar','text','char')
  AND (lower(column_name) LIKE '%phone%' OR lower(column_name) LIKE '%mobile%');

-- 对样本值做 Luhn 校验识别疑似银行卡号
SELECT card, (Luhn_Check(card)) AS is_valid FROM (
  SELECT '6222021234567890' AS card
) t;

#

★★★

2. 数据分类分级（Data Classification）的标准，公开、内部、机密、绝密？

问题

数据分类分级的标准是什么？公开、内部、机密、绝密四个等级如何定义和落地？

考察点

分类分级的基本概念与等级划分
各等级的定义、访问控制与保护要求
分级与业务条线、生命周期管理的结合

答案

数据分类分级是按敏感程度和影响范围对数据划分保护等级的管理制度。常见的四级划分：公开（Public）可对外发布，无敏感信息；内部（Internal）仅限企业内部使用，泄露影响有限；机密（Confidential）限特定部门或角色访问，泄露会造成较大损失；绝密（Restricted/Secret）限极少数人，泄露会带来严重法律或商业风险。分级落地时，将等级标签写到元数据中，并据此决定访问控制（RBAC/ABAC）、传输与存储加密、脱敏策略、审计日志与保留期限。分级标准应参考行业规范（如金融分级、个人信息保护法），且每个字段/表都应有明确的所有者（Data Owner）负责定级。

解析

分级不是一次性的，数据在生命周期中等级可能变化（如脱敏后从机密降为公开），需与脱敏、血缘联动实现自动降级；分级结果要能驱动数据库权限和脱敏策略，否则制度无法落地。

#

★★★

3. 数据目录（Data Catalog）的应用，元数据、血缘、术语？

问题

数据目录（Data Catalog）的核心应用是什么？它如何组织元数据、血缘与业务术语？

考察点

答案

数据目录是面向全组织的数据资产索引与检索系统，帮助用户"找到数据、理解数据、信任数据"。它把三类信息统一组织：技术元数据（表、字段、类型、分区、血缘关系）、业务元数据（业务术语、指标定义、数据所有者、SLA）、运营信息（数据质量评分、最近刷新时间、使用热度）。业务术语（Glossary）把晦涩的字段名映射为业务语言（如 amount 对应"交易金额"），是业务与技术沟通的桥梁；血缘则展示数据从源到目标表到报表的链路。数据目录通常带搜索、标签、收藏、评论与订阅功能，是大数据平台和治理平台的核心组件。

解析

数据目录的价值在于治理"数据查找"这一高频痛点，通过集中索引降低评估数据可信度的成本；它依赖元数据采集的自动化程度，目录越完整，自助分析越顺畅。

#

★★★

4. 数据分类分级的工具，Apache Atlas、DataHub、Collibra？

问题

数据分类分级的常用工具有哪些？Apache Atlas、DataHub、Collibra 各自的特点是什么？

考察点

主流元数据/治理工具的分类分级能力
三种工具的开源/商业属性与定位差异
工具选型考虑因素

答案

三者都是元数据与治理平台，但定位不同。Apache Atlas 是 Apache 开源项目，深度集成 Hadoop 生态（Hive、HBase、Kafka、Sqoop），以类型系统（Type System）和血缘为核心，提供基于标签（Tag）的资产分类与访问控制建议，适合以 Hadoop 为主的数据湖环境。DataHub（LinkedIn 开源）是现代化数据目录，采用 Kappa 架构，元数据模型灵活、搜索体验好，支持血缘、术语、数据质量与 schema 版本，社区活跃，适合现代数据栈。Collibra 是商业治理平台，强在业务术语、数据治理流程（认责、审批、政策管理）与合规报告，适合大型企业需要制度流程落地的场景。选型需权衡开源可控性、业务术语支持、血缘深度与企业集成需求。

解析

这三个工具本质都在做"元数据采集+分类标签+血缘+搜索"，差异在生态、业务治理深度与商业化程度；选型应结合团队栈与对流程治理的需求，开源且社区活跃的工具（如 DataHub）更易落地。

#

★★★

5. OpenMetadata、DataHub 的元数据模型？

问题

OpenMetadata 和 DataHub 的元数据模型是如何设计的？它们各自如何组织实体与关系？

考察点

元数据模型的核心要素（实体、类型、关系、属性）
OpenMetadata 与 DataHub 模型设计的差异
模型对扩展性与接入生态的影响

答案

两者都采用"实体-关系-属性"的元数据模型，但实现方式不同。DataHub 以 Aspect（属性片段）为核心，一个实体（如 Dataset）由多个可独立更新的 Aspect 组成（如 schemaMetadata、ownership、dataQuality），通过版本化的历史记录支持时间旅行，首次写入时过验证（first-write-wins），后续更新走合并（merge），模型定义用 PD (Pegasus)/JSON Schema。OpenMetadata 采用类对象模型的类型系统（Entity Type），实体（如 Table、Pipeline）通过 Relationship 关联，并内置了标准化的实体关系图（如 Table 与 Column、Dashboard 与 Chart）；整体采用 JSON Schema 定义，并区分"实体实数据"与"界面渲染"的分离。两者都支持血缘、术语、标签与扩展自定义属性。

解析

元数据模型要平衡"表达的灵活性"与"查询的效率"：DataHub 的 Aspect 片段化利于并发更新与增量同步，OpenMetadata 的类型系统利于关系遍历与标准化；对扩展性要求高的团队宜选 Aspect 化模型。

#

★★★

6. 元数据管理（Metadata Management），技术元数据、业务元数据？

问题

什么是元数据管理？技术元数据与业务元数据分别指什么，二者如何配合？

考察点

元数据的概念与分类
技术元数据与业务元数据的定义与来源
元数据管理的价值与落地方式

答案

元数据是"关于数据的数据"，元数据管理是对其采集、组织、存储、维护与使用的过程。技术元数据描述数据的技术结构，包括表结构、字段类型、约束、索引、分区、存储位置、血缘与调度信息，多由系统自动采集（如 DDL 解析、JDBC 扫描、ETL 工具导出）。业务元数据描述数据的业务含义，包括业务术语、指标口径、数据负责人、SLA、质量要求与使用说明，多由人工维护或从业务系统导入。两者配合才能让人既看懂"数据长什么样"（技术）又懂"数据代表什么、谁负责"（业务）。元数据管理是数据目录、血缘、质量与治理的基础，帮助组织盘活数据资产、降低理解成本。

解析

技术元数据易自动采集、业务元数据需人工维护，这是元数据治理的主要工作量所在；好的元数据管理要打通两者，让搜索能同时命中字段名与业务含义。

#

★★★

7. 数据契约（Data Contract）的应用，生产者-消费者约定？

问题

数据契约（Data Contract）的应用是什么？生产者与消费者之间如何通过契约约定数据？

考察点

数据契约的定义与核心内容
生产者-消费者之间的职责划分
数据契约在治理与质量保障中的作用

答案

数据契约是数据生产者与消费者之间对数据交换的显式、可校验的约定，类比 API 契约。它通常包含：Schema 定义（字段名、类型、必填性、枚举值）、数据语义（字段含义、口径）、质量约束（非空率、唯一性、取值区间）、SLA（送达时间、时效性）、血缘分界与破坏性变更通知。契约作为"可执行文档"被版本管理，变更走评审流程，并用契约测试自动校验生产端数据是否满足要求。落地时常用 schema 校验（如 Avro/Protobuf 兼容性）、质量规则（如非空、唯一）与断点监控；一旦违约即告警或阻塞下游。数据契约让"数据分发"契约化，是数据网格（Data Mesh）与数据团队协作的核心机制。

解析

数据契约实现从"隐式约定"（靠口头和文档）到"显式可校验"的转变，能显著降低下游消费方因上游变动而断裂的风险；其关键在把质量、口径、SLA 一并写入契约并自动化校验。

#

★★★

8. 数据分级标签如何随血缘自动传播？为什么下游表与报表应继承上游字段的敏感级别，传播规则如何设计？

问题

数据分级标签如何随血缘自动传播？为什么下游表与报表应继承上游字段的敏感级别，传播规则应如何设计？

考察点

血缘驱动的敏感标签传播机制
下游继承上游敏感级别的必要性
传播规则的设计（传播方向、覆盖、例外）

答案

敏感标签沿血缘自上而下传播，即上游字段的敏感级别自动推导到下游表、视图与报表。必要性在于：脱敏/权限通常部署在出口（报表、API），若只在上游打标而下游不继承，敏感数据会在下游泄露；且手动为每个下游打标成本高、易遗漏。传播规则设计要点：一是方向，一般沿"数据源→仓库→应用→报表"单向传播，字段级处理（如聚合、加密）可能降级；二是"取最大"原则，多个上游字段汇聚到下游字段时取最高敏感级别；三是允许例外与人工覆盖，脱敏/聚合后的字段可手动降级，但要记录覆盖原因与审计；四是传播要基于字段级血缘，避免表级血缘导致过度标记。

解析

标签传播把"打标"从一次性人工操作变成"随血缘自动推导"，是分级治理落地的关键；难点在于字段级血缘的准确性，以及降级规则（脱敏、聚合、加密）的自动辨识，否则会要么漏标要么过度保护。

示例代码

-- 示例：下游字段敏感级别 = 上游所有字段中的最高级别
-- 用血缘表（lineage: src_field -> dst_field）做聚合推导
SELECT dst_field,
       MAX(src_level) AS inherited_level
FROM lineage
GROUP BY dst_field;

#

★★★

9. 血缘如何支撑影响分析（改表前评估下游影响）与问题溯源（上游变更导致下游数据异常）？两类场景对血缘粒度的要求有何不同？

问题

数据血缘如何支撑影响分析（改表前评估下游影响）与问题溯源（上游变更导致下游数据异常）？两类场景对血缘粒度的要求有何不同？

考察点

血缘在影响分析（Impact Analysis）中的作用
血缘在问题溯源（Root Cause Analysis）中的作用
两类场景对血缘粒度的差异要求

答案

影响分析用于"变更前"：修改某表结构、删除字段或调整口径前，沿血缘从变更点向下游遍历，找出所有受影响的表、任务、报表与 API，评估风险并通知相关方。问题溯源用于"故障后"：下游数据异常时，沿血缘向上游回溯，定位是哪个源表、哪个 ETL 步骤、哪次调度导致异常。两者对血缘粒度的要求不同：影响分析需要相对完整、可遍历的"链路级"血缘（能列出所有下游节点），但容忍一定粒度粗糙；问题溯源则需要更细的"字段级+操作级"血缘（能定位到具体字段、具体转换步骤与执行实例），才能精确定位误差来源。因此生产级血缘引擎应同时保留表级与字段级、以及按时间版本化的执行血缘。

解析

影响分析是"下游视角"、溯源是"上游视角"，方向相反但都依赖血缘图的可遍历性；粒度的差异本质是"够用"与"精确"的权衡，字段级血缘成本更高但溯源价值更大。

#

★★

10. 数据血缘（Data Lineage）的概念，表 → 字段的下游链路？

问题

什么是数据血缘（Data Lineage）？如何理解"表 → 字段"的下游链路？

考察点

血缘的定义与价值
表级与字段级血缘的层次
血缘的采集与应用

答案

数据血缘描述数据从源头到目的地的流转链路，即数据在表、字段、任务、报表之间的来源与去向关系。血缘分层级：表级血缘展示"表 A 的数据来自表 B、流入表 C"的粗粒度关系；字段级血缘展示"字段 X 由字段 Y、Z 经计算产生"，粒度更细，是精确定位与影响分析的基础。血缘常以有向无环图（DAG）表示，节点为表/字段/任务，边为父子关系。血缘的价值包括影响分析、问题溯源、数据质量与合规审计（说明数据来源、支持数据可追溯）。采集方式包括解析 SQL、观测执行计划、解析 ETL 工具元数据等。

解析

血缘本质是"数据来源的可追溯性"，表级血缘易采集但粒度粗，字段级血缘精准但采集成本高；二者结合才能满足不同场景（架构梳理 vs 精准溯源）。

#

★★

11. Confluent Schema Registry 的兼容性策略，BACKWARD、FORWARD、FULL？

问题

Confluent Schema Registry 的兼容性策略有哪些？BACKWARD、FORWARD、FULL 分别代表什么？

考察点

Schema Registry 的兼容性概念
BACKWARD、FORWARD、FULL 三种策略的语义
兼容性策略对生产消费的影响

答案

Schema Registry 管理 Kafka 消息的 Schema 并校验兼容性，避免生产者/消费者因 Schema 演进不兼容而崩溃。三种策略：BACKWARD（向后兼容）允许新 Schema 兼容旧 Schema，即用新 Schema 的消费者可以读旧 Schema 生产的数据，只能增加可选字段或删除必填字段，保证旧消费者能读新数据；FORWARD（向前兼容）允许新 Schema 兼容旧 Schema 的消费者，即用旧 Schema 的消费者能读新 Schema 生产的数据，只能删除字段或增加带默认值的字段；FULL（全兼容）同时满足两者，即同时兼容新旧消费方。判断依据是使新旧 Schema 的读写双向兼容。选择策略取决于演进方向：若消费者先升级选 BACKWARD，生产者先升级选 FORWARD。

解析

兼容性策略本质是"谁是先行者"的契约：BACKWARD 面向"消费者先升级"，FORWARD 面向"生产者先升级"，FULL 是两者兼顾的最严格策略；核心是字段默认值与必填性的约束。

#

★★

12. Schema Registry 的应用，Kafka Avro/Protobuf Schema 版本管理？

问题

Schema Registry 在 Kafka 中如何应用？如何用 Avro/Protobuf Schema 做版本管理？

考察点

Schema Registry 在 Kafka 中的作用
Avro/Protobuf Schema 的版本管理
Schema 演进与消费者兼容性

答案

在 Kafka 中，生产者把 Schema 注册到 Schema Registry 并获取 Schema ID，消息中携带该 ID 而非完整 Schema；消费者用 ID 从 Registry 拉取对应 Schema 反序列化。这样消息体积小、Schema 集中管理、版本可追溯。版本管理上：每次 Schema 变更生成新版本号，Registry 记录全量历史与兼容性检查结果；写入时按配置的兼容性策略（如 BACKWARD）校验新版本与历史版本是否兼容，不兼容则拒绝注册。Avro 与 Protobuf 都支持字段演进，但语义不同：Avro 用字段名与 union 表达可选性，Protobuf 用 field number 与 optional 表达，兼容性校验规则（如新增字段必须有默认值）也各有差异。Schema 版本管理让"生产者演进不影响消费者"变得可控。

解析

Schema Registry 的价值在于"集中管理+版本化+兼容性校验"，把消息契约从"散落各处"变成"可控可演进"；消息只带 ID 有效降低序列化开销，同时保证消费者按正确版本解析。

#

★★

13. 数据库 Schema 注册表（Database Schema Registry）？

问题

什么是数据库 Schema 注册表（Database Schema Registry）？它解决什么问题？

考察点

数据库 Schema Registry 的定义
与消息队列 Schema Registry 的异同
解决的问题与价值

答案

数据库 Schema Registry 是集中管理数据库 Schema 及数据变更的注册服务，它把数据库的 DDL（建表、改字段、加索引）与数据变更（CDC）统一注册、版本化并对外发布，使下游消费者（数据仓库、Flink、Kafka、应用）能感知并适配 Schema 变化。它扩展了消息队列 Schema Registry 的思想到数据库领域：只要数据库 Schema 变更，注册表即生成新版本并触发兼容性评估与下游通知，避免下游因上游表结构变化而崩溃。也常与 CDC 结合，把表结构变更与数据变更一同分发。它解决的核心问题是"数据库变化如何可控地传导到消费方"，常见于数据管道与实时计算场景。

解析

数据库 Schema Registry 本质是"数据库 Schema 的契约化治理"，把数据库层面的变更也纳入版本与兼容性管理；相比纯消息队列，它还要处理 DDL 与 CDC 的时序、幂等与增量同步。

#

★★

14. Schema Registry 在消息队列与流处理中的应用，如何校验生产者与消费者的 Schema 兼容性，Avro/Protobuf 的演进策略如何设计？

问题

Schema Registry 在消息队列与流处理中如何应用？如何校验生产者与消费者的 Schema 兼容性，Avro/Protobuf 的演进策略如何设计？

考察点

消息队列中 Schema Registry 的注册与校验流程
生产/消费两端的兼容性校验
Avro/Protobuf 的演进策略设计

答案

在消息队列与流处理中，Schema Registry 作为统一契约中心：生产者注册 Schema 并携带 ID 发送消息，消费者按 ID 拉取 Schema 反序列化。兼容性校验发生在"注册新版本"时：系统按配置策略（BACKWARD/FORWARD/FULL）比较新 Schema 与历史 Schema 的读写兼容性，不兼容即拒绝注册，从而保证线上生产/消费两端不因 Schema 演化而断裂。演进策略设计上，Avro 建议新增字段用带默认值的 union 或 optional 字段、不删除字段、变更字段名用别名；Protobuf 建议新增字段用新的 field number 且类型必须兼容、不重用已删除的 field number、用 oneof/optional 表达可选。流处理（如 Flink）中常把 Schema 注册与状态存储、序列化器绑定，Schema 变更还需考虑状态结构与上下游状态兼容。

解析

兼容性校验的时机在"注册时"而非"消费时"，是防患于未然的关键；演进策略的共性约束是"新增字段要可默认、删除字段要谨慎、field number/名称不可复用"。

#

★★

15. Schema Registry 的实现要点，Schema 的存储、版本管理与缓存如何设计，注册表不可用时对生产消费链路的影响？

问题

Schema Registry 的实现要点是什么？Schema 的存储、版本管理与缓存如何设计，注册表不可用时对生产消费链路有何影响？

考察点

Schema 的存储与版本管理设计
缓存机制（本地缓存、Redis）设计
Registry 不可用时的降级与影响

答案

实现要点包括存储、版本与缓存三方面。存储：用数据库（如 PostgreSQL 或内嵌 KV）存储 Schema 实体、版本号、兼容性策略与元数据，Schema 以 JSON/Avro/Protobuf 文本或二进制存储，并对内容做哈希以去重，防止重复注册。版本管理：每次变更递增版本号，记录完整历史与"变更时间、作者、兼容性检查结果"，支持按版本查询与回退。缓存：客户端本地缓存 Schema ID→Schema 映射，减少频繁请求；服务端用 Redis 缓存高频读取结果，降低 DB 压力。可用性影响：注册表不可用时，若客户端已有本地缓存可继续收发（存在数据一致性风险，Schema 未缓存的新版本无法解析）；从 Registry 拉取 Schema 的请求会失败导致序列化/反序列化报错，生产消费链路中断。因此 Registry 需高可用部署（如集群+副本），并预置本地缓存与超时/重试策略。

解析

Schema Registry 本质是"读多写少"的高可用服务，缓存与去重是性能关键，高可用与降级策略决定链路韧性；客户端缓存是应对瞬时不可用的重要手段。

#

★★

16. Schema 演化的版本控制？

问题

Schema 演化的版本控制如何实现？如何管理 Schema 的变更历史与兼容性？

考察点

Schema 版本控制的概念与价值
版本管理的方式（版本号、历史、兼容性）
与下游消费的联动

答案

Schema 演化版本控制指对 Schema 的每次变更进行登记、编号、历史留存与兼容性管理，使演进可追溯、可回退、可校验。实现方式：为每个 Schema 分配唯一 ID 与递增版本号，将完整 Schema 内容与变更元数据（时间、作者、说明）存入注册表；每次新增版本时，依据兼容性策略与历史版本比对，判定是否兼容，不兼容则阻止或告警。版本历史让消费者可"按版本消费"，即显式指定要使用的 Schema 版本，避免因上游演进被强制适配。版本控制还支持回退（发布问题时可回滚到旧版本）与协同（多团队共享演进状态）。结合序列化（Avro/Protobuf）与兼容性策略，schema 版本控制是数据契约治理的基础。

解析

版本控制的核心是"可追溯、可回退、可校验"，把 Schema 从"可变的代码"变成"受控的资产"；与兼容性策略结合，才能既允许演进又不破坏下游。

#

★★

17. 字段级血缘为什么比表级血缘难？表达式改写、视图嵌套、函数处理会导致哪些解析误差？

问题

字段级血缘为什么比表级血缘难？表达式改写、视图嵌套、函数处理会导致哪些解析误差？

考察点

字段级血缘的复杂性来源
表达式改写、视图嵌套、函数处理带来的误差
高精度字段级血缘的实现难点

答案

表级血缘只需判断"表间数据流向"，而字段级血缘需要解析 SQL 中字段与字段的精确依赖关系，复杂得多。误差来源：一是表达式改写，如 SELECT a+b AS c FROM t 中 c 依赖 a 和 b，但若写成 SELECT b+a AS c 或 SELECT a+a AS c，依赖关系需精确区分；列通配 *、coalesce、if、case 等导致依赖不明确。二是视图嵌套，多级视图层层包裹，字段别名在嵌套中重命名，需逐层展开解析，否则会丢失底层真实来源。三是函数与聚合处理，sum(x)、count(distinct y)、group by 等改变了字段的粒度与语义，聚合后字段与上游字段的对应关系需特别标注。四是 SQL 方言差异（递归 CTE、子查询、窗口函数）增加解析复杂度。这些因素导致解析器易产生"漏报"（漏掉真实依赖）或"误报"（标出不存在的依赖）。

解析

字段级血缘难在"语义级解析"，需真正理解 SQL 表达式而非只有语法树；工程上常结合 SQL 语法树、AST 遍历与执行计划观测来提升精度，但完整语义解析仍难做到 100% 准确。

#

★★

18. 分类分级结果如何联动数据库权限与动态脱敏？标签驱动的访问控制如何落地？

问题

分类分级结果如何联动数据库权限与动态脱敏？标签驱动的访问控制如何落地？

考察点

标签驱动的访问控制（Label-based Access Control）概念
分级结果与数据库权限的联动
分级结果与动态脱敏的联动

答案

分类分级结果作为"标签"（Label）驱动两类治理动作：一是权限，即按标签决定谁能访问哪些数据（Label-based Access Control）；二是脱敏，即按标签与角色决定查询时是否遮盖敏感字段。落地方式：在权限层，把数据标签映射到角色/权限模板，如"机密级数据仅 DBA 与数据所有者可读"，通过数据库的 RBAC、行级安全（RLS）或视图层实现；在脱敏层，把字段标签映射到脱敏规则，如"身份证号对非授权角色显示为掩码"，用动态脱敏（DDM）在查询出口按需遮盖。落地关键是把"标签"作为统一决策输入，由策略引擎（Policy Engine）根据"用户角色+数据标签+操作"三元组输出允许/遮盖/拒绝，并集中管理策略、留有审计日志。标签驱动的访问控制让"分级"从文档变成可执行的策略。

解析

标签驱动的访问控制把"分级"与"执行"打通，核心是策略引擎统一决策；难点在于标签到权限/脱敏策略的映射维护、策略的层叠与默认拒绝原则，以及审计的完整性。

#

★

19. 数据血缘的采集方式，SQL 解析、执行计划观测与 ETL 工具元数据三种方案的覆盖度与成本？

问题

数据血缘的采集方式有哪些？SQL 解析、执行计划观测与 ETL 工具元数据三种方案的覆盖度与成本如何？

考察点

三种血缘采集方式的原理
各方案的覆盖度与成本对比
组合使用的策略

答案

三种主流采集方式：一是 SQL 解析，对 SQL 语句做语法分析，从 AST 中提取表与字段依赖，覆盖度高（能覆盖所有可见 SQL），但依赖 SQL 方言支持，且对动态 SQL、存储过程内的复杂逻辑解析不完整，初始化成本高。二是执行计划观测，从数据库执行计划（如 explain plan）中提取实际读取/写入的表与字段，真实准确（反映运行时实际血缘），但依赖引擎能力与采样，非 SQL 场景（如外部工具）覆盖度低，且需要接入每个引擎。三是 ETL 工具元数据，从 ETL/BI 工具（如 Airflow、Informatica、Tableau）导出的元数据中获取血缘，无侵入、成本低，但只覆盖工具管理的数据，且粒度常为表级。三者互补：主流做法是"SQL 解析为主、执行计划校正、ETL 元数据补充"，按覆盖度与成本权衡组合。

解析

三种方式各有优劣：SQL 解析覆盖广但精度有限，执行计划最真实但覆盖有限，ETL 元数据成本低但粒度粗；生产级血缘平台通常组合使用，以 SQL 解析为主干。