ETL 是擷取（Extract）、轉換（Transform）、載入（Load）的縮寫，指把分散在官網、訂單、會計、POS 等系統裡的資料取出，依業務規則清理、統一格式與計算，再載入資料倉儲或報表專用的資料庫，讓報表有一份口徑一致的資料可用。要不要建立 ETL 流程、選哪一類 etl 工具，看資料來源數量、更新頻率與轉換規則的複雜度：來源少、每月更新的，試算表內建的查詢功能可能就夠；來源多、要每天自動更新或保留長期歷史的，再評估雲端資料平台或客製排程程式。
ETL 的三個步驟各在做什麼
Microsoft 的架構說明把 ETL 定義為一種資料整合程序，用來把不同來源的資料整合到統一的資料存放區。三個步驟要決定的事情各不相同：
擷取：從來源系統取出資料
來源可能是官網資料庫、電商後台、ERP、會計軟體或共用試算表。依 Google Cloud 的說明，擷取後的資料會先放進暫存區。這一步要決定每次取出全部資料，還是只取上次之後異動的部分；資料量大時，需要有修改時間這類可判斷異動的欄位。以 Microsoft Fabric 的 Data Factory 為例，複製工作支援大量複製、增量複製與變更資料擷取（CDC）。
轉換：依業務規則清理與計算
Microsoft 列出的常見轉換作業包括篩選、排序、匯總、聯結、清除、去除重複與驗證資料。真正要花時間討論的是規則：取消單與退貨怎麼扣除、同一位客戶在不同系統的編號怎麼對應、時區統一成哪一種、金額含不含稅。
載入：寫入目的地
整理後的資料寫入資料倉儲或報表用資料庫，要決定是覆蓋、附加還是更新，以及中途失敗時怎麼處理，避免報表讀到一半新、一半舊的資料。
ETL 和資料倉儲是什麼關係
Google Cloud 把資料倉儲定義為可分析多種來源的結構化與半結構化資料、並製作報表的企業系統，它把新舊資料集中在一處，方便查看不同時間點的狀態。ETL 就是把資料送進資料倉儲的管線，Google Cloud 也提到 ETL 常用於把資料移到資料倉儲。
為什麼不直接查營運系統？Google Cloud 的說明提到，把歷來資料與營運資料放在不同伺服器，執行查詢和報表時不會影響作業系統的效能。另外，營運系統若只存「現在」的狀態，例如客戶等級變更後就覆蓋舊值，資料倉儲可以另外保留每個時間點的紀錄。
以 Google Analytics 為例，說明中心稱 BigQuery 是雲端資料倉儲系統，原始事件可以匯出到 BigQuery 再和其他資料一起查詢，標準資源的每日匯出事件數有上限，做法可參考匯出到 BigQuery 後的運用。
ETL、ELT 與 API 串接的差別
| 做法 | 轉換在哪裡發生 | 主要用途 |
|---|---|---|
| ETL | 載入前，在獨立的處理環境 | 把多個來源整理成分析用資料，可先遮蔽敏感欄位 |
| ELT | 載入後，在目標資料倉儲裡 | 先保存原始資料，需要時再轉換或重新計算 |
| API 串接 | 系統之間即時或依事件觸發 | 讓營運系統彼此同步，例如官網訂單寫入 ERP |
Microsoft 的說明指出，ELT 與 ETL 的差別只在轉換發生的位置，ELT 是用目標資料存放區本身的處理能力來轉換。API 串接的目的則是讓業務流程自動接續，而不是產出報表；欄位對應、觸發時機與重送規則怎麼規劃，可參考API串接的規劃流程。
什麼情況該建立 ETL 流程
- 報表要同時用到兩個以上系統的資料，例如官網訂單加門市 POS、廣告花費加實際成交。
- 每週或每月都有人手動匯出、複製貼上再對帳，常因欄位變動出錯。
- 想看長期趨勢，但來源系統只保留近期資料，或狀態會被覆蓋。
- 舊系統要汰換，歷史資料需要另外保存與查詢；Google Cloud 也提到 ETL 常用於整合舊版系統的資料。
- 主管、業務與財務對同一個指標各有一個數字，開會先爭論誰對。
報表只用到單一系統、內建報表已能回答問題時，就先用內建報表。
etl 工具怎麼選：四類做法比較
- 試算表內建的查詢功能：以 Microsoft 的 Power Query 為例，它是資料轉換與資料準備引擎，可在 Windows 版與 Mac 版 Excel、Power BI 等產品使用，轉換步驟會被記錄、不修改來源資料，可手動重新整理，或在 Power BI 等產品排程重新整理。適合來源少、由一兩人維護的報表。
- 雲端資料平台的整合服務：以 Microsoft Fabric 的 Data Factory 為例，同時支援 ETL 與 ELT，可以用管線把多個移動與轉換工作串成一個流程，適合來源多、需要排程與監控的情況。
- 排程程式：在既有主機上定時執行自寫程式，彈性高，但錯誤通知、重跑與文件都要自己建立。
- 整合進客製系統：資料來源就是自家客製後台時，可以直接加上匯出介面、彙總排程與報表。
不論哪一類，都要確認能否連到每個資料來源、能否增量擷取與排程、失敗時怎麼通知與重跑、轉換規則別人能否接手，以及權限與個資遮蔽怎麼設定；費用計算方式以供應商公告為準。
規劃 ETL 流程的七個步驟
- 從報表倒推：先列出要回答的問題與指標，再回推需要的資料。
- 盤點來源：記下每個來源的負責人、取得方式（資料庫、API 或匯出檔）與更新時間。
- 定義欄位對照與指標口徑並寫成文件，例如營收是否扣除退貨、以下單日或付款日計算。
- 決定更新頻率，以及全部重取或增量擷取。
- 安排執行順序與錯誤處理：例如先更新客戶再更新訂單，並決定失敗時通知誰、重跑會不會重複寫入。
- 對帳驗證：用來源系統的筆數與金額總計比對 ETL 結果，一致後再開放使用。
- 文件與交接：記錄排程、帳號與權限，並約定來源系統改版前先通知負責人。
ETL 流程的常見錯誤
- 沒有先定義口徑就開始搬資料：資料搬好了，營收與客戶數的算法沒有共識，報表仍然沒人相信。
- 營業時段對正式資料庫跑大量查詢：可能拖慢官網或後台，應排在離峰時段，或改從複本讀取。
- 整包複製個資：分析如果用不到姓名、電話與地址，就在轉換階段遮蔽或去除，並依公司的個資管理規範限制存取。
- 失敗沒有人知道：排程停了好幾天，報表照常顯示舊數字。每次執行都要留紀錄，失敗時主動通知。
- 來源欄位改了沒有通知：欄位改名後 ETL 可能出錯或抓到空值，改版流程要納入資料負責人。
常見問題
ETL 和資料庫備份是同一件事嗎？
不是。備份是為了在系統故障時還原，保存的是完整複本；ETL 是為了分析，通常只取需要的欄位並依規則轉換，結果不能拿來還原系統，兩者要各自規劃。
中小企業需要資料倉儲嗎？
不一定。資料來源只有兩三個、資料量不大時，報表專用的資料庫或自動更新的試算表就能支援報表；來源變多、要保留長期歷史或多人同時查詢時，再評估資料倉儲。
ETL 一定要即時更新嗎？
不一定。報表若用於每週或每月的管理會議，每天更新一次可能就夠。Google Cloud 的說明區分批次與串流兩種管道，串流適合需要即時反應的情境，例如庫存警示，先確認決策需要多快的資料再決定。
做 ETL 一定要會寫程式嗎？
不一定。以 Power Query 為例，在圖形介面操作時會自動產生背後的 M 程式碼，簡單的合併與清理不必手寫；轉換規則複雜、來源很多時，仍需要懂資料庫與程式的人員維護。
ETL 跑完的數字和系統報表對不上怎麼辦？
先比對筆數，再逐一檢查口徑：取消單與退貨是否扣除、日期以哪個時區計算、是否重複載入。執行紀錄沒有錯誤時，落差就可能來自定義不同，查出原因後要更新口徑文件。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
如果你的報表要合併官網、會員、訂單與其他系統的資料，可以先列出想回答的問題與現有的資料來源。京采能協助盤點各系統的欄位與取得方式，規劃匯出介面或 API 串接，並在客製後台加入彙總排程與報表功能，詳情可參考網頁設計服務，或與我們聯繫討論你的資料整合需求。
