資料的生命週期

從一次點擊到一個決策：這趟旅程

台北，週二早上 8 點 02 分。一位顧客打開一款叫 BeanCount 的咖啡店 App，點下「買一杯拿鐵」，付了新台幣 120 元。對她來說，故事到此結束——咖啡正在路上。但對一個資料團隊而言，這一次點擊才是一趟漫長、且大多看不見的旅程的起點。到了中午，這一次點擊，連同數以百萬計的其他點擊，也許能幫忙回答這樣的問題：「我們新的早晨促銷到底有沒有賺錢，還是只是把本來就賣得掉的咖啡白白送出去？」

這篇指南就是那趟旅程的地圖。我們會跟著一次點擊，從它誕生的那一刻起，穿過搬運它、儲存它、重新塑形它的各個系統，一路走到主管螢幕上的一張圖表，以及一個會改變 App 的決策——而這又會產生新的點擊，於是整件事再轉一圈。這個不斷重複的圓圈，就是人們所說的資料生命週期；而沿途承載資料的那一整套相連機具，則稱為資料管線。

在我們放大任何單一環節之前，先一眼看見整道弧線會很有幫助。在大多數公司裡，大多數資料都會走過同樣的六個階段，順序大致如下：

產生——某件事發生了（一次點擊、一筆付款、一個感測器讀數），並產生一筆紀錄。
汲取（ingestion）——那筆紀錄從運行中的 App 被搬到一個專為分析而建的地方。
儲存——它落腳在倉儲或資料湖裡，與數十億筆同類紀錄並列。
轉換——原始、雜亂的紀錄被清理、合併、重塑成可信賴的表格。
分析與建模——人們探索這些表格、儀表板將它們彙總、機器學習模型則從中學習。
決策——某個人或某個系統採取行動，產品改變，於是新鮮的資料又開始流動。

資料在哪裡誕生

在資料能被分析之前，它得先在某處誕生。在一家現代公司裡，它同時在許多地方誕生。最顯而易見的來源是產品本身：顧客看到的每一個畫面都可能發出事件（event）——一筆筆說明「發生了什麼、何時發生」的小紀錄。我們那次拿鐵點擊就是這樣一個事件。此外還有交易（那筆真正的 120 元付款）、營運資料庫（顧客帳號、菜單、門市庫存）、伺服器的背景日誌、來自裝置與感測器的訊號，以及向第三方購買或取得的資料，例如金流商、地圖供應商或廣告平台。

所謂事件，不過就是一筆帶有時間戳記、記錄「發生了一件事」的紀錄，通常寫成一小束欄位。你不需要會看程式也能理解它；把它想成日記裡的一行字。下面大致就是我們那次拿鐵點擊，在它被產生的那一瞬間可能長成的樣子：

event = {
  'user_id':   'u_88213',
  'event':     'purchase',
  'item':      'latte',
  'price_twd': 120,
  'store':     'taipei-da-an',
  'ts':        '2026-06-27T08:02:14+08:00'
}

一個事件：那次拿鐵點擊被擷取成六個欄位——誰、做了什麼、多少錢、在哪、以及確切的時間。

這些資料有些是結構化的——整齊的列與欄，就像上面那個事件。有些是非結構化的——產品照片、顧客評論文字、客服通話錄音——它們較難塞進表格，卻越來越有價值。但無論哪一種，有一條規則主宰著下游的一切：垃圾進、垃圾出（garbage in, garbage out）。如果價格在這裡就記錯了，之後再聰明的分析也救不回來。確保品質最便宜的地方就是源頭，這也是為什麼團隊會如此在意事件是怎麼被定義與記錄的。

OLTP 與 OLAP：兩種非常不同的工作

這裡有一個真正形塑現代資料技術棧的關鍵想法：負責「運行你的 App」的資料庫，和負責「回答你的問題」的資料庫，想要的東西恰好相反，所以我們通常把它們分開。這個區分有兩個醜醜的縮寫，值得花一次力氣記住，因為它們解釋了接下來的整個版圖。

OLTP 是「線上交易處理」（online transaction processing）的縮寫。這是替企業做即時工作的資料庫。當我們的顧客付款時，一個 OLTP 系統必須在幾毫秒內，精準地收取 120 元、把一杯拿鐵標記為已售出、並扣減該門市的牛奶庫存——只動到寥寥幾列，但要完美無誤、就在當下，同時為成千上萬名顧客做這件事。它被最佳化來「極快地讀寫極小片段的資料」，而且絕不弄丟任何一筆交易。

OLAP 是「線上分析處理」（online analytical processing）的縮寫。這是為「問題」而建、而不是為「銷售」而建的資料庫。像「過去三個月，每間門市、每個小時的拿鐵平均銷量是多少？」這樣的問題，得掃過數百萬列再加總起來。你不需要它在一毫秒內回答——幾秒鐘就夠了——但它必須一次嚼完龐大的歷史資料。OLAP 系統正是為此而最佳化：在巨大的表格上做大量讀取。

汲取與儲存

汲取（ingestion）是一件不光鮮的工作：把資料從它誕生的地方（App、OLTP 資料庫、第三方服務）搬到它將被分析的地方。大致有兩種風格。批次汲取（batch）按排程一塊一塊地收集資料——例如每天凌晨兩點把昨天所有的銷售複製一份。它簡單、便宜，對多數報表來說也夠用。串流汲取（streaming）則持續地搬運每一個事件，在它發生後幾秒內就送達——當「分秒必爭」時才需要，例如在下一筆刷卡之前抓出一張盜刷的卡。

感受一下規模會很有幫助，因為這正是為什麼這件事需要真正的工程，而不是一個大家共用的試算表。假設 BeanCount 有 50 萬名日活躍使用者，平均每位使用者一天產生約 40 個事件（開啟 App、瀏覽、點擊、付款）。那麼每天與每秒的量大約是：

\text{events/day} = 500{,}000 \times 40 = 2.0 \times 10^{7} \\[6pt] \text{events/second} = \frac{2.0 \times 10^{7}}{86{,}400} \approx 231

一天兩千萬個事件——平均每秒約 231 個，全天無休、日復一日。正是這樣的量，讓汲取與儲存成為「工程化的系統」，而不是一個裝著檔案的資料夾。

這一切最後落在哪裡？通常是三種「家」之一。資料倉儲就像一座井然有序的食品儲藏室：資料進來時已經清理好、結構化成表格，非常適合快速的 SQL 分析——但你得先把東西整理好才能放進去。資料湖比較像一座巨大的車庫：你可以便宜地把任何形狀的原始資料（日誌、影像、JSON）通通倒進去，組織的事之後再煩惱。湖倉（lakehouse）則是越來越流行的混血兒，試圖同時給你車庫那種便宜又有彈性的儲存，以及食品儲藏室那種快速又可靠的查詢。

轉換與建模

原始資料幾乎從來都不能直接拿來回答問題。我們那堆「一天兩千萬個事件」裡，充滿了重複、做到一半的工作階段、用不同幣別記的價格，以及去年春天就改過的門市代碼。轉換（transformation）就是讓原始紀錄變成可信賴表格的階段：清理錯誤的值、把事件與顧客和門市資訊合併起來，並把數百萬次點擊彙總成整齊的摘要。目標是產出整齊資料表格——每一列代表一件事、每一欄代表一個屬性——後續每一步都默默仰賴它們。

這個轉換說的是什麼語言？絕大多數時候是 SQL——這個有數十年歷史的查詢語言，至今仍是資料工作的通用語。一個叫 dbt 的現代工具，讓團隊能把這些轉換寫成「有版本控制、可測試」的 SQL 檔案，這種做法常稱為分析工程（analytics engineering）。來嚐一小口：把原始事件變成「每間門市每日銷售摘要」。

SELECT
  store,
  date_trunc('day', ts) AS day,
  count(*)         AS orders,
  sum(price_twd)   AS revenue_twd
FROM sales
WHERE event = 'purchase'
GROUP BY store, day
ORDER BY day;

一個小小的轉換：把數百萬筆購買事件，彙整成「每間門市、每一天一列」的整齊表格——這正是儀表板或模型真正用得上的那種表。

分析、商業智慧與機器學習

現在我們終於來到回報的時刻。一旦資料乾淨又整齊，就有三種「人加機器」的組合把它派上用場，而大多數公司三種都做。第一種是分析：由人提出開放式問題並加以探索——統計學家稱之為探索性資料分析，也就是「先看清楚再行動」的功夫。這也是統計學工具的家。

第二種是商業智慧（business intelligence）：把那些整齊的表格變成全公司一眼就能讀懂的儀表板與報表，用商業智慧工具打造而成。門市店長不會去跑 SQL；她每天早上打開一張儀表板，看昨天各門市的營收，並把任何異常標示出來。好的商業智慧讓同一份可信賴的數字人人可用，終結每天「到底誰的試算表才對」的爭吵。

第三種是機器學習：不是由人來讀表，而是由一個模型從表中學習規律，自動做出預測或決策——哪些顧客快要不再消費、那杯拿鐵旁邊接下來該推薦哪種糕點。為真實顧客運行的模型，通常會從共用的特徵庫取用輸入，好讓「訓練模型用的數字」與「線上即時用的數字」彼此一致。

無論用哪種工具，輸出的最終目的都是導向一個決策——「早晨促銷讓營收提升 6%，所以全面推行吧」。在你照著一張圖採取行動之前，有兩點誠實提醒。第一，一張儀表板的可信度，頂多等於它背後那份轉換資料的可信度；建立在錯誤合併之上的漂亮圖表，只是「很有自信地錯」。第二，儀表板上的一個規律——促銷日的銷售比較高——只是一種相關，並不能證明是促銷「造成」了那些銷售；說不定那些剛好都是發薪日的週末。確立因果難到足以自成一個學習軌。帶著這份警覺，決策改變了 App，改變後的 App 產生新的點擊，於是生命週期的迴圈閉合了。

誰負責什麼：資料團隊

你現在已經看過旅程的每一個階段，因此終於能搞懂那些職稱了。大致上，每個角色負責你剛剛走過的管線中的一段。職稱在不同公司之間差異極大——而在小型新創裡，可能是同一個疲憊的人戴上全部這些帽子——所以這些標籤請寬鬆看待。重要的是工作本身，而不是名牌。

資料工程師（data engineer）——打造水電管路：汲取、儲存，以及可靠地搬運資料的管線（從產生到儲存那一段）。
分析工程師（analytics engineer）——負責轉換：用 SQL 與 dbt 把原始表格變成乾淨、有文件、經過測試的資料模型。
資料分析師（data analyst）——活在分析與商業智慧裡：回答商業問題、打造人們賴以為據的儀表板。
資料科學家（data scientist）——把統計、實驗與機器學習，用在關於因果、預測與不確定性的更難問題上。
機器學習工程師（ML engineer）——把有潛力的模型送完最後一哩，變成可靠、受監控的生產軟體。