資料的最後一哩:服務給分析與 ML,讀《Fundamentals of Data Engineering》Ch.9

前面幾章一路走過源頭、儲存、擷取、建模 —— 但這些辛苦,只有在有人真的拿去用的那一刻才變現。這章講生命週期的最後一站:服務(Serving)。而它的第一原則,只有兩個字。

最高原則:信任

書把話講得很重:沒人會用他不信任的資料。 一張數字對不上、或昨天壞掉沒人發現的儀表板,只會讓人默默退回「憑感覺」或自己開 Excel —— 那你前面整條 pipeline 就白做了。所以服務這一站,資料品質與信任不是加分項,是及格線。實務上這代表:對關鍵資料立SLA / SLO(多新、多準、壞了多久內修好)、把品質監控擺在最靠近消費者的地方。

信任是服務的地基,下面所有形式都蓋在它上面。

服務會扇出到很多張嘴

「服務資料」不是單一動作,而是同一份建模好的資料,餵給形態完全不同的消費者:

分析的三種形態,別搞混

上圖前兩個都叫「分析」,但需求天差地遠。書分成三種:

形態	給誰、幹嘛	對即時的要求
商業分析	內部決策:報表、儀表板、探索	低(多半批次夠)
營運分析	當下要行動:即時監控、線上運營	高(要即時,見 串流)
嵌入式分析	給外部客戶看:產品內的數據頁	中~高,而且對正確性零容忍

最容易踩的坑是把嵌入式當成內部報表做 —— 它是給客戶看的,算錯一個數字是產品事故,不是「內部再改就好」。

服務給 ML:DE 的責任邊界

另一大消費者是機器學習。這裡要分清楚 DE 該負責到哪:DE 通常負責把資料弄成乾淨、可信、可重現的特徵與訓練資料(常透過 feature store 統一管理),讓模型訓練與線上推論拿到同一套特徵;再往後的建模、調參是 ML 工程師的事。書提醒一個關鍵:訓練用的特徵和線上服務的特徵必須一致,否則就是那個惡名昭彰的 training-serving skew。DE 在這條線上的價值,還是老話 —— 把資料弄得可信、可重現。

Reverse ETL:讓資料不只是被「看」

傳統服務是把資料拿去看(儀表板)。Reverse ETL 反過來,把倉儲裡算好的結果推回營運系統 —— 例如把「高流失風險客戶」名單灌回 CRM、把受眾包推到廣告平台。資料因此不只是報表,而是直接驅動行動。它讓 生命週期閉環:資料從營運系統來,轉一圈,又回營運系統去。

一個數字,一個定義:語意層

回到「信任」。信任最常見的殺手,是同一個「營收」,三個工具算出三個數字 —— BI 一版、Notebook 一版、產品端一版,誰都不信誰。語意層(metrics layer) 就是來解這個的:把指標的定義集中、只定義一次,所有工具都來這裡拿:

反思

沒有信任,前面整條 pipeline 都白做

這章點醒我一件常被工程師忽略的事:資料的價值不在「算出來」,在「有人信、有人用」。 我看過做得很漂亮的 pipeline,最後沒人用 —— 因為某次數字對不上、或壞了三天沒人告警,大家就默默退回自己的 Excel 和直覺。從此那個儀表板變成沒人開的墓碑。教訓很硬:服務這一站的品質與信任,值得你花的力氣不亞於前面任何一段 —— 因為它是唯一把前面所有努力變現的地方。把監控與 SLA 擺在最靠近消費者的地方,不是龜毛,是保護整條 pipeline 的投資。

「為什麼兩張報表數字不一樣」——語意層是我最想早點導入的東西

這個問題我被問到怕。同一個「活躍使用者」,BI 一個數、老闆自己拉一個數、產品端又一個數,每次開會都在對數字而不是做決策 —— 信任就是這樣一次次被磨掉的。癥結幾乎都一樣:指標的定義散在各個工具裡,各算各的。 語意層(dbt 的 metrics、或 BI 的語意模型)把定義集中成一份單一事實來源,是我認為最被低估、投報率卻極高的一步。它賣的不是技術,是「大家終於在同一個數字上吵對的事」。

Reverse ETL 讓我重新想「服務」的定義

以前我對「服務資料」的想像就是儀表板 —— 把資料端出去給人看。Reverse ETL 打開了另一半:資料可以直接回去驅動營運,把「高風險客戶」灌回 CRM 讓業務今天就打電話、把受眾推回廣告平台。這讓資料從「被觀賞」變成「會行動」,也讓 生命週期真正閉環。對我來說它的啟發是:別把資料團隊的產出想成報表,想成「產品」 —— 一個會被消費、要負責、能驅動行動的產品。這也呼應這一整章:服務,才是資料工程真正面對使用者的那一面。