数据血缘追踪技术：Apache Atlas在银行数仓的落地

当银保监发出问询函，要求某家银行解释"流动性覆盖率"报表中某一金额的计算来源时，如果数据团队无法在2小时内给出从原始交易明细到最终报表指标的完整链路说明，将面临严重的合规风险。数据血缘（Data Lineage）正是解决这一问题的关键技术。Apache Atlas 作为开源数据治理和血缘平台，已在国内多家银行的数据中台项目中落地。

为什么银行需要数据血缘？

银行的数据链路呈典型的"深井"结构：一张最终监管报表可能依赖上游30+张DWS表，这些DWS表又依赖50+张DWD表，DWD 表再追溯至100+张ODS表和数十个源系统接口。没有血缘追踪，以下场景会带来灾难：

字段口径变更：DWD层的 txn_amt 字段从"交易金额"扩展为"交易金额+手续费"，如果下游50张报表不知道这个变更，其中有30张会计算错误；
监管问询：人行要求解释某笔不良贷款率数据的完整加工链路；
系统下线评估：判断核心接口库中的某张表是否可以下线，必须知道它下游影响的所有应用。

Apache Atlas 的核心概念

Atlas 使用 Type System（类型系统）来建模数据资产。银行场景下的关键类型定义如下：

类型	定义	示例
`hive_table`	Hive 表	`dws.dws_card_daily_summary`
`hive_column`	Hive 表的列	`txn_amt`
`spark_process`	Spark 作业	`spark_etl_dws_daily`
`kafka_topic`	Kafka Topic	`txn-credit-card`
`db2_table`	DB2 源系统表	`core.cust_base`

Atlas 通过Hook 机制自动捕获血缘：

Hive Hook：在 Hive CLI/JDBC/Beeline 执行 SQL 时，解析 AST（抽象语法树），自动提取 SELECT ... FROM ... JOIN ... 中的源表和目标表关系；
Spark Listener：通过 Spark 的 QueryExecutionListener 捕获 Spark SQL/DataFrame 的逻辑计划，注册进 Atlas；
Kafka Hook：通过 Kafka Connect Atlas Sink 注册 Topic 与 Consumer/Producer 的映射关系。

金融数仓的血缘采集实践

1. Hive SQL 血缘自动解析

银行 ETL 作业以 Hive SQL 为主。Atlas Hive Hook 配置在 HiveServer2 中后，每次执行以下SQL都会自动注册血缘：

INSERT OVERWRITE TABLE dws.dws_cust_daily_summary
SELECT 
    a.cust_id,
    SUM(b.txn_amt) AS daily_amt
FROM dwd.dwd_cust_base a
JOIN dwd.dwd_txn_detail b ON a.cust_id = b.cust_id
GROUP BY a.cust_id;

Atlas 会自动创建如下血缘边（Lineage Edge）： - dwd.dwd_cust_base → spark_etl_dws_daily - dwd.dwd_txn_detail → spark_etl_dws_daily - spark_etl_dws_daily → dws.dws_cust_daily_summary

2. Spark DataFrame API 血缘捕获

对于用 Spark Scala/Python API 编写的复杂风控特征工程作业，Atlas 的 Spark 插件会监听 spark.sql.execution.QueryExecution 事件，提取逻辑计划中的 Read 和 Write 节点：

val df = spark.table("dwd.dwd_txn_detail")
  .filter(col("txn_date") >= "2024-01-01")
  .groupBy("cust_id")
  .agg(sum("txn_amt").alias("total_amt"))
  .write
  .mode("overwrite")
  .saveAsTable("dws.dws_cust_feature_v1")

这段代码执行后，Atlas 中的血缘关系显示 dwd.dwd_txn_detail 流向 dws.dws_cust_feature_v1。

3. 字段级血缘（Column Level Lineage）

表级血缘只能回答"A表影响B表"，但在监管问询中往往需要字段级答案："B表的 liquidity_ratio 字段是由A表的哪些字段计算出来的？"

Atlas 3.0+ 通过 JanusGraph 和自定义的 SQL 解析器，支持字段级血缘的粗粒度推导。如果 Atlas 自带解析器不能满足要求，银行通常会在 ETL 代码规范中要求工程师在 SQL 注释中显式声明字段映射：

-- lineage: dwd.dwd_asset_snapshot.aum -> dws.dws_cust_profile.total_aum
-- lineage: dwd.dwd_cust_base.cust_name -> dws.dws_cust_profile.cust_name
INSERT OVERWRITE TABLE dws.dws_cust_profile ...

然后通过自定义 Hook 解析注释生成精确血缘。

金融场景的 Atlas 部署架构

某全国性股份制银行的 Atlas 部署采用了高可用集群方案：

[ETL作业集群]
      | (Hive Hook / Spark Listener)
      v
[Atlas Server Cluster] (3节点HA)
      |
      v
[JanusGraph + Cassandra backend]
(存储血缘关系图谱)
      |
      v
[Atlas UI / 数据资产门户 / API Gateway]

Backend：JanusGraph + Cassandra（或 HBase）存储图数据，Elasticsearch 支持全文检索；
高可用：Atlas Server 通过 Nginx 负载均衡，后端图数据库做三副本；
数据量：该银行每日新增血缘关系约50万条，一年累积超过1.8亿条边，图查询性能通过索引优化保持在亚秒级。

血缘的应用场景

1. 监管问询响应

当收到监管机构要求解释"2024年Q3个人住房贷款不良率"口径时，数据管理员在 Atlas UI 中搜索字段 npl_ratio_mortgage，即可一键追溯：

npl_ratio_mortgage (DM层)
  <- agg_npl_mortgage (DWS层)
    <- loan_contract_status + overdue_days (DWD层)
      <- core_loan_master + core_acct_balance (ODS层)
        <- 信贷系统DB2 + 核心系统AS400 (源系统)

整个过程从原来的"文档翻查+人工确认半天"缩短到"自动图谱查看10分钟"。

2. 变更影响评估

BI团队计划修改 dwd.dwd_txn_detail 中 txn_type 的枚举值，新增"电子商业汇票"类型。在 Atlas 中查询该字段的下游血缘，发现影响52张DWS表和128张DM表。经评估，其中30张表是直接聚合该字段，需要增量刷新。变更范围和成本在评审会上清晰可见。

3. 自动元数据发现

银行数据资产门户（基于 Atlas API 构建）每天自动扫描新增表和字段，通过正则表达式识别敏感字段（如 id_card、card_no、phone），并自动添加 PII（个人敏感信息）标签，触发数据安全团队的脱敏审计流程。

总结

Apache Atlas 在银行数据治理中的最大价值，不是技术本身，而是将"数据链路黑箱"变成了"透明血缘图谱"。对于正经历从烟囱式数仓向中台化演进的银行而言，血缘追踪是数据资产管理的"基础设施"。建设时需注意：

规范先行：没有统一的表命名规范、字段命名规范，血缘图谱会变成无法理解的" spaghetti "；
自动化优先：依赖人工录入的血缘无法持久，必须通过 Hook 自动化捕获；
与工单系统打通：血缘发现字段口径问题时，应自动创建治理工单，形成闭环。

数据血缘是数据信任的基础设施。只有数据链路可见、口径来源可查，数据驱动决策才不会是一句空话。