上一篇文章我們用電信門市的例子，學會了 ETL、資料倉儲、OLTP 和 OLAP 的概念。
但實務上，光有資料倉儲還不夠。
你會遇到一個問題：原始資料要存在哪裡？
這篇文章會延續同樣的電信門市情境，帶你理解 Data Lake（資料湖）、它和 Data Warehouse（資料倉儲）的差異，以及結合兩者的 Data Lakehouse（資料湖倉）。
上一篇學到的 ETL 和資料倉儲概念
在上一篇文章中，我們知道了：
- 電信門市有多個資料來源：POS 系統（MySQL）、保險軟體（Oracle）、Amazon S3 上的電子合約 PDF。
- 這些 OLTP 系統是服務顧客的，不能直接在上面跑分析查詢。
- 所以我們透過 ETL 流程，把資料擷取出來、轉換清理、載入到資料倉儲。
- 資料分析師在資料倉儲上跑報表、做分析。
看起來很完美，但實際運作一段時間後，你會發現幾個問題。
為什麼光有資料倉儲還不夠？
OLTP 系統不會永遠保留資料
回到我們的電信門市。
POS 系統的 MySQL 資料庫會一直長大——每天都有新的交易紀錄寫進來。
但門市的資料庫不可能無限儲存，通常會有清除機制（Purging）。
例如只保留最近兩年的交易紀錄，超過兩年的就自動刪除，騰出空間給新的資料。
保險軟體的 Oracle 也是一樣，可能只保留最近三年的保單紀錄。
至於門市的應用程式伺服器上的 Log 檔案（系統日誌），保留時間更短——可能只存最近七天。
所以，如果有一天老闆問你：「幫我調五年前台北信義店的銷售資料」，你去 POS 系統一看——資料已經被清掉了。
資料倉儲的儲存成本很高
你可能會想：「那就把所有歷史資料都存到資料倉儲裡不就好了？」
問題是，資料倉儲通常跑在雲端服務上（像 Snowflake、Amazon Redshift、Google BigQuery），而且它的儲存成本不便宜。
因為資料倉儲不只是「存」資料，它還需要為每筆資料建立索引、做查詢優化，讓你跑 SQL 的時候很快。
這些運算資源和優化機制都要花錢。
如果把二十年、三十年的所有原始資料都塞進資料倉儲，帳單會非常驚人。
資料倉儲主要存的是結構化資料
還有一個限制：資料倉儲擅長存放的是結構化資料——也就是像表格一樣、有固定欄位的資料。
但你的電信公司還有很多非結構化資料：電子合約的 PDF、客服錄音檔、門市監視器畫面、App 的使用者行為 Log。
這些東西很難直接塞進資料倉儲的表格裡。
所以你需要另一個地方，專門用來存放這些原始、未經處理的資料。
什麼是 Data Lake（資料湖）？
Data Lake 的核心概念
Data Lake 說白了，就是一個很大、很便宜的雲端儲存空間，你把公司所有的原始資料通通丟進去，不管格式、不管有沒有清理過。
不管是結構化的（資料庫表格）、半結構化的（JSON、CSV）、還是非結構化的（PDF、圖片、Log 檔案），全部都可以存。
跟資料倉儲比起來，兩者的定位完全不同：資料倉儲是「整理好、隨時可以查」的地方，空間貴、只能放結構化資料；Data Lake 剛好相反——什麼都能丟、空間便宜、但資料是原始的，沒有經過整理。
簡單來說：資料倉儲是給分析師查資料用的，Data Lake 是給整間公司備份所有原始資料用的。
以我們的電信公司為例，Data Lake 裡可能有：
- POS 系統每天匯出的銷售紀錄原始檔
- 保險系統的完整保單歷史資料
- 電子合約的 PDF 原始檔
- App 的使用者行為 Log（JSON 格式）
- 客服通話錄音檔
- 門市監視器的影像資料
這些資料不需要事先清理或轉換，就是原封不動地丟進去。
為什麼需要保留原始資料？
你可能會問：「資料都已經經過 ETL 轉換放進資料倉儲了，為什麼還要保留原始版本？」
有幾個很實際的原因：
回溯和稽核需求。 假設金管會來查，要求你提供三年前某筆交易的完整原始紀錄。
資料倉儲裡存的是轉換後的彙總資料，原始的逐筆明細可能已經被合併了。
但 Data Lake 裡有完整的原始資料，你可以隨時回去調。
轉換邏輯可能會改。 也許一年前你的 ETL 轉換邏輯有個 bug，某些資料被錯誤地計算了。
如果你只有資料倉儲裡轉換後的結果，那這些錯誤就回不去了。
但如果 Data Lake 裡還保留著原始資料，你可以修正邏輯後重新跑一次 ETL。
未來可能有新的分析需求。 也許現在你只分析銷售數據，但三年後公司決定要做 AI 預測模型。
這時候你可能需要當初沒有放進資料倉儲的欄位或資料格式。
Data Lake 裡有完整的原始資料，讓你隨時可以回去挖。
完整的資料架構長什麼樣？
上一篇文章裡，我們的資料流向是：OLTP 系統 → ETL → 資料倉儲 → 分析。
加入 Data Lake 之後，中間多了一個步驟，整個流程變成五步：
第一步：擷取（Extract）
跟之前一樣，先從各個 OLTP 系統把資料拉出來。
POS 系統的 MySQL、保險軟體的 Oracle、S3 上的電子合約 PDF、App 的行為 Log——全部都要擷取。
第二步：存入 Data Lake
但這次拉出來的資料，不是直接送去做轉換，而是先原封不動地丟進 Data Lake。
這一步非常關鍵。
因為一旦你做了轉換（彙總、清理、格式統一），原始的細節就回不去了。
先存一份原始版本在 Data Lake 裡，等於幫自己買了一份保險——未來不管要稽核、修正 bug、還是做新的分析，你都有完整的原始資料可以用。
第三步：轉換（Transform）
接下來，從 Data Lake 裡讀取需要的資料，做清理和加工。
跟上一篇講的一樣：彙總、標準化、去除空值、格式統一。
注意，這裡的資料來源不再是直接連到 OLTP 系統了，而是從 Data Lake 讀取。
這樣做還有一個好處：你不需要每次做轉換都去打擾 OLTP 系統，減少對前線門市的影響。
第四步：載入（Load）
把轉換好的乾淨資料，載入到資料倉儲裡。
這時候資料倉儲裡存的就是「分析就緒」的結構化資料，分析師可以直接用 SQL 查詢。
第五步：分析
資料分析師和資料科學家在資料倉儲上跑報表、做儀表板、訓練 AI 模型，回答那些商業問題。
這個流程跟上一篇的差異在哪？
你會發現，跟上一篇的 ETL 流程相比，中間多了一個「Data Lake」。
原本是：OLTP → 轉換 → 資料倉儲。
現在是：OLTP → Data Lake → 轉換 → 資料倉儲。
Data Lake 扮演的是一個暫存區的角色，在業界有時也被稱為 Staging Area。
它不做任何轉換，就是單純地把原始資料存好，確保你隨時都能回去找到最原始的版本。
Data Lake 和 Data Warehouse 有什麼不同？
這兩個名字聽起來很像，但它們的定位完全不同。
存放的資料不一樣
Data Lake 存的是原始資料（Raw Data）——沒有經過清理、沒有統一格式，就是資料最原始的樣子。
Data Warehouse 存的是清理過、轉換過、可以直接分析的資料（Analytics-Ready Data）。
用買菜來比喻：你從市場買了一袋菜回來，連泥巴都還沒洗，直接丟進冰箱旁邊的紙箱裡——那就是 Data Lake。
你把菜洗乾淨、切好、分裝進保鮮盒、放進冰箱——那就是 Data Warehouse。
支援的資料格式不一樣
Data Lake 什麼都能存：表格資料、JSON、CSV、PDF、圖片、影片、Log 檔案，結構化和非結構化通通可以。
Data Warehouse 主要存結構化資料——有固定欄位的表格，這樣才能用 SQL 查詢、做 BI 報表。
儲存成本差很多
Data Lake 通常用的是像 Amazon S3、Azure Data Lake Storage（ADLS）、Google Cloud Storage 這類物件儲存（Object Storage）。
這種儲存方式非常便宜，因為它不需要做查詢優化，就是單純地把檔案存起來。
Data Warehouse（像 Snowflake、Redshift、BigQuery）的儲存成本就高得多，因為它背後有索引、有查詢引擎、有平行處理的基礎架構。
查詢效能差很多
Data Lake 上也可以做查詢——例如用 Amazon Athena 直接對 S3 上的 JSON 檔案跑 SQL。
但因為資料沒有做過索引和優化，查詢速度會比較慢。
Data Warehouse 就是專門為查詢設計的，SQL 跑起來快很多，而且支援 ACID 交易特性。
什麼是 ACID？
ACID 是資料庫交易的四個保證，簡單來說：
A（Atomicity，原子性）：一個交易裡的所有操作，要嘛全部成功，要嘛全部不做。
舉個例子：一位客人在門市買了手機，同時加購了保險和保護貼，系統需要同時寫入三筆訂單紀錄。
如果第三筆寫入失敗了，ACID 保證前兩筆也會一起撤回，不會出現「手機買了但保險沒記錄到」的狀況。
Data Warehouse 支援 ACID，Data Lake 通常不支援（因為它只是單純的檔案儲存）。
一張表看懂差異
什麼是 Data Lakehouse（資料湖倉）？
看到這裡，你可能會想：「Data Lake 便宜但查詢慢，Data Warehouse 查詢快但貴。有沒有辦法兩個都要？」
有，這就是 Data Lakehouse 的概念。
Data Lakehouse 結合了兩者的優點
Data Lakehouse 是一種新的架構，它把 Data Lake 和 Data Warehouse 的優點結合在一起。
簡單來說，它的底層儲存還是用便宜的物件儲存（像 S3），但在上面加了一層管理機制，讓你可以像使用資料倉儲一樣做 SQL 查詢、支援 ACID、做 BI 分析。
等於你不用再維護兩套系統（一個 Data Lake + 一個 Data Warehouse），只要一套就能搞定。
常見的 Data Lakehouse 方案
目前業界最主流的兩個 Data Lakehouse 方案：
這兩個方案的核心思路是一樣的：不改變底層便宜的儲存方式，但在上面加一層「表格格式（Table Format）」的管理機制，讓原本只是一堆檔案的 Data Lake，變得像資料倉儲一樣好查詢。
小結：Data Lake、Data Warehouse、Data Lakehouse 的關係
這篇文章延續電信門市的情境，解釋了三個重要概念：
- Data Lake（資料湖）：便宜的雲端儲存空間，存放公司所有的原始資料，不限格式，什麼都能丟進去。
- Data Warehouse（資料倉儲）：專為分析設計的資料庫，存放清理過、轉換過的結構化資料，查詢速度快，但成本較高。
- Data Lakehouse（資料湖倉）：結合兩者優點的新架構，底層用便宜的物件儲存，上層加入查詢優化和 ACID 支援，一套系統搞定儲存和分析。
它們之間的演進邏輯是：企業一開始只有資料倉儲，後來發現需要保留原始資料所以加了 Data Lake，最後覺得維護兩套系統太麻煩，就出現了 Data Lakehouse 這種整合方案。
理解了這些概念，你就掌握了現代資料架構的核心全貌。