資料工程生命週期:讀《Fundamentals of Data Engineering》Ch.2

上一篇給了定義,這一章給的是全書的骨架 —— 資料工程生命週期(data engineering lifecycle)。這本書最有價值的貢獻,就是用這個框架把「資料工程在做什麼」講清楚:五個階段 + 六條暗流(undercurrents)。讀懂這張圖,後面九章都只是在它上面長細節。

五個階段:資料從產生到被用

生命週期把「原始資料 → 有用的資料」這段切成五個階段:

階段	在做什麼	對應我寫過的
Generation 生成	資料在來源系統產生(DB、App、感測器、事件)	[kafka-intro|Kafka]
Storage 儲存	資料落地的地方 —— 橫跨中間三個階段	Medallion 分層
Ingestion 攝取	把資料從來源搬進系統	Kafka、批次載入
Transformation 轉換	清洗、建模、聚合成可用形狀	dbt、Spark
Serving 服務	把資料交付給分析、ML、產品	BI / 報表 / 特徵

為什麼儲存是「橫跨」的,不是一個獨立步驟

這是這章最該記住的細節:儲存不是「攝取完、轉換前」插進去的一站,而是貫穿攝取、轉換、服務三個階段的底層。資料在這三段裡反覆被讀出、寫回 —— 攝取要寫進儲存、轉換要從儲存讀出再寫回、服務要從儲存取出。所以書把它畫成橫跨的一條,而不是排在中間的一格。

這跟我寫 Medallion 架構的體會完全對上:Bronze / Silver / Gold 不是三個「步驟」,而是資料在生命週期裡流經的三層儲存。

六條暗流:看不見、卻決定系統會不會垮

五個階段是「看得見的管線」,而 undercurrents 是貫穿每一階段的底層實踐 —— 書用「暗流」這個詞很傳神:它們不在表面,卻決定整條河的流向與安危。

Undercurrent	在管什麼
Security 安全	最小權限、加密、別把帳密寫死
Data Management	治理、品質、血緣、主資料、隱私
DataOps	自動化、可觀測性、事件應變(資料界的 DevOps)
Data Architecture	系統怎麼設計、權衡與取捨
Orchestration 編排	把任務依相依排程、監控、重試
Software Engineering	把工程紀律帶進資料工作

注意 Orchestration 就是 Airflow 的家 —— 它不是某個階段,而是橫貫所有階段的暗流。這解釋了為什麼 Airflow 那麼核心:它管的是整條生命週期的「節奏」。

反思

這個框架最大的價值,是給了我一個「定位用」的座標系

讀完這章我做的第一件事,是把過去半年寫的每個工具丟進這張圖:Kafka 落在生成/攝取、Spark 與 dbt 在轉換、Medallion 是儲存的分層、Airflow 是 orchestration 暗流。突然之間,那些原本各寫各的筆記,在同一張地圖上有了位置。 框架的價值往往不是教你新東西,而是給你一個座標系,讓你看清自己已知的東西彼此怎麼接 —— 這章對我就是這個作用。

暗流,才是資淺與資深的分水嶺

我越來越覺得,五個階段是「入門就看得到」的東西 —— 誰都知道資料要攝取、要轉換、要服務。真正拉開差距的是 undercurrents:有沒有把安全(別 hardcode 帳密,呼應我寫 Connection 那篇)、可觀測性、資料品質、血緣這些「看不見的」做進去。一個 demo 跟一個能在半夜不出事的生產系統,差別幾乎全在暗流。新手炫的是管線跑通,老手守的是暗流。

如果只能先補強一條暗流,我選 DataOps

書把六條暗流並列,但要我排優先序,我會把 DataOps 放前面 —— 自動化、可觀測性、事件應變。理由很實際:資料系統最大的痛不是「建不出來」,是「壞了不知道、知道了難查、查到了難復原」。這跟我在 Airflow 系列反覆強調的冪等、可重跑、別讓資源默默耗乾是同一件事。把 DataOps 做起來,等於給整條生命週期裝上儀表板與保險絲 —— 其他暗流的問題,也才看得見、修得動。