在 CRM 有兩種 那篇，我提到自己當年撈名單選在 ETL 那邊，主要原因是怕影響正式系統：排程、盤點都接在同一座資料庫上，撈名單的查詢直接打過去，就是在已經很忙的資料庫上再加一份壓力。
這是 ETL 存在的第一個理由：把分析用的查詢搬離正式系統。 第二個理由是前幾篇一直在講的：名單需要的資料散在好幾個系統，總要有一個地方把它們放在一起。
這一篇整理這個「另外的地方」要怎麼規劃。整合篇前四篇講的東西，在這裡會全部用上。
分三層
ETL 最常見的規劃是把資料分層，每一層只做一件事：
| 層 | 做什麼 | 例子 | 誰會直接用 |
|---|---|---|---|
| 原始層 | 照搬來源系統的資料，不改內容 | 訂單表、會員表、開信紀錄，各一份副本 | 只有工程師，用來追查問題 |
| 整理層 | 合併身分、統一格式、去除重複 | 同一個人的三筆會員資料合成一筆；時間統一成同一個時區 | 工程師寫名單和報表時的來源 |
| 應用層 | 算好的成品 | 「近 90 天消費金額」「本檔名單」「每週營收報表」 | 行銷、報表使用者、AI |
為什麼要分層，而不是直接從原始資料撈名單？
- 名單和報表的數字才會一致。 如果名單從原始層撈、報表也從原始層撈，兩邊各自處理一次身分合併和時區，處理方式只要差一點，「近 90 天消費的會員有幾個」在名單和報表上就會是兩個數字。從同一個整理層出發，算法只有一份。
- 出問題時找得到原因。 原始層保留來源的原貌。名單錯了，可以一層一層往回查，看是整理時出錯，還是來源本來就錯。
- 身分合併只做一次。 用手機或 email 合併會員，這件事放在整理層做一次，所有下游都用同一個結果。
全量還是增量
每次 ETL 是把資料全部重搬一次（全量），還是只搬上次之後新增或修改的部分（增量）？
我當年兩種都有，不同的資料用不同做法。這其實是常態，因為兩種做法各有適合的資料：
| 全量 | 增量 | |
|---|---|---|
| 做法 | 每次整份重搬，覆蓋舊的 | 只搬「上次之後」變動的部分 |
| 適合 | 筆數少、常被修改的資料，例如商品分類、門檻設定 | 筆數多、只會新增的資料，例如訂單、開信紀錄 |
| 好處 | 簡單，不會漏 | 快，對來源系統的壓力小 |
| 要小心 | 資料一多就越跑越久 | 刪除抓不到、晚到的資料可能漏掉 |
增量最常見的坑是判斷「上次之後」的依據。如果用「更新時間」欄位判斷，那這個欄位一定要每次修改都會更新；有任何一個地方改資料時沒有更新它，那筆修改就永遠不會被搬過去。用 Logstash 從資料庫增量同步，踩到的就是這一類問題（見Logstash JDBC 同步的七個坑）。
不管全量還是增量，都要能重跑：某一天的資料錯了，要能只重跑那一天，而且跑兩次的結果一樣（見 ETL）。
排程怎麼排
我當年的 ETL 一天跑好幾次。排程要考慮三件事：
1. 抽資料的時候，一樣會打到正式系統。 這是很容易忽略的地方。ETL 把撈名單的查詢搬離了正式系統，但「把資料抽出來」這一步本身，還是要讀正式系統的資料庫。所以抽資料的時段要避開正式系統最忙的時候，或者改讀資料庫的唯讀副本，讓正式系統的主資料庫不受影響。增量也是為了這個：每次只讀變動的部分，壓力比全量小很多。
2. 有先後順序。 名單要用到消費紀錄，那「算名單」就一定要排在「搬完消費紀錄」之後。順序沒排好，名單會用到上一輪的資料。排程工具要能表達「A 跑完才跑 B」，而不是只靠時間錯開。
3. 對齊檔期。 名單要在寄送前用最新一輪的資料算。如果 EDM 排在早上十點寄，最後一輪 ETL 就要在那之前跑完並通過檢查（見怎麼觀察資料有沒有正常進來）。
名單送出之前：最後一道過濾
算好的名單要送到 EDM 系統。常見的送法有三種：匯出檔案上傳、程式透過 API 推過去、EDM 系統直接來讀應用層。不管哪一種，送出前都一定要做一件事：
用唯一的同意來源，再過濾一次退訂。
名單是在某個時間點算的，從算好到寄出之間，可能有人退訂了。I01 講過，退訂後還寄行銷信，會違反個資法第 20 條「應即停止」的規定。所以這道過濾不能放在算名單的時候，要放在送出前的最後一步。
AI 和 MCP 的角色
分三層的規劃，剛好決定了 MCP 該接哪裡：接應用層，不接原始層。
- 應用層的東西都是算好的、有定義的：「近 90 天消費金額」的意思是固定的。AI 透過 MCP 拿這些指標，不會自己猜怎麼算。
- 原始層的資料還沒合併身分、時區也還沒統一。讓 AI 直接查原始層，它算出來的「會員數」可能跟報表對不上，而且沒人知道為什麼。
- 資料截止時間，就是最後一輪 ETL 跑完的時間。MCP 工具回傳時一起附上。
行銷想要一個應用層還沒有的新條件時，AI 也幫得上忙：把行銷的描述翻成 SQL 草稿，交給工程師確認後再加進應用層。這樣新條件只要定義一次，之後行銷和 AI 都能直接用。這也是我當年「請工程師寫 SQL」那一步可以省下來的地方：工程師不用每次從頭寫，只需要審 AI 寫好的草稿。
整合篇回顧
這五篇串起來，是一條完整的路：
- CRM 會碰到哪些資料：身分、交易、互動、同意，誰說了算
- 紀錄怎麼產生：埋點、事件規格、匿名訪客怎麼接回會員
- 企業系統之間怎麼交換資料：六種方法，看資料多晚到可以接受
- 怎麼觀察資料有沒有正常進來：五種檢查，每條資料流要有負責人
- 這一篇：在哪裡算、怎麼分層、怎麼排程、送出前怎麼過濾