Software Systems Atlas

中文

English

中文

English

主题

第 12 卷 / 第 12 章 / 第 2 课

12.2 运行时血缘与影响分析：从一条错误指标追到具体版本 ​

报告里的任务完成率突然下降。目录告诉你指标定义和 owner，却不能回答昨夜那次运行到底读取了哪个快照、使用哪版 SQL、是否跳过北部区域分区。真正排障需要把静态设计与每次执行事实连接起来。

本课目标 ​

  • 区分设计血缘、运行时血缘与字段级血缘；
  • 建模 dataset、job、run、process 与版本关系；
  • 选择解析、引擎事件和显式埋点等采集方式；
  • 用血缘做变更、事件和隐私影响分析。

1. 血缘是一张带时间的图 ​

基本节点包括：

  • dataset：表、文件集合、流、报告或模型输入；
  • job/process：执行转换逻辑的作业；
  • run：某个 job 的一次具体执行；
  • field：列、指标或特征；
  • code/config：SQL、镜像、参数与 schema 版本。

边至少表达 run READ dataset_version、run WROTE dataset_version。只记录：

text
missions_clean → daily_report

无法判断它描述当前设计、昨天运行还是三年前已退役逻辑，也无法区分重跑和回填。

2. 设计血缘与运行时血缘 ​

设计血缘 ​

来自代码、DAG 和声明配置，回答“按设计会依赖什么”。它能在部署前做变更检查，但动态分支可能没有实际执行。

运行时血缘 ​

来自查询引擎、调度器、计算框架或作业埋点，回答“这次实际读写什么”。它能绑定 run、时间和状态，却可能只覆盖已运行路径。

两者应并存：设计边用于预防，运行边用于证据。差异需要结合分支条件解释；设计允许读取三张表，而这次只读取两张，既可能是合法分支，也可能是采集缺口或执行错误。

3. 一条可审计的运行事件 ​

下面是本课自定义的简化事件结构，标识和版本均为示例，不是 OpenLineage 协议负载。逻辑 job ID 保持稳定，代码版本和 attempt 分开记录：

json
{
  "run_id": "2026-08-03/daily-report/attempt-2",
  "job_id": "analytics.daily-report",
  "job_version": "v17",
  "event_id": "example-daily-report-attempt-2-complete",
  "started_at": "2026-08-03T06:01:00Z",
  "ended_at": "2026-08-03T06:08:20Z",
  "status": "complete",
  "inputs": [
    {"asset": "missions_clean", "version": "snapshot-2026-08-03T05:55Z"}
  ],
  "outputs": [
    {"asset": "daily_mission_summary", "version": "partition=2026-08-02/run=attempt-2"}
  ],
  "code_version": "example-release-v17",
  "schema_version": "3"
}

生产实现还要处理 start/complete/fail、重试 attempt、幂等事件 ID、乱序到达和访问控制。血缘事件本身也可能泄露表名、字段分类或租户信息。

若接入 OpenLineage 对象模型，需遵循对应版本的 namespace/name、UUID runId、事件类型和 facets schema；同一次 run 的 START/COMPLETE 更新共用 runId。采集器报告完成不自动证明输出已事务发布，还应保存存储提交 ID 和发布证据。不能仅按事件到达顺序把迟到的 START 覆盖已知 COMPLETE。

4. SQL 正则不能可靠解析血缘 ​

用正则提取 FROM 和 JOIN 会在以下情况失效：

  • CTE、嵌套查询和 correlated subquery；
  • quoted identifiers、catalog/schema 和临时视图；
  • MERGE、UPDATE、动态 SQL 与宏；
  • UDF 内部读取、外部函数和存储过程；
  • 引擎重写后的实际物理来源。

优先级通常是：

  1. 查询引擎/执行框架提供的结构化计划或事件；
  2. 使用完整 SQL parser 和方言 AST；
  3. 编排器声明的输入输出；
  4. 作业入口/出口显式埋点；
  5. 人工补录并标记置信度。

不同采集器可能产生冲突边。保存来源、置信度和观察时间，不要静默合并成一条“真相”。

5. 字段级血缘需要表达式语义 ​

表级血缘只能说某表受影响。字段级血缘进一步记录：

text
daily.completed_count
  ← count(distinct missions.mission_id)
     where missions.status in COMPLETED_STATUS_SET(v4)

daily.completion_rate
  ← completed_count / eligible_count

区分直接值来源与间接控制依赖：mission_id 贡献去重计数，status 决定哪些行计入，所以更改状态规则也会改变计数。常量、UDF 与多输入表达式同样要保留语义。“间接”是一种依赖类型，不等于“未知”；解析不出时应另记 unknown。参见 OpenLineage 字段血缘 facet。

字段级血缘昂贵，应优先覆盖 CDE、关键指标、敏感字段和高风险模型特征。

6. 影响分析不是简单 BFS 列表 ​

图遍历能找候选下游，但实际优先级还取决于：

  • 边是否当前有效、最近是否运行；
  • 变更的是名称、类型、单位、值域还是历史语义；
  • 下游是否只读未变字段；
  • 资产是实验、内部报告还是外部决策；
  • 是否有缓存、导出、模型和人工副本；
  • owner、SLO、敏感分类和变更窗口。

影响报告应输出路径与证据：

text
changed field → expression → output field → report/model → owner
last successful run / active consumers / severity / confidence

图中有环、别名和重复边，遍历要维护 visited 集并限制版本/时间范围。

下面对已选定版本的候选边做遍历。时间字符串统一使用同一精度的 UTC ISO 格式，按证据被观察到的时间裁剪；生产中应解析成时间类型。函数为每个候选返回一条代表路径，并传播该路径的未知标记：

python
from collections import defaultdict, deque

# source field/version, target field/version, run evidence, observation time, confidence
edges = [
    ("missions@v3.status", "summary@v2.completed", "run-17", "2026-08-03T06:00:00Z", "observed"),
    ("summary@v2.completed", "summary@v2.rate", "run-17", "2026-08-03T06:00:00Z", "observed"),
    ("summary@v2.rate", "report@v5.rate", "run-18", "2026-08-03T07:00:00Z", "observed"),
    ("summary@v2.rate", "export@v1.rate", "manual-1", "2026-08-03T07:00:00Z", "unknown"),
    ("missions@v2.status", "report@v4.rate", "run-10", "2026-08-02T07:00:00Z", "observed"),
]

def impacted(start, observations, as_of):
    adjacency = defaultdict(list)
    for src, dst, evidence, observed_at, confidence in observations:
        if observed_at <= as_of:
            adjacency[src].append((dst, evidence, confidence))
    paths, queue = {start: ([], False)}, deque([start])
    while queue:
        node = queue.popleft()
        path, uncertain = paths[node]
        for target, evidence, confidence in adjacency[node]:
            if target not in paths:
                paths[target] = (path + [(node, target, evidence)],
                                 uncertain or confidence != "observed")
                queue.append(target)
    return {node: value for node, value in paths.items() if node != start}

impact = impacted("missions@v3.status", edges, "2026-08-03T08:00:00Z")
print(sorted(impact))
# ['export@v1.rate', 'report@v5.rate', 'summary@v2.completed', 'summary@v2.rate']
assert impact["export@v1.rate"][1] is True
assert "report@v4.rate" not in impact

这不是完整影响判定。示例不收集血缘、不验证发布状态，也不枚举全部路径；若同一资产有多条证据路径，应保留原图供进一步核查。版本过滤避免把旧报告算成本次后代，unknown 导出仍进入人工调查，不能因为置信度低就从范围中消失。

7. 三种典型用途 ​

变更前 ​

检查 schema/语义变更，定位活跃消费者，安排兼容窗口和回归样本。

事件响应 ​

从错误输出反向追溯实际 run 与输入版本，再正向查找已污染报告、特征、模型和导出。

隐私与删除 ​

追踪敏感字段的派生、缓存与外发位置。血缘能给候选范围，但不能证明所有副本都已发现；还要结合访问日志、存储扫描和资产清单。

8. 完整性与新鲜度 ​

监控：

  • 生产 runs 发出血缘事件的覆盖率；
  • complete run 是否都有输入、输出和版本；
  • 目录中活跃资产是否有近期边；
  • 设计与运行边差异；
  • 字段级解析失败率和 unknown 表达式；
  • 事件延迟、重复和孤立节点。

血缘缺边会给影响分析虚假的安全感。查询结果应展示覆盖范围和置信度，而不是只画一张漂亮图。

9. 变更门禁 ​

text
[ ] 当前与近期运行时下游已识别
[ ] 关键字段级路径已核对
[ ] 活跃 owner 已确认或收到通知
[ ] 兼容策略与回滚版本已准备
[ ] 回归样本覆盖旧/新语义
[ ] 外发、模型和缓存已纳入
[ ] 未知/低置信血缘已有人工补查

常见误区 ​

  • 表到表箭头就是完整血缘：缺少版本、run 和字段表达式。
  • 解析 SQL 可覆盖所有转换：动态代码与引擎行为需要其他信号。
  • 画出所有下游就完成影响分析：还要按活跃度、字段和业务风险筛选。
  • 血缘能证明删除完成：未接入系统和人工副本仍需其他发现手段。

练习 ​

  1. 为同一 job 的失败、重试和回填写三条运行事件。
  2. 找一个含 CTE、子查询和 UDF 的 SQL，比较正则与 AST 解析结果。
  3. 为完成率指标画字段级表达式血缘，并标出业务规则版本。
  4. 模拟一个单位变化，生成带 owner、活跃度和置信度的影响报告。

小结 ​

可用血缘不是静态箭头，而是带运行、版本、字段语义和证据来源的图。它让变更和事件响应从“可能有关”推进到“哪次运行、哪列输出、哪些活跃决策受到影响”。

下一章讨论 Data Mesh：当领域增多时，如何分散数据责任，又不失去互操作、平台能力和共同治理。

Built with VitePress | Software Systems Atlas

Copyright 2026 Steven Yang