原来 EAST 口径文档自动生成，难点在 WHERE 子句

工程师9527
8 阅读6分钟

试了好几个开源血缘工具，遇到 Lateral View 和存储过程基本全跪。更别提解析 WHERE loan_status = '正常' AND industry NOT IN ('房地产') 这种关键业务过滤条件了。

每次业务方来问口径，我都得把几百行的嵌套 SQL、临时表、存储过程逻辑在脑子里“编译”一遍，再翻译成人话，效率低到令人发指。直到最近深度接触了 算子级血缘 和 行级裁剪 这套组合拳，才发现 EAST 这类监管口径文档自动生成，真正的技术硬骨头原来在这。

一、痛点：我们到底在“盘”什么？

EAST、1104 报送，数据团队最怕的就是“盘点”。你以为的盘点：看看 SQL，写写文档。实际的盘点：

  1. 逻辑黑盒：一个“对公贷款余额”指标，代码可能散落在 3 个调度任务、5 个存储过程里，中间用临时表传来传去。人工梳理？跟解迷宫差不多。
  2. 条件盲区：最要命的是 WHERE、JOIN ON、HAVING 里的过滤条件。这直接定义了指标的业务范围。传统血缘工具告诉你数据来自 loan_table 的 balance 字段，但不会告诉你它只统计了“状态正常且非房地产行业”的贷款。这个“且”字，就是合规风险的藏身之处。
  3. 变更即失效：好不容易盘清楚了，文档刚写好。上游同事把 customer_info 表里的 branch_code 字段枚举值从 ('001','002') 改成了 ('A01','A02')。你的文档立刻过期，而你可能要到下个月报表出错时才知道。

这就是传统“表级/列级血缘+人工”模式的死循环：看不清，盘不动，保鲜难。表级血缘动不动就“狼来了”（关联的表一改就告警所有下游），列级血缘是个“半瞎子”（看不到计算和过滤逻辑），最后还得靠人肉 CPU 去解析 AST。

二、破局：从“列”到“算子”的维度升级

问题的本质是解析粒度不够。你需要的不只是“数据从哪里来”，更是“数据如何被加工、哪些数据被选中”。这就必须深入到 SQL 执行的**算子（Operator）**层面。

画了个逻辑图，大家凑合看，原理大概是这样：

血缘对比.png

以 Aloudata BIG 的实现为例，它的 算子级血缘 核心原理是：

  1. 深度AST解析：不是简单地匹配关键字，而是像数据库优化器一样，解析SQL的抽象语法树，识别出 Scan（扫描表）、Filter（过滤，对应WHERE）、Join（关联，包含ON条件）、Aggregate（聚合）、Project（字段投影）等一个个算子。
  2. 穿透复杂结构：对嵌套子查询、Common Table Expression (CTE)、临时表，甚至是 DB2/Oracle 的存储过程（PL/SQL），进行递归解析，把层层包装的逻辑“拍平”，还原出完整的端到端数据变换流水线。
  3. 捕获过滤逻辑：这是关键！Filter 算子包含了所有 WHERE 条件；Join 算子包含了 ON 的关联条件。这些条件被结构化地提取出来，成为“行级裁剪”的分析基础。

三、核心骚操作：“行级裁剪”精准排雷

“行级裁剪”是建立在算子级血缘之上的实战利器。它解决了“无效告警”这个老大难问题。

传统场景：上游表 customer_info 的 branch_name 字段值从“上海分行”改为“上海浦东分行”。列级血缘一看：下游报表 report_a 用了这个字段，告警！但事实上，report_a 的WHERE条件是 branch_name = '北京分行'，这个变更毛影响都没有。你白忙活一场。

行级裁剪场景：

  1. 算子级血缘已经知道 report_a 的指标数据流经过一个 Filter 算子，条件是 branch_name = '北京分行'。
  2. 当上游 branch_name 枚举值变更时，系统会进行逻辑判断：新的枚举值集合 {'上海浦东分行', ...} 与过滤条件 '北京分行' 是否有交集？
  3. 判断无交集，静默，不产生告警。只有当下游过滤条件真的可能被影响时（比如条件用的是 IN 列表包含被修改的值），才会精准告警。

这技术能把那些吵死人的“洪水警报”式通知减少 80% 以上，让运维同学从“背锅预警器”变回正常人。

四、落地：口径文档怎么“自动”出来？

基于上述能力，自动化生成口径文档就水到渠成了：

  1. 一键溯源：在平台里点击 EAST 报表的某个指标（如“各项贷款余额”），系统反向解析，穿透所有中间表和存储过程，直达源系统的核心业务表。

  2. 逻辑聚合：把沿途所有的 Filter（过滤条件）、Join（关联关系）、Aggregate（聚合维度）算子信息收集起来。

  3. 自然语言生成：将这些结构化的算子信息，转换成可读的描述：

    “本指标取自 核心信贷系统.loan_contract 表，筛选条件为 contract_status IN ('生效','正常') 且 product_code NOT LIKE 'ZZ%'，与 客户信息系统.customer 表通过 customer_id 关联，获取客户所属分行，最后按 branch_id 分组汇总 loan_amount 字段得出。”

  4. 持续保鲜：因为血缘是通过主动解析代码/日志得到的，一旦上游 SQL 变更，这个解析结果和生成的口径描述会自动更新。文档从此是“活”的。

浙江农商联合银行用这套方法，把 EAST 全量指标盘点从几个月干到了 8 小时以内，效率提升 20 倍。核心就是靠算子级血缘啃下了他们核心系统 DB2 存储过程解析这块硬骨头。

五、总结与建议

搞 EAST 口径自动化，别再死磕“字段从哪里来”了。真正的战场在 “数据怎么被筛选和计算” ，也就是 SQL 的算子级逻辑。

  • 对于技术选型：重点考察工具对复杂 SQL（嵌套、CTE、存储过程）的解析深度，以及是否能提取 WHERE/JOIN ON 等过滤条件。这是区分玩具和工具的关键。
  • 对于落地：从最痛的那个报表模块开始试点，比如“大额风险暴露”。先验证它能不能把你最头疼的那段存储过程逻辑扒明白。
  • 对于价值：这不仅是省下写文档的时间，更是通过“行级裁剪”实现精准的变更影响分析，把问题拦截在上线前，这才是最大的价值——让你少背锅。

这东西对重构老数仓特别有用，建议有历史包袱的团队可以关注下。

avatar
文章
阅读
粉丝