簡介

在 DAY2 知識之章-理解資料本源 與 DAY6 知識之章-儲存的基石 Amazon S3 中，我們分別介紹了本系列所使用的資料檔案和 S3 的儲存機制。

本篇要進一步來說明如何在 AWS S3 上設計 Bronze → Silver → Gold 的完整流程。

在開始設計我們的 Data Lake 之前，我們要先來了解一下 Medallion 架構。

什麼是 Medallion 架構?

Medallion 架構 (Medallion Architecture) 是由 Databricks 推廣的一種 資料湖倉 (Lakehouse) 分層設計模式，核心理念是透過 多層精煉 (multi-hop refinement)，讓資料的品質隨著層級逐步提升，最終能提供可靠的數據給分析、BI 和機器學習使用。

它通常分為三層：

🥉 Bronze 層（Raw Data Layer）

• 存放最原始的資料（Raw Data）。
• 資料直接從來源系統進來，不做清洗、不改欄位。
• 保留完整歷史與追溯能力。
• 格式可以是 CSV、JSON、Parquet 等。

🥈 Silver 層（Cleansed Data Layer）

• 對 Bronze 的資料做 清洗、轉換、去重、標準化。
• 修正資料格式、補齊欄位、處理異常值。
• 適合分析師、資料科學家進行探索與建模。
• 格式通常轉換成 Parquet / Delta / ORC，方便查詢與壓縮。

🥇 Gold 層（Curated / Business-ready Layer）

• 提供 商業就緒 (business-ready) 的資料集。
• 會做 聚合 (aggregation)、維度建模 (dimensional modeling)、特徵工程。
• 直接支援 BI 報表、即席查詢、機器學習訓練。
• 資料通常經過效能最佳化，例如 Partition、Compaction、索引。

📌 Medallion 架構的好處

1. 資料品質逐層提升：從原始 → 清洗 → 商業化，降低髒資料影響。
2. 可追溯性：保留 Raw Data，出錯時可重建下游。
3. 可擴展性：能支援多種來源（log、API、DB dump、IoT）。
4. 治理與權限清晰：不同使用者可讀取不同層級的資料（工程師看 Bronze/Silver，商業分析看 Gold）。

根據以上的介紹我們初步理解了 Databricks 推廣的 Medallion 架構，請特別注意，Medallion 架構「不是」強制規範，而是一種分層模式，企業可依資料性質與應用需求，調整層數與命名方式。

接著就讓我們來看看 Anime Data Lake 該怎麼設計吧!

Anime Data Lake 設計

我們將參考 Medallion 架構設計，來規劃以下內容。

🥉 Bronze 層：Raw Data 與 Partition 自動化

📂 Bronze 資料夾結構設計

我們會建立兩個 Bronze folder：animes 與 ratings，並依照日期自動分區。

s3://anime-lake/bronze/animes/year=YYYY/month=MM/day=DD/animes.csv
s3://anime-lake/bronze/ratings/year=YYYY/month=MM/day=DD/ratings.csv

⚙️ 自動 Partition 流程

1. 使用者上傳檔案至：

s3://anime-lake/bronze/animes/animes_20250926.csv
s3://anime-lake/bronze/ratings/ratings_20250926.csv

2. S3 Event 觸發 Lambda → Lambda 解析檔名中的日期 (YYYYMMDD)。
3. Lambda 將檔案搬移至正確的 Partition 路徑：

s3://anime-lake/bronze/animes/year=2025/month=09/day=26/animes.csv
s3://anime-lake/bronze/ratings/year=2025/month=09/day=26/ratings.csv

4. Lambda 最後觸發 Glue Job，進入 Bronze → Silver 的轉換。

🥈 Silver 層：清洗、去重與格式最佳化

在 Bronze → Silver 的轉換過程，我們有兩種設計模式可以選擇，取決於資料性質。

🔹 模式 A：Append-only（事件型/交易型資料）

• 適用：每筆都是獨立事件且不更新的資料，例如每次的 API Log 紀錄。
• 處理方式：
• 讀取對應日期 partition。
• 清洗：移除空值、轉換欄位型別。
• 去重：避免重複上傳的紀錄。
• 輸出 Parquet 至 Silver：

s3://anime-lake/silver/ratings/year=2025/month=09/day=26/ratings.parquet

🔹 模式 B：Merge/Upsert（狀態型資料）

• 適用：會持續做更新的資料，例如動漫的分數/續集資訊更新、使用者評分更新。
• 處理方式：
• 讀取 Bronze 新檔案。
• 以 animeID 作為主鍵，與 Silver 既有表格做 merge/upsert。
• 保證 Silver animes 永遠是最新狀態。
• 輸出格式：

s3://anime-lake/silver/animes/animes.parquet

由於我們的資料可能是會被使用者做更新的，故我們選擇模式B Merge/Upsert 來處理 Silver 層的資料。

📌 常見的 AWS 資料處理服務

• AWS Glue Job (PySpark)
• Athena CTAS (快速產表)
• Airflow/MWAA（排程調度）

我們後續將使用 Glue Jobe (PySpark) 來進行建表和處理。

🥇 Gold 層：商業就緒的分析與特徵表

Silver 資料經過清洗後，就可以進一步轉換成 Gold 層，提供 BI 報表 / ML 模型訓練。

🔹 聚合表 (Aggregate Tables)

適合 Dashboard/報表，例如：

• gold.top_animes：最受歡迎動漫
• gold.anime_avg_rating：動漫平均分數
• gold.genres_count：什麼風格的動漫數量最多

🔹 效能最佳化

• Partition by 日期 / 地區。
• 檔案壓縮與合併 (Compaction)。
• Delta Lake / Iceberg：支援 Z-Order 與 Time Travel。
• 預先計算的物化檢視。

結論與建議

• Bronze 層：只收 Raw Data，透過 Lambda 自動解析檔名並建立分區。
• Silver 層：依資料性質分為 Append-only（ratings）與 Merge/Upsert（animes），清洗後轉換成 Parquet。
• Gold 層：提供 BI 報表、維度模型、ML 寬表，並加強效能優化。

透過這樣的設計，我們在 AWS S3 Lakehouse + Medallion 架構中，實現了 可追溯、可清洗、可消費 的完整數據管道。

下篇預告

下篇我們將進入 「DAY13 雲端基礎章-Lambda、EventBridge 概念篇」，來簡單的介紹一下 Lambda + EventBridge 可以解決那些問題。

參考資料

[1] Medallion 架構 (Medallion Architecture)
[2] Databricks