你可能聽過「ETL」「資料倉儲」「OLTP」「OLAP」這些名詞，覺得很複雜。
但其實它們的概念非常簡單。
這篇文章會用像遠傳、台哥大這種電信門市當例子，帶你一步步理解這些概念。
電信門市的資料從哪來？以遠傳、台灣大哥大為例
想像你經營的是像遠傳或台灣大哥大這樣的電信品牌，在全台各地都有門市。
你走進任何一家門市，會看到店員在櫃檯幫客人辦門號、賣手機。
客人挑好手機、選好資費方案，店員就會在 POS 系統（銷售點系統） 上完成這筆交易。
這個系統會記錄下「誰在哪家店、什麼時間、買了哪支手機、花了多少錢」。
買手機的時候，店員通常會問：「要不要加購手機保險？螢幕摔破可以免費換。」
大部分的人都會買，而這些保單和後續的理賠紀錄，就會存在另一套保險軟體裡。
這兩套系統通常是完全獨立的，背後用的資料庫也不一樣。
例如 POS 用的是 MySQL，保險系統用的是 Oracle。
除了這些存在資料庫裡的結構化資料，你的公司還會有一些非結構化資料。
例如客人在門市辦門號或續約時，會簽署電子合約，這些合約會以 PDF 的形式存放在 Amazon S3 雲端儲存上。
所以整體來看，一家電信公司的資料是散落在各處的——POS 資料庫、保險資料庫、雲端上的 PDF，格式不同、系統不同、存放位置也不同。
為什麼企業需要整合不同系統的資料？
現在資料都有了，但它們分散在不同的地方。
身為老闆，你一定會想問：「台北信義店和高雄左營店，到底哪家表現比較好？」
要回答這個問題，你需要看手機賣了多少、保險賣了多少。
但問題來了——手機銷售的數字在 POS 系統的 MySQL 裡，保險業績卻在另一套保險軟體的 Oracle 裡。
你沒辦法打開一個畫面就看到完整的答案，因為資料根本不在同一個地方。
不只如此，你可能還想更進一步知道：「哪位業務員的簽約量最多？合約續約率怎麼樣？」
但這些電子合約是一份一份的 PDF，存在 S3 雲端上。
PDF 不像資料庫可以直接下指令查詢，你得先想辦法把合約裡的資訊「抓出來」，才有辦法做統計。
再往更長遠的角度想，農曆新年或雙十一快到了，你想預測哪個門市會最忙、該多派幾個人。
這就需要綜合過去幾年的銷售紀錄來分析，但這些歷史資料同樣分散在好幾個系統裡，要一個一個撈非常費時。
這些問題看起來各不相同，但背後卡住的原因都是一樣的：資料散落在 MySQL、Oracle、S3 三個不同的地方，格式不同、系統不同，沒有人能一次看到全貌。
而這些問題的答案，會直接影響你的商業決策——要不要多開一家店、該把資源集中在哪個地區、哪位業務員值得升遷。
所以，你需要一個方法，把這些散落各處的資料整合在一起。
為什麼不能直接在原始資料庫上做分析？
最直覺的做法是：直接去 POS 的 MySQL 資料庫撈銷售數字，再去保險的 Oracle 資料庫撈保險數字，然後加起來比較。
聽起來很合理，但這樣做其實有很大的風險。
問題：分析查詢會拖慢系統
想像一下，現在是週六下午，門市擠滿了客人。
店員正在用 POS 系統幫客人結帳、辦門號，每一筆操作都需要即時讀寫 MySQL 資料庫。
就在這個時候，總部的資料分析師對同一個 MySQL 資料庫跑了一個很複雜的查詢——例如「幫我算出過去三年每家門市每個月的銷售趨勢」。
這種查詢需要掃描大量的歷史資料，會吃掉很多資料庫的運算資源。
結果就是：資料庫變慢了，門市店員的 POS 系統開始轉圈圈，客人站在櫃檯前面等，結帳排隊越排越長。
這就是所謂的任務關鍵系統（Mission Critical System）——這些系統正在服務你的真實顧客，一旦變慢或掛掉，生意就直接受影響。
所以你不能為了做分析，去拖慢正在服務客人的系統。
解法：複製到另一個資料庫
企業通常的做法是：把資料複製到另一個獨立的資料庫，所有的分析查詢都在那個資料庫上跑。
這樣一來，就算分析師跑了再複雜的查詢，讓這個資料庫變慢，也完全不會影響到前線門市的運作。
資料搬移前為什麼需要轉換？
不過，你不會想把原始資料原封不動地搬過去。
為了讓後續分析更方便，你需要先做一些轉換。
讓我們用一個具體的例子來看。
步驟一：看看原始資料長什麼樣
假設你的電信品牌不只在台灣有門市，在日本也有據點。
你的 POS 資料庫裡有這些紀錄：
你會發現，台北信義店有三筆紀錄，東京澀谷店有一筆。
而且幣別不同——一個是新台幣，一個是日圓。
步驟二：做「彙總」
第一個轉換動作是彙總（Aggregation），把同一家門市的數字加起來。
現在每家門市只剩一筆彙總數字，比較容易看了。
步驟三：做「標準化」
但你還是不能直接比較，因為幣別不同。
所以第二個轉換動作是標準化（Standardization）——把不同單位統一成同一個基準，這裡就是把日圓換算成新台幣。
現在你可以在同一個基準下比較了。
台北信義店的手機銷售額是 89,690 元，東京澀谷店換算後是 33,000 元。
加上保險的數字之後，就能清楚知道哪家門市整體表現最好。
什麼是資料倉儲（Data Warehouse）？
轉換完的資料要放到哪裡？你需要一個專門的地方來集中存放，這個地方就叫做資料倉儲（Data Warehouse）。
為什麼叫「倉儲」？因為它儲存的不只是某一個系統的資料，而是整個組織的資料。
以我們的電信公司為例，資料倉儲裡可能同時存放了：
- POS 系統的手機銷售紀錄
- 保險軟體的保費和理賠資料
- ERP 系統裡的員工資料
- 雲端上電子合約的關鍵欄位
所有散落在不同系統的資料，經過轉換後，都集中放進這一個資料倉儲裡。
之後，資料分析師和資料科學家就可以在這個倉儲上執行各種查詢、製作儀表板和報表，來回答我們前面提到的那些商業問題。
什麼是 ETL？
回顧剛才的過程，我們其實做了三件事，而這三件事剛好對應到一個標準流程的三個步驟。
擷取（Extract）：把資料從各個來源拉出來
第一步是「擷取」——去各個系統把你需要的資料拉出來。
以我們的電信公司為例，你需要：
- 連線到 POS 系統的 MySQL 資料庫，把手機銷售紀錄撈出來。
- 連線到保險軟體的 Oracle 資料庫，把保費和理賠紀錄撈出來。
- 連到 Amazon S3，把電子合約的 PDF 下載下來，再從裡面擷取出需要的欄位（例如簽約日期、資費方案、綁約期間）。
這些來源的格式可能完全不同——有的是資料庫表格，可以直接用 SQL 查詢；有的是 PDF 檔案，需要額外的工具去解析內容。
但不管來源的格式是什麼，擷取這一步的目標就是：把散落在各處的原始資料，全部收集到手上。
轉換（Transform）：清理和加工資料
第二步是「轉換」——把拉出來的原始資料做清理和加工，讓它變成可以分析的格式。
原始資料通常是「髒」的，不能直接拿來分析。
回想一下我們前面做的事情：台北信義店有三筆交易紀錄，我們做了彙總把它加總成一筆；台北和東京的銷售額幣別不同，我們做了標準化把日圓換算成新台幣。
除了這兩種操作，實務上常見的轉換還有很多，例如：
- 去除空值（Null）：有些紀錄的某些欄位是空的，例如客人沒填電話號碼，你需要決定是補上預設值還是直接排除。
- 去除異常值（Outlier）：例如某筆交易金額顯示 0 元或負數，很可能是系統錯誤，留著會影響分析結果。
- 格式轉換：MySQL 裡的日期格式是
2024-01-20，Oracle 裡可能是20-JAN-2024，你需要統一成同一種格式。 - 合併欄位：POS 裡的門市地址和保險系統裡的門市名稱，可能用不同的寫法指向同一家店，你需要建立對應關係把它們合在一起。
轉換的目的就是讓資料變得乾淨、一致、可比較，這樣後續分析才有意義。
載入（Load）：把處理好的資料存進資料倉儲
第三步是「載入」——把轉換完成的資料，寫入我們前面提到的資料倉儲裡。
載入不只是「把資料丟進去」這麼簡單。
你需要考慮的事情包括：這批資料要覆蓋掉舊的，還是追加在後面？載入的頻率是每天一次、每小時一次，還是即時同步？如果載入到一半失敗了，要怎麼處理？
不過對初學者來說，先記住核心概念就好：載入就是把清理好的資料，放進一個專門用來分析的資料庫裡。
三個步驟合起來，就是 ETL
擷取（Extract）、轉換（Transform）、載入（Load）——這三個步驟合起來，就叫做 ETL。
簡單一句話總結：ETL 就是「把散落在各處的資料，經過清理和轉換，集中存放到一個地方」的標準流程。
OLTP 和 OLAP 的差異
現在我們把整個架構分成左右兩邊來看。
左邊：OLTP（線上交易處理系統）
OLTP 的全名是 Online Transaction Processing。
它指的就是左邊那些正在服務顧客的資料庫，例如 POS 的 MySQL 和保險的 Oracle。
OLTP 的特色：
- 服務的是真實顧客
- 是任務關鍵系統，不能當機、不能變慢
- 資料操作以「新增、修改、刪除」為主（例如每一筆交易）
右邊：OLAP（線上分析處理系統）
OLAP 的全名是 Online Analytical Processing。
它指的就是右邊的資料倉儲。
OLAP 的特色：
- 服務的是公司內部的分析需求
- 不直接面對顧客
- 資料操作以「大量讀取和分析」為主（例如跑報表、做趨勢分析）
簡單來說：OLTP 是做生意用的，OLAP 是分析生意用的。
常見的 ETL 工具和資料倉儲方案
知道了 ETL 和資料倉儲的概念之後，你可能會好奇：實務上要用什麼工具來做？
ETL 工具
如果你的資料量不大、來源也只有兩三個，最簡單的做法是自己寫程式。
例如用 Python 連線到 MySQL 撈資料、做轉換、再寫入資料倉儲，整個流程幾十行程式碼就能搞定。
但隨著公司規模成長，ETL 會越來越複雜——資料來源變多、轉換邏輯變繁瑣、還需要排程（例如每天凌晨自動跑一次）、錯誤時要通知、失敗時要重跑。
這時候就需要專門的 ETL 工具來管理整個流程：
如果你是剛入門的初學者，建議先從 Python 手寫 ETL 開始理解整個流程，等掌握概念之後再學習 Airflow 這類工具。
資料倉儲方案
理論上，你可以用 MySQL 或 PostgreSQL 這些一般的資料庫來當資料倉儲。
但當資料量大到幾百萬、幾千萬筆以上，一般資料庫跑分析查詢就會越來越慢。
這時候就需要專門為分析設計的資料倉儲方案。
這些方案通常有一個共同特色：大規模平行處理（MPP, Massively Parallel Processing）——把一個大查詢拆成很多小任務，同時丟給多台機器去跑，速度快非常多。
目前業界的趨勢是往雲端方案走，像 Snowflake、Redshift、BigQuery 這三個是最常被討論的選擇。
選哪一個通常取決於你的公司已經在用哪家雲端服務——如果用 AWS 就選 Redshift，用 GCP 就選 BigQuery，如果不想被特定雲端綁住就選 Snowflake。
小結：ETL、資料倉儲、OLTP 與 OLAP 的關係
這篇文章用電信門市的例子，解釋了幾個重要的資料工程概念：
- OLTP 是服務顧客的交易系統，強調即時處理和穩定性。
- OLAP 是支援內部分析的系統，強調大量資料的查詢和洞察。
- ETL 是把資料從來源「擷取」出來、做「轉換」、再「載入」到資料倉儲的標準流程。
- 資料倉儲 是集中存放整個組織資料的地方，分析師在這裡跑報表、做分析。
理解這些概念之後，你就掌握了資料工程領域最基礎也最重要的架構觀念。