数据血缘（data lineage）是「哪些来源，经过哪些转换，产生哪个结果」的可追溯关系。它不只服务大型资料平台：只要本机周报会重跑、交接或被问「这个数从哪来」，就需要一条最小血缘；差别只在记录深度，不在公司规模。
没有血缘时，真正浪费的是判断时间
想像一份月报数字突然下降。你手上有 orders_july.xlsx、clean_orders.csv、三个 SQL 草稿与最终 HTML，却不知道：清洗档用了哪版原始资料？退款在哪一步排除？更新原始档后该重跑哪些查询？
没有血缘，团队只能靠档名、修改时间与作者记忆猜测。血缘把猜测改成依赖关系：
orders.xlsx
→ 01_clean_orders（型别、状态清理）
→ 02_monthly_revenue（月份、营收口径）
→ 03_segment_summary（市场分组）
→ Report / HTML
OpenLineage 把 lineage 建模为 Dataset、Job 与 Run：Job 消费或产生 Dataset，Run 则是某个 Job 的一次实际执行。这个模型很适合提醒我们：知道「A 依赖 B」还不够，还应知道是哪次执行与哪段转换形成结果。OpenLineage Object Model
本机分析的最小血缘应记什么
不必先导入企业级 metadata platform。对一份会重用的分析，先保留五项：
- 来源识别：档名／连线、工作表或资料表，以及分析时点。
- 转换逻辑：可重跑的 SQL，不只留下输出 CSV。
- 中间结果名称：用
clean_orders而非final_v3_new表达用途。 - 输入／输出关系：每一步读什么、产出什么。
- 执行与限制：何时跑、是否成功、资料新鲜度与已知缺口。
这五项能回答三种常见问题：上游档案换了要重跑什么、某个错误会污染哪些下游、报告数字能否回到具体 SQL。
什么时候值得建 DAG
可以用「重用、复杂、影响」三项判断：
| 情境 | 建议记录 |
|---|---|
| 一次性、单一 JOIN、逻辑清楚 | 保留一段 SQL 与来源即可 |
| 多步清洗，中间结果会重用 | 命名持久 SQL 与依赖 |
| 上游常更新，需要选择性重跑 | 建立 DAG／Source Run |
| 正式报告或高影响指标 | 再加 Plan、执行 evidence 与 limitations |
别为了形式把一段简单 SQL 拆成十个节点。血缘的目的，是降低除错与重跑成本；若图比逻辑更难读，就拆过头了。
Lantide Data 如何承载本机 SQL 血缘
在 Lantide Data 中，持久 SQL 分页可保存转换逻辑，查询结果可作为同一工作区内的快取中间表；当下游 SQL 引用上游快取，Source Run 可依依赖顺序重跑，Lineage Graph 则显示档案、持久分页与快取间的关系。操作可参考 快取与 Source Run 指南 与 使用者指南 §8。
这里有两个重要边界：
- 快取是工作区内的中间结果，切换工作区或重新启动后可能清除；它不是永久数仓资料表。
- Agent 后台查询形成的 agent 快取不一定支援 Source Run；需要稳定重跑时，应使用持久 SQL 分页建立清楚依赖。
Lantide 的优点是让本机档案、SQL、Plan 与 Report 留在同一分析工作面，血缘可直接服务审阅与交付；它不取代跨系统企业 catalog、排程器或全公司的 metadata governance。
一份可直接采用的命名规则
用「序号 + 动词／成果 + 粒度」命名：
01_clean_orders_order_grain02_revenue_by_month03_retention_by_signup_cohort
并在 Plan 写下每一步的 input、output、grain 与 checkpoint。这比 query_final_2 多几个字，却能让下一位接手者少重建一次整个分析脉络。
结语
先挑一份每月会重跑的本机报表，画出「原始档 → SQL → 中间结果 → Report」四层，再确认每个箭头都有可重跑逻辑。这就是足以产生价值的最小 lineage；等依赖与团队规模真的扩大，再升级到平台级方案。