簡介

在上篇 Day18 淬鍊之章-使用 Lambda 呼叫 Glue Workflow 中，我們已經把資料寫入到 Iceberg。

本篇要介紹 Amazon Athena 這個 AWS 服務，並且搭配 Glue Data Catalog 來查詢我們 Data Lake 內的資料。

主要目的：

• 驗證數據是否正確寫入。
• 展示如何利用 SQL 查詢 Data Lake。

什麼是 Amazon Athena？

基本介紹

Amazon Athena 是 AWS 提供的一個 Serverless（無伺服器）互動式查詢服務。
它最大的特色是「免基礎設施管理」：

• 不需要建立、維護資料庫伺服器或叢集。
• 查詢即付費（Pay per query），只會根據實際掃描的資料量收費。
• 底層使用 Presto/Trino 分散式查詢引擎，完全支援標準 SQL 語法。
• 透過 Glue Data Catalog 提供資料表結構與 Schema 定義，可以直接讀取 Amazon S3 上的資料。

架構特色

• 與 Glue Data Catalog 整合：Athena 不儲存資料，只依賴 Glue Catalog 來定義表格與欄位。
• 支援多種格式：CSV、JSON、Parquet、ORC、Avro、Iceberg、Hudi、Delta Lake 等。
• 彈性擴展：查詢會自動並行分散處理，不需要手動調整運算資源。
• 查詢結果可持久化：可選擇將查詢結果存放在指定的 S3 Bucket。

常見應用場景

1. 數據驗證與探索 (Data Validation & Exploration)

   • 在 ETL/ELT 流程後，用來檢查資料是否轉換正確。
   • 探索資料集的 Schema、欄位分佈、缺失值。

2. ETL 工作的輔助工具

   • 搭配 Glue Job，先用 Athena 驗證數據，再進行後續轉換。
   • 可以透過 SQL 做部分數據清洗，將結果匯出至 Parquet 供下游使用。

3. 下游商業智慧 (BI) 整合

   • Athena 可直接與 Amazon QuickSight 或其他 BI 工具整合，提供即時報表與 Dashboard。
   • 適合需要低成本、快速上手的數據分析情境。

4. 跨來源查詢 (Federated Query)

   • Athena 可以透過 Connector 連接 RDS、DynamoDB、Redshift 等不同數據來源。
   • 讓分析師能用單一 SQL 查詢跨系統資料。

5. 事件驅動分析

   • 搭配 S3 EventBridge/Lambda，當新數據進入 S3 時，自動觸發 Athena 查詢並將結果存放回 S3。
   • 適合即時數據驗證與輕量的即時數據處理。

💡 小總結：

• Athena 是一個「低門檻、即用即查」的分析服務，非常適合用於 Data Lakehouse 架構中的 數據驗證、探索與輕量 BI 報表。
• 它不是取代 Redshift 或 RDS，而是作為一個 靈活查詢層，讓使用者能快速驗證與探索數據。

接著讓我們看看如何使用 Athena 吧!

使用 Athena 查詢 DataLake

Step1：本次我們登入使用者 Andy，並於查詢 Athena 服務，然後點擊進入 Athena 頁面。

記得也要選擇台北區域，才能正常顯示 Catalog 和相關 DB、Table。

Step2：接著我們點選「探索查詢編輯器」進入查詢頁面。

Step3：在使用 Athena 之前，我們要先設定 Athena 查詢後產出檔案的存放位置，所以我們要先點擊「編輯設定」。

Athena 每次在查詢時，都會自動儲存一個查詢的產出檔案 .csv 到儲存路徑下。

Step4：既然是儲存，當然就會運用到我們的 S3 服務，但此時還尚未有建立 Athena 查詢輸出檔案的儲存路徑。

Step5：接下來我們需要於 S3 建立一個 Athena 專用的儲存 Folder

• 首先先進入 S3 Bucket：anime-lake/
• 然後建立一個 Folder 可以命名為 Athena (可自行命名)

Step6：再來我們就可以回到剛剛 Athena 選擇儲存路徑的畫面，選擇我們剛剛建立好的 Folder 路徑作為後續的Athena 查詢檔案存放位置。

Step7：接著確認儲存路徑無誤後，就可以儲存設定了。

Step8：跳轉後我們就可以看到該 Athena 的工作群組，查詢產出檔的儲存位置

Step9：接著我們回到編輯器的地方

• 可以看到資料來源為 AwsDataCatalog，這是此帳號在台北區域唯一的 Catalog
• 資料庫可以選擇：silver、gold
• 切換不同 DB 後，可以看到先前建置的相關 Table

Step10：再來我們來實際查詢 silver 內的 animes Table

• 先選擇 Catalog、DB、Table
• 輸入 SQL Query 語法
• 點選查詢
• 確認效能與查詢結果
• 可以直接做 CSV 檔案的下載，會從 S3 Folder 路徑下下載

SQL：

SELECT * FROM "silver"."animes" limit 10;

Step11：接著我們回到 S3 Athena 的路徑下，查看有無正常建立查詢儲存檔

• 他是採時間分區的方式建立查詢儲存檔，除了結果檔以外，還會有 metadata 的檔案
• 除了從 Athena 查詢頁面下載 CSV 檔案，也可以再從 S3 Folder 來做下載
  

Step12：除了 silver Table 以外，我們也來看一下 gold Table

SELECT * FROM "gold"."animes_summary" limit 10;

Step13：除了基本的 Select 語法，我們也可以在做一些根據 Column Order By 的操作

• 取得 10 筆 animes_summary 的資料，需根據 avg_anime_score 由小到大排序

SELECT 
 * 
FROM "gold"."animes_summary" 
ORDER BY avg_anime_score
limit 10

總而言之就是一般的 SQL 用法，你可以自己做分類、篩選、排序等操作，但請注意查詢量的耗用。

Step14：接著我們也可以針對剛剛的查詢語法做儲存。

Step15：接著設定 Query 查詢的儲存名稱、描述、預覽後，即可按儲存。

Step16：我們可以至「儲存的查詢」頁籤頁面，找到剛剛儲存的查詢，再選擇該筆查詢後，會直接跳轉到查詢頁面，將常用的查詢做儲存，可以非常便於下次的使用。

以上即完成 Athena 的查詢應用步驟，想必熟悉 SQL 的你，看到 Athena 這個服務會有別於前面的其他服務，感到特別的親切吧?

結論與建議

透過本篇的實作，我們可以清楚看到 Athena 在 Data Lakehouse 架構中的角色：

1. 低門檻與即用即查

   • 不需要維護伺服器，只要會寫 SQL，就能即時查詢 S3 上的資料。

2. 與 Glue Data Catalog 緊密整合

   • Glue Catalog 提供 Schema，Athena 負責查詢，兩者搭配能讓資料湖的數據真正「可被使用」。

3. 最佳實踐建議

   • 驗證數據：ETL/Workflow 執行完後，用 Athena 立即檢查數據正確性。
   • 提升效能：建議將 Raw CSV/JSON 轉換為 Parquet 或 ORC，以減少查詢成本並提升效能。
   • 分層查詢：在 Silver、Gold 層查詢比 Raw 層更有效率，因為這些層已做過 Schema 校正與最佳化。
   • 控制成本：Athena 的收費依照「掃描資料量」計價 → 建議壓縮檔案、使用列式格式並加上 Partition。

💡 總結來說，Athena 是一個 驗證、探索與輕量分析的利器，讓我們能快速檢視數據處理成果，並成為後續 BI 報表與數據應用的基石。

下篇預告

在完成資料查詢與驗證後，下篇我們回到 「Day20 淬鍊之章-重新設計 Data Pipeline 流程」 來將 Day18 說的使用場景重新思考，並簡易的說明什麼場景適合用什麼服務來設計 Data Pipeline。

參考資料

• Amazon Athena 官方文件
• AWS Glue Data Catalog 官方文件
• Athena 定價資訊
• 最佳實踐：使用 Parquet/ORC 格式提升 Athena 效能