雲端資料庫
現代化資料湖倉：S3、Glue 與 Redshift 怎麼組起來
現代化資料湖倉：S3、Glue 與 Redshift 怎麼組起來
資料湖倉這個詞被用得很鬆，鬆到很多人講了半天其實在講不同的東西。真要落地，你要回答的是很具體的四個問題：資料放哪、誰知道它長什麼樣、誰能看、以及最後用什麼查。
在 AWS 上，這四題各有對應的服務。這篇把它們一個一個放回自己的位置，順便講 2026 年比較值得注意的變化。
你將學到什麼
四層分工
S3 存資料、Glue 做目錄與整合、Lake Formation 管權限、Redshift 負責分析輸出。
S3 的重點
選對儲存類別，再用生命週期規則讓冷資料自動往下沉，應用端不必改程式。
目錄是核心
Glue 資料目錄是整個湖倉的共同語言，權限與查詢引擎都靠它認得資料。
2026 年變化
Redshift 推出 Graviton 架構的 RG 執行個體，把資料湖查詢引擎直接放進叢集節點。
湖倉不是一個產品，是一種分工方式。它把「便宜地存下全部」與「有結構地快速查詢」這兩件事拆到不同層，再用一份共同的目錄把它們接起來。
所以理解 AWS 的湖倉，最有效的方式不是背服務名稱，而是先畫出這條路徑：資料從哪裡來、落在哪一層、誰負責描述它、誰負責放行、最後誰把它變成報表。
先把四層的位置畫出來
這張圖要記住的重點只有一個：資料只有一份，能力分在不同層。同一批放在 S3 上的檔案，可以被 Glue 的作業處理、被目錄描述、被 Redshift 或 Athena 查詢，不必為了每一種用途各複製一份。
S3：分層儲存與生命週期，先想冷熱
S3 提供多種儲存類別，差別在於取用頻率、取回速度與成本結構。AWS 官方頁面上列出的包含 S3 Standard、Intelligent-Tiering、Standard-IA、One Zone-IA、Express One Zone，以及 Glacier 系列的三種。
- 經常存取：S3 Standard，日常讀寫的預設選擇。
- 存取模式抓不準：S3 Intelligent-Tiering，官方說明是依存取頻率自動把資料搬到最划算的層級。
- 偶爾才讀：Standard-IA；資料可重建、能接受單一可用區的話還有 One Zone-IA。
- 封存：Glacier Instant Retrieval 要求立即取回，Flexible Retrieval 與 Deep Archive 則以取回時間換更低的保存成本。
真正省事的是生命週期規則。官方的說法很直接：規則設好之後，資料會自動轉到另一個儲存類別，應用程式不需要任何修改。
資料湖的分層目錄（原始、清洗、彙整）天生就是生命週期規則的好邊界。原始層通常最大也最少被讀，最適合設定較積極的轉移規則；彙整層則多半要留在熱層。先把目錄結構設計好，規則才寫得乾淨。
另一個近年的變化是開放表格式。S3 Tables 提供內建的 Apache Iceberg 支援，讓表格語意直接落在物件儲存上，Redshift、Athena、EMR 與 Glue 都能存取同一份表。
Glue：無伺服器的整合層與資料目錄
AWS 官方文件把 Glue 定義為無伺服器的資料整合服務，讓分析使用者發現、準備、搬移與整合來自多個來源的資料，並且沒有基礎設施要管。
它有幾個部件，實務上分工很清楚。搞混這幾個部件是新手最常見的卡點。
| 部件 | 它負責什麼 | 什麼時候會用到 |
|---|---|---|
| 資料目錄 | 集中登記資料庫、資料表與結構定義 | 任何時候。它是整個湖倉的共同語言 |
| 爬蟲 | 自動推斷結構並寫進資料目錄 | 來源結構會變，或檔案是別人丟進來的 |
| ETL 作業 | 在 Spark 引擎上做搬運、清洗與轉換 | 要把原始層加工成清洗層與彙整層 |
| Glue Studio | 用視覺化介面組作業並產生程式碼 | 團隊裡有非工程背景的成員要參與 |
文件也提到，登記在目錄裡的資料可以直接被 Athena、EMR 與 Redshift 查詢。這句話很關鍵：目錄寫得好不好，決定後面每一個引擎好不好用。
Glue 的能力近年逐步被收進 Amazon SageMaker Unified Studio 的統一介面裡，Glue 主控台也加上了一鍵跳轉。這影響的是你在哪個畫面上工作，不影響底層的目錄與作業概念。實際的版本與介面請以 AWS 官方公告為準。
Lake Formation：權限要管在目錄這一層
AWS 文件把 Lake Formation 描述為一個授權層，對 AWS Glue 資料目錄裡的資源提供細緻的存取控制。換句話說，它管的不是檔案路徑，而是資料表與欄位。
官方頁面強調的定位是集中治理、保護與分享資料，讓你用類似資料庫的方式管理資料湖的存取權限，並提供標籤式的存取控制與稽核記錄。
- 先把 S3 上的資料位置註冊給 Lake Formation 管理。
- 在 Glue 資料目錄裡建立好資料庫與資料表定義。
- 用資料表與欄位層級的權限授予角色，需要規模化時再改用標籤。
- 打開稽核記錄，讓「誰查了什麼」變成可回溯的事實而不是猜測。
權限模型是那種「晚做十倍成本」的東西。資料湖裡的表一旦長到幾百張、使用者散在好幾個團隊，事後補治理幾乎等於重做一次。剛開始只有五張表的時候，把註冊、授權與稽核走一遍，成本幾乎是零。
Redshift：分析出口，以及 2026 年的變化
Redshift 在這條路徑上的角色是分析與查詢的出口。它處理的是固定報表、複雜彙整與需要穩定回應時間的並行查詢，這些正好是隨查隨付引擎比較吃力的地方。
Redshift Serverless 讓你不必先決定叢集規格，運算會依分析需求自動伸縮，適合用量起伏大或不想做容量規劃的團隊。
2026 年 5 月，AWS 宣布 RG 執行個體正式推出。它採用 AWS Graviton 處理器，並把 Redshift 自建的向量化資料湖查詢引擎直接放進叢集節點，在節點上處理 Apache Iceberg 與 Parquet 資料。
這件事的意義是：倉儲查詢與資料湖查詢可以用同一套引擎跑完。官方公告也提到，這讓 Redshift Spectrum 那套獨立的掃描叢集不再是必要的。
另外值得留意的是 zero-ETL 路線。它讓營運資料庫、串流服務與部分第三方應用的資料能近即時地進到分析端，減少你自己維護搬運管線的份量。
常見的三個坑
- 小檔案氾濫：串流寫入很容易在 S3 上堆出海量小檔，查詢效能會被拖垮。要排壓縮合併的作業，或改用有維護機制的表格格式。
- 目錄與實體不同步：手動改了路徑或分區卻沒更新目錄，查詢會回傳空結果而不是報錯，最難查。把目錄更新寫進管線，不要靠人記得。
- 權限用桶政策硬撐：一開始看起來簡單，等到要做欄位層級遮蔽時規則會爆炸。該用 Lake Formation 的時候就用。
最後給一個很實際的建議：不要一次把四層全部上齊。先讓資料能穩定落到 S3、目錄能正確描述它，之後再談分析引擎與治理細節。順序反了的湖倉，通常會變成一座沒人敢用的湖。
延伸學習
寫給升國一的你的筆記術
寫給剛升上國中的你：筆記不是寫給老師看的，是寫給考前的自己看的。18 章 85 課圖文，從「為什麼要寫」講到七科各自怎麼記，附 78 份可以印出來寫的練習單，以及 80 課家長專區與 34 張三年筆記養成路徑圖。沒有閱讀期限，國一買、國三還在。
NT$ 3,599
ChatGPT 很強，但真正讓你下班的是 Google
六小時完整實錄。從「AI 很厲害，為什麼你還是每天加班」這個問題出發，把 Google Workspace 當成真正的工作平台重新設計一次流程 ── Sheets 的資料結構、Drive 與 Docs 的文件流、Gmail 與 Calendar 的通知系統，再用 Apps Script 讓它自己跑起來，最後收斂成一張屬於你自己的 AI 工作能力地圖。
NT$ 4,599