數據血緣（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；等依賴與團隊規模真的擴大，再升級到平台級方案。