企业数据治理：数据血缘追踪的技术方案

企业数据治理：数据血缘追踪的技术方案

数据血缘（Data Lineage）回答了企业数据治理中最基本的问题：这个数字从哪里来？经过了哪些转换？谁改过它？在GDPR、”删除权”和审计合规的多重压力下，数据血缘从”nice to have”变成了”必须实现”。

数据血缘的三个层次

• L1 表级血缘：A表的数据来自B表和C表的JOIN。这是最粗的粒度，通常由ETL工具（dbt、Airflow）自动生成。适合回答”这个报表依赖哪些上游表”。
• L2 列级血缘：report.customer_name来自orders.email经过JOIN users表后取users.full_name，再通过UPPER()函数转换。适合回答”修改users.full_name的格式会影响哪些下游”。
• L3 行级血缘：report表的第157行数据来自orders表的第4231行和第8923行经过聚合计算得出。这是最细的粒度，对于审计和”删除权”响应至关重要——你可以精确定位哪些聚合结果需要重新计算。

技术实现方案

dbt天然提供L1和部分L2血缘——它的ref()和source()函数自动构建DAG，dbt docs generate生成可视化血缘图。要获得完整的L2和L3血缘，推荐OpenLineage——它通过在Spark、Airflow、dbt等工具中注入标准的OpenLineage事件来捕获运行时血缘。Marquez是OpenLineage的参考实现，提供血缘可视化和元数据搜索。

与删除权的对接

实现数据血缘后，”删除某个用户的全部数据”就不再是噩梦：从源表（如users）的user_id出发，沿着血缘图向下游追溯，标记所有包含该user_id衍生数据的表和列。对于聚合表（该用户的数据已与其他用户的数据混合），需要判断聚合粒度——如果聚合是按用户维度的，删除该用户的行；如果是全局聚合，触发重新计算。整个流程可以通过血缘图自动化，而非手工排查数百张表。