Amazon Athena 是 AWS 資料工程師在需要直接對 S3 資料進行隨機分析時會使用的無伺服器互動式 SQL 服務，在 DEA-C01 考試中，網域 3 的問題中大約每六題就有一題涉及 Athena 查詢與工作群組。陷阱很少關於是否使用 Athena — 陷阱幾乎總是關於成本。Athena 按掃描的 TB 數計費，而一個粗心的工程師如果忘記進行分區或選擇欄位式格式，可能會執行一個掃描 10 TB 的 Athena 查詢，並從單個儀表板產生五位數美元的月度帳單。來自 Tutorials Dojo、ExamCert.App 和 Camille Chang 的 dev.to 文章的研究指南都指出了相同的模式：考生知道 Athena 的存在，但他們無法正確回答詢問「Athena 成本激增，您首先更改什麼」的情境問題，並給出正確的排序清單。
本指南旨在將 Athena 查詢與工作群組轉化為維運肌肉記憶。它涵蓋了 Athena 的定義、驅動每個架構決策的每 TB 掃描定價模型、分區 + 欄位式格式 + 壓縮的成本三位一體、分區投影與 MSCK REPAIR TABLE 的比較、用於查詢隔離和資料掃描限制的工作群組、用於具體化中間結果的 CTAS、透過 Lambda 連接器的聯合查詢、用於 Spark 的 Athena Notebooks，以及隱藏在情境問題中的規範 Athena vs S3 Select vs Redshift Spectrum 考試陷阱。
什麼是 Amazon Athena？
Amazon Athena 是一種全受管、無伺服器的互動式查詢服務，可對儲存在 S3 中的資料執行 SQL（並透過聯合查詢，對許多其他來源執行）。在底層，Athena 使用開源的分散式 SQL 引擎 — 引擎版本 3 使用 Trino（之前的引擎版本 2 使用 Presto），由 AWS 代表您營運。您編寫標準 SQL，AWS 分配運算資源、執行查詢、將結果返回到 S3 位置，並根據掃描的位元組數向您計費。無需佈建叢集，無需調整節點大小，無需修補軟體。
為什麼 S3 上的無伺服器 SQL 很重要
在 Athena 出現之前，查詢 S3 資料意味著要麼啟動 EMR 叢集，要麼將資料載入 Redshift，要麼執行 Glue 作業來提取樣本。每條路徑至少需要幾分鐘時間，而且其中許多路徑需要熟悉 Hadoop 或 Spark 的工程師。Athena 將整個模式簡化為一個針對已在 Glue 資料目錄中註冊為資料表的 S3 前置詞的 SELECT 陳述式。無伺服器模型意味著單個隨機查詢除了掃描的位元組外沒有最低成本，這使得 Athena 成為單次調查、儀表板後端和管道驗證的規範工具。
Trino 引擎版本
Athena 公開了兩個引擎版本。引擎版本 2 基於 Presto，是舊工作群組的舊版預設值；引擎版本 3 基於 Trino，支援更多 SQL 函數，在 Iceberg 資料表上具有更好的效能，並且是 Lambda 中 SQL UDF 等較新功能所必需的。新工作群組預設為引擎版本 3。考試期望您知道兩者之間存在差異；具體的函數級差異超出了範圍。
Athena 定價 — 每 TB 掃描量
圍繞 Athena 查詢和工作群組的每個架構決策都追溯到一個事實：AWS 為 Athena 掃描的資料計費，而不是它返回的資料。
定價公式
Athena 按掃描的 TB 數收費，每場查詢的掃描位元組數計數器會無條件進位到最近的 10 MB，每場查詢最低 10 MB。一個返回單行但掃描 100 GB 資料表的查詢與返回 100 GB 資料的查詢成本相同。取消的查詢仍會對取消前掃描的內容計費。除了 10 MB 的最低限制外，沒有單次查詢的基礎費用。
「掃描」代表什麼
Athena 從 S3 讀取滿足查詢所需的檔案範圍。對於原始 CSV，「需要」意味著整個檔案，因為 CSV 無法進行範圍讀取。對於 Parquet，「需要」意味著僅讀取 SELECT 子句中引用的欄位區塊、僅讀取統計資訊顯示符合條件的資料列組，以及僅讀取其 Hive 前置詞與 WHERE 子句相符的分區。針對相同資料集的 CSV 與 Parquet 執行相同的邏輯查詢，針對 CSV 的掃描位元組數可能高出十倍 — 成本也高出十倍。這就是為什麼 DEA-C01 考生必須對欄位式格式瞭如指掌的核心原因。
壓縮檔案大小
Athena 根據其讀取的壓縮位元組數計費，而不是解壓縮後的邏輯大小。一個 1 TB 的 CSV 檔案，如果使用 gzip 壓縮到 200 GB，掃描成本為 0.2 TB，而不是 1 TB。採用 Snappy 壓縮的 Parquet 通常可以對現實世界的資料提供 5 到 10 倍的壓縮，結合欄位剪枝 (column pruning) 和謂詞下推 (predicate pushdown)，可顯著降低成本，使 Athena 在大規模情況下具有經濟效益。
Athena 按掃描的 TB 數計費，每場查詢最低 10 MB，其中「掃描」是指 Athena 為了滿足查詢而實際從 S3 讀取的壓縮位元組。 如果工程師認為 Athena 按返回的資料列、查詢持續時間或解壓縮後的邏輯大小計費，估計值將會出現一個數量級的偏差。DEA-C01 考試將此作為成本計算問題和架構建議問題：「Athena 成本正在增加且資料量正在增長，什麼操作最能降低成本？」答案始終是相同的三位一體 — 對資料進行分區、轉換為 Parquet 並應用 Snappy 或 ZSTD 壓縮。這些操作都不會改變資料；三者都減少了掃描的位元組。
成本三位一體 — 分區、欄位式格式、壓縮
三種最佳化方式相互結合，共同實現了使 Athena 服務在生產環境中具有經濟可行性的成本降低。
分區 — Hive 風格佈局
Athena 理解 Hive 風格的分區佈局，其中資料夾前置詞對分區欄位值進行編碼，例如 s3://bucket/orders/year=2026/month=05/day=02/。當查詢包含 WHERE year=2026 AND month=05 AND day=02 時，Athena 僅讀取匹配的分區前置詞，並跳過所有其他天、週和年份。一個典型的按日期分區的資料集，在針對單日查詢時，相對於多年歷史紀錄，可以減少 99% 的掃描量。
欄位式格式 — Parquet 或 ORC
Parquet 和 ORC 逐欄儲存資料，而不是逐列儲存。針對 Parquet 執行的 SELECT customer_id, order_total FROM orders 僅讀取 customer_id 和 order_total 欄位區塊 — 它不會讀取 product_description、shipping_address 或數十個其他欄位。針對 CSV 執行相同的查詢則會讀取每一列的每個位元組。Parquet 加上欄位剪枝通常根據欄位數量提供 5 到 20 倍的掃描減少。
壓縮 — Snappy, ZSTD, GZIP
在 Parquet 檔案中，單個欄位區塊會被壓縮。Snappy 是預設值且解壓速度快；ZSTD 壓縮得更緊湊，但 CPU 成本略高；GZIP 壓縮率最高但解壓最慢。對於 Athena，越來越推薦 ZSTD，因為 Athena 的運算成本已攤銷在每 TB 價格中，而 ZSTD 減少了驅動帳單的讀取位元組數。
三者結合
一個現實世界的生產轉換：一個 10 TB 的 CSV 資料集按日期分區，轉換為帶有 Snappy 的 Parquet，並使用 WHERE date='2026-05-02' AND customer_segment='premium' 且選取三個欄位進行查詢。天真掃描：10 TB。分區掃描：30 GB (單日)。加上欄位剪枝：6 GB (15 個欄位中的 3 個)。加上 Snappy 壓縮：1.2 GB。從 10 TB 到 1.2 GB 大約減少了 8000 倍 — 成本從每次查詢 50 美元降至不到 1 美分。
分區投影 vs MSCK REPAIR TABLE
兩者都是告知 Athena 分區存在與否的機制；它們具有非常不同的維運特性。
MSCK REPAIR TABLE
MSCK REPAIR TABLE 是舊有的 SQL 命令，它掃描 S3 前置詞樹、查找 Hive 風格的分區資料夾，並將其作為分區註冊到 Glue 資料目錄中。它可以運作但速度很慢 — 掃描時間隨分區數量線性增長，非常高基數 (high-cardinality) 的資料集（數年的每小時分區）每次修復可能需要幾分鐘。每當新分區到達時都必須重新執行。Glue 爬蟲是受管的替代方案，但同樣受到「掃描並註冊」模式的困擾。
分區投影 (Partition Projection)
分區投影完全消除了對目錄的往返請求。Athena 不再詢問目錄「此資料表存在哪些分區」，而是根據資料表上聲明的組態來計算分區值：整數範圍、日期範圍、列舉值或從 WHERE 子句注入的值。針對具有傳統分區的 10 年每小時分區表進行查詢會產生數千次目錄呼叫；使用分區投影則產生零次。分區投影透過資料表屬性進行組態，如 projection.enabled=true, projection.year.type=integer, projection.year.range=2020,2030。
如何選擇
對於分區值遵循可預測模式（日期範圍、每小時貯體、區域代碼、一組已知租戶 ID）的任何資料表，分區投影是正確答案。當分區值不可預測或零星到達時，MSCK REPAIR TABLE 或 Glue 爬蟲是必要的。考試將此設為效能陷阱：「團隊每小時執行一次 MSCK REPAIR TABLE 且查詢緩慢」，答案是分區投影。
MSCK REPAIR TABLE 是正確的但在大規模情況下很昂貴，而分區投影對於可預測的分區佈局來說，使它變得不再必要。 在每次查詢或按排程預設執行 MSCK REPAIR TABLE 的工程師正在支付隱藏成本 — SQL 命令本身需要時間，且目錄會隨著數千個分區項目的增加而增長，進而減慢後續的每個查詢計畫。DEA-C01 考試中常用類似「資料表有數年的每小時分區，且查詢計畫緩慢」的短語。如果答案選項包括分區投影，那就是正確的；建議擴展目錄或更頻繁執行 MSCK REPAIR TABLE 的選項則是干擾項。從第一天起，就應將任何具有可預測分區值的生產資料表轉換為分區投影。
Athena 工作群組 — 查詢隔離與成本控制
工作群組 (Workgroups) 是 Athena 的多租戶控制平面。每場查詢都在工作群組內執行，工作群組是資料工程團隊強制執行成本限制、隔離計費和應用治理的方式。
每場查詢與每個工作群組的資料限制
工作群組可以聲明每場查詢的資料掃描限制（取消任何掃描量超過限制的單個查詢）以及每個工作群組在時間窗口內的資料掃描限制（當工作群組在本小時或本日掃描量超過 X TB 時取消新查詢）。這些限制是防止因編寫不良的查詢或分析師沙盒而導致成本失控的主要制動器。
結果位置與加密
每個工作群組都指定了一個寫入查詢結果的 S3 位置。工作群組可以強制該位置是唯一允許的結果位置（防止分析師將結果洩漏到公共儲存貯體），並可以要求使用 SSE-S3、SSE-KMS 或 CSE-KMS 對結果進行伺服器端加密。工作群組層級的加密設定會覆蓋任何用戶端設定，這對於合規性使用案例來說是正確的強制執行模型。
基於 IAM 的存取
工作群組是一個 IAM 資源。政策會對特定的工作群組 ARN 授予 athena:StartQueryExecution 權限，讓您可以將行銷團隊分配到其專屬的工作群組，資料工程團隊分配到另一個，財務團隊分配到第三個 — 具有獨立的成本追蹤、獨立的掃描限制和獨立的結果位置。
查詢引擎版本固定
工作群組會固定其引擎版本。如果您的儀表板依賴於引擎版本 2 的查詢語義，請將儀表板工作群組設定為引擎版本 2，並讓工程工作群組使用引擎版本 3 進行新開發。
在生產環境中，務必為每個團隊或每個使用案例建立獨立的 Athena 工作群組 — 絕不要讓所有人共用預設的工作群組。 工作群組是您在 Athena 中限定成本限制、計費標記、結果加密和 IAM 存取範圍的方式。預設工作群組沒有掃描限制，也沒有強制加密，這對於任何生產環境來說都是錯誤的基準。推薦模式：一個具有高限制和 Parquet 結果格式的 data-engineering 工作群組；一個具有適度限制和引擎版本固定以確保穩定性的 bi-dashboards 工作群組；以及一個具有嚴格單次查詢限制（例如 10 GB）的 analysts-sandbox 工作群組，以防止初級分析師意外進行全表掃描。為每個工作群組貼上標籤以進行成本分配。DEA-C01 考試會測試關於成本失控、隔離合規團隊或區分生產與開發的情境。
CTAS — CREATE TABLE AS SELECT
CTAS 是 Athena 將查詢結果具體化 (materializing) 為新資料表的機制。
CTAS 的功能
CREATE TABLE new_table WITH (format='PARQUET', external_location='s3://bucket/path/') AS SELECT ... 執行 SELECT、將結果以 Parquet（或 ORC, JSON, TEXTFILE, AVRO）格式寫入 S3 指定位置，並在 Glue 資料目錄中註冊新資料表。後續針對 new_table 的查詢將讀取具體化後的資料，而不是從來源重新計算。
用於管道階段的 CTAS
規範的管道模式：將原始 CSV 擷取到 S3，然後執行 CTAS 將 CSV 轉換為分區 Parquet，並註冊精選資料表 (curated table) 以供下游查詢使用。每位分析師的查詢都命中 Parquet 而非 CSV — 轉換成本在 CTAS 執行時支付一次，並分攤到數千個後續查詢中。
帶有分區和儲存貯體化 (Bucketing) 的 CTAS
CTAS 支援 partitioned_by 以在輸出中編寫 Hive 風格的分區，並支援 bucketed_by 以在分區內對檔案進行儲存貯體化以進行聯結最佳化。從單個檔案 CSV 寫入分區 Parquet 的 CTAS 是最簡單的 Athena ETL 管道。
限制與注意事項
CTAS 預設每場查詢最多寫入 100 個分區；此限制可組態但有上限。INSERT INTO 可以在 CTAS 之外附加額外的分區，當分區數量增長時，建議在目標資料表上使用分區投影。
聯合查詢 — Athena 延伸至 S3 之外
Athena 的聯合查詢功能使用 Lambda 連接器在同一場 SQL 中讀取非 S3 來源。
工作原理
您安裝一個連接器 — 這是發佈在 AWS Serverless Application Repository 中的 Lambda 函數，它知道如何讀取 DynamoDB, RDS PostgreSQL, RDS MySQL, Aurora, Redshift, ElastiCache, DocumentDB, OpenSearch 或任何其他 AWS 或社群編寫的來源。Athena 將連接器註冊為目錄中的「資料來源」。然後，查詢可以在一個 SELECT 中將 S3 資料表聯結到 DynamoDB 資料表再聯結到 Postgres 資料表。
何時使用聯合查詢
當您需要一次性的跨來源聯結，且先將資料 ETL 到 S3 是大材小用時，聯合查詢是正確的。當相同的聯結重複執行時，它是錯誤的 — 每次查詢的連接器延遲和 Lambda 成本會累積，正確的答案應是按排程將來源導入 S3 的 Glue 或 DMS 作業。
連接器定價
聯合查詢的成本為每 TB 掃描費用加上連接器的 Lambda 呼叫成本。對於非常小的輔助資料表（由 50 個國家代碼組成的 Postgres 查找表），成本微不足道；對於大型來源資料表，Lambda 執行時間和記憶體將佔據主導成本。
Athena Notebooks — 用於互動式分析的 Spark
Athena Notebooks 是內建於 Athena 主控台的 Apache Spark 互動式筆記本環境。
定義
這是一個由 Athena 管理的 Spark 工作節點支援的 Jupyter 風格筆記本。您在單元格中編寫 PySpark、Spark SQL 或 Spark Scala，筆記本會針對從 Glue 資料目錄和 S3 讀取的 Spark 工作階段執行。工作階段會根據工作負載自動擴展工作節點。
何時使用筆記本而非 SQL
SQL 足以處理 90% 的 Athena 工作負載。當分析需要 Python 庫（pandas, NumPy, scikit-learn 用於描述性統計）、互動式 DataFrame 操作或從 Spark 分散式混排 (distributed shuffle) 中受益的大型資料表聯結時，筆記本是正確的。筆記本工作階段按 DPU 小時計費，類似於 Glue Spark 作業。
Athena Notebooks vs Glue Notebooks vs SageMaker Studio
Athena Notebooks 與 Glue 資料目錄緊密耦合，是已經在 Athena 主控台中的分析師阻力最小的路徑。Glue Notebooks 是 Glue ETL 開發經驗的一部分，當筆記本原型將被保存為 Glue ETL 作業時，它是正確答案。當 ML 工作流程步驟是分析的一部分時，SageMaker Studio Notebooks 是正確答案。考試詢問前兩者；第三者更多是 MLA-C01 的主題。
Athena vs S3 Select vs Redshift Spectrum
三種服務都可以使用 SQL 語義查詢 S3 資料。了解每種服務的適用時機是 DEA-C01 上最高產的決策樹。
Athena
最適用於：對一個或多個 S3 物件進行隨機 SQL 分析、跨表聯結、複雜聚合、對非 S3 來源的聯合查詢。付費模式：按掃描的 TB 數計費。
S3 Select
最適用於：在檢索之前從單個 S3 物件中篩選資料列或欄位。當應用程式需要讀取 CSV 或 Parquet 檔案的一部分，並希望將篩選條件下推到 S3 以節省頻寬時使用。無法跨物件聯結，無法聚合，無法 UNION。付費模式：按返回的 GB 數加上掃描的 GB 數計費，對於單物件篩選案例，每位元組成本低於 Athena。
Redshift Spectrum
最適用於：從 Redshift 叢集查詢 S3 資料，特別是當同一個查詢需要將 S3 資料與叢集內駐留的資料表聯結時。對於資料湖加資料倉儲混合模式非常有用。付費模式：按掃描的 TB 數計費（類似於 Athena）加上底層叢集成本。
決策規則
如果工作負載是從應用程式內部進行單物件篩選，選擇 S3 Select。如果工作負載是互動式隨機 SQL 或由 S3 資料支援的儀表板，選擇 Athena。如果工作負載是基於 Redshift 的分析平台，需要偶爾聯結到 S3 資料湖，選擇 Redshift Spectrum。考試中會描述兩個服務都可行但只有一個最優的情境 — 請仔細閱讀是否有「從應用程式內」(S3 Select)、「隨機分析師」(Athena)、「從 Redshift」(Spectrum) 等關鍵字。
白話文解釋 Amazon Athena Queries And Workgroups
三個具體的類比可以使 Athena 的成本模型和工作群組紀律變得直觀。
類比 1 — 按「走動距離」計費的餐廳
想像一家倉庫大小的自助餐廳，帳單不是根據您吃了什麼，而是根據您的服務勺在自助餐地板上穿過了多少距離。如果咖哩雞攤位在第 3 區，您直接走過去領一份然後離開，您只需支付少量費用。如果您在每個區域徘徊掃視有哪些菜，即使您吃的是同樣的一份菜，您也必須為整個走動過程付費。Athena 就是這家餐廳 — 帳單是「走動距離」（從 S3 掃描的位元組），而不是盤子裡的食物（返回的資料列）。分區就是掛上指示牌，引導您直接前往第 3 區，而無需穿過其他區域。欄位式格式是將自助餐拆分為單一菜餚攤位，因此選擇雞肉不需要走過甜點區。壓縮是縮小走道的寬度。分區 + Parquet + 壓縮的三位一體就是領班引導您走五步直接拿到菜，而不是讓您徘徊一個小時。工作群組是門口的售票亭，上面寫著「工程團隊每天最多可以走 10 TB 的距離，分析團隊最多 100 GB」— 防止一名用餐者在整個倉庫閒逛而導致餐廳破產。
類比 2 — 帶有索引卡片目錄的圖書館
想像一個老式圖書館，裡面有數百萬本書排列在書架上。如果沒有索引卡片目錄，尋找「所有 2025 年出版的關於機器學習的書」意味著要走遍每一條走道並閱讀每一本書的書脊 — 這很慢、很累且圖書管理員的時間成本很高。卡片目錄（Glue 資料目錄）告訴管理員每本書在哪條走道和哪個書架上，但目錄本身需要時間維護 — 每本新書都需要歸檔一張卡片（MSCK REPAIR TABLE 會重新掃描書架以歸檔新卡片，在大規模情況下很慢）。分區投影是用標籤規則取代卡片目錄：「每本書都按年份、主題上架，不需要卡片，規則會告訴您位置。」使用分區投影對日期分區表進行查詢的 Athena 會直接前往 year=2025 month=05，而無需諮詢任何目錄。工作群組是圖書館會員資格 — 普通讀者卡每月可以借閱 10 本書，研究員卡 1000 本，學生團體卡有嚴格上限，以防止 30 名學生在一次實地考察中意外耗盡圖書館預算。
類比 3 — 帶有電子收費與快速車道的收費公路
Athena 是一條收費公路，掃描的位元組數就是行駛距離。CSV 是緩慢的鄉村小路 — 每英里都是收費里程，因為汽車必須在每間房子前停下來檢查地址。Parquet 是快速收費車道 — 在每個出口都有指示牌告訴您答案是否在此區域，您可以跳過不需要的整個路段。分區是多條公路，每個州一條，因此限定在加州的查詢不會開過德州。壓縮是縮小道路本身，因此到達相同目的地的收費距離減半。工作群組是電子收費帳戶等級 — 個人帳戶在觸發警報前可以累積 100 美元的通行費，企業車隊帳戶 10000 美元，而租車帳戶為零（在第一次嘗試收費時取消）。CTAS 是那家從您的倉庫到最常去目的地建造私人快速道路的公司，只需支付一次建設成本，之後在那條路線上再也不用支付通行費。聯合查詢是側路 — 對於偶爾繞道進入 Postgres 或 DynamoDB 很有用，如果您每天都走則很昂貴。DEA-C01 考試要求您閱讀情境，確定工作負載應該在哪條車道上，並選擇能使通行費降至最低的答案。
Athena 查詢與工作群組的常見考試陷阱
DEA-C01 考試設置了一套穩定的陷阱。請記住這五個。
陷阱 1 — 將 Athena 用於即時需求
情境要求對串流資料提供亞秒級的查詢響應。錯誤答案：Athena。正確答案：根據情境的其餘部分，可能是用於 Apache Flink 的 Kinesis Data Analytics、OpenSearch 或即時資料庫。Athena 查詢至少需要幾秒鐘，大規模掃描則需要更多秒。
陷阱 2 — Athena 根據結果大小收費
考生根據返回單行的 SELECT COUNT(*) 計算 Athena 成本，並假設成本接近零。錯誤。該查詢仍會掃描資料表中每個檔案的每一行（除非套用了謂詞下推）。掃描量，而非結果大小，才是帳單金額。
陷阱 3 — 將 MSCK REPAIR TABLE 作為唯一的分區機制
情境描述了高分區計數和緩慢的查詢計畫。僅接受過舊模式培訓的考生建議更頻繁地執行 MSCK REPAIR TABLE。錯誤 — 分區投影才是正確答案。
陷阱 4 — 將聯合查詢用於高容量聯結
情境中 Athena 在每次儀表板重新整理時都將 S3 聯結到一個 1 TB 的 Postgres 資料表。聯合查詢在技術上可行，但每次查詢的 Lambda 成本和延遲是錯誤的。正確答案：使用 Glue 或 DMS 導入 S3，然後讓 Athena 查詢駐留在 S3 的複本。
陷阱 5 — 在生產環境中使用預設工作群組
情境描述了成本失控並詢問下一步。錯誤答案：教育分析師編寫更好的查詢。正確答案：為每個團隊建立工作群組，並設定每場查詢和每個工作群組的資料掃描限制，加上基於標記的成本分配。
使用 CTAS 將 CSV 擷取區一次性轉換為分區 Parquet 精選區，讓下游的每個 Athena 查詢永遠受益。 模式：擷取管道將原始 CSV 存放在 s3://bucket/raw/dataset/，每日 Glue 或 Athena CTAS 作業將前一天的 CSV 轉換為分區的 Snappy-Parquet 並存放在 s3://bucket/curated/dataset/year=YYYY/month=MM/day=DD/，分析師查詢僅存取精選區。CTAS 執行每天支付一次 Athena 掃描費用；分析師查詢之後每次查詢節省 5 到 20 倍成本。考試詢問「針對原始 CSV 的 Athena 查詢緩慢且昂貴，最具成本效益的長期修復方案是什麼」— 答案是 CTAS 驅動的 Parquet 轉換加上分區，而不是查詢調優、不是工作群組限制、也不是引擎版本升級。
關鍵數字與必須記住的 Athena 事實
定價
- 每掃描 1 TB 計費一次，每場查詢最低 10 MB
- 掃描位元組數計數器無條件進位到 10 MB
- 取消的查詢仍會對已掃描位元組計費
- 計算壓縮位元組，而非解壓縮後的邏輯大小
成本三位一體
- 分區 (Hive 風格的 year/month/day 前置詞)
- 欄位式格式 (Athena 偏好 Parquet)
- 壓縮 (Snappy 為預設，ZSTD 通常更好，GZIP 壓縮率最高)
分區機制
- MSCK REPAIR TABLE — 舊有方式，掃描 S3，大規模時緩慢
- Glue 爬蟲 — 受管掃描，模式類似
- 分區投影 — 零目錄呼叫，推薦用於可預測佈局
工作群組
- 每場查詢資料掃描限制（取消單場查詢）
- 每個工作群組在時間窗口內的資料掃描限制
- 強制執行結果位置和加密
- 每個工作群組固定引擎版本
- 用於細粒度存取的 IAM 資源
CTAS
- 預設每場查詢最多 100 個分區（可組態）
- 輸出 Parquet, ORC, JSON, TEXTFILE, AVRO
- 在 Glue 資料目錄中註冊新資料表
- INSERT INTO 可在 CTAS 之外附加分區
聯合查詢
- 來自 Serverless Application Repository 的 Lambda 連接器
- DynamoDB, RDS, Aurora, Redshift, ElastiCache, DocumentDB, OpenSearch
- 每 TB 掃描費加上 Lambda 成本
- 最適用於一次性的跨來源聯結，而非高容量重複操作
DEA-C01 考試優先事項 — Amazon Athena 查詢與工作群組。 此主題在 DEA-C01 考試中佔有很大權重。掌握每種 AWS 服務公開的權衡、決策邊界以及成本/效能觸發因素 — 考試將測試那些取決於了解哪種服務是錯誤答案的情境，而不僅僅是哪種是正確答案。
必須記住的關鍵事實。 牢記與此主題相關的服務層級限制、預設行為和 SLA 承諾。考試經常測試對特定預設值（持續時間、限制、重試行為、免費方案邊界）的記憶，記住確切數字往往是「正確」與「幾乎正確」之間的區別。
FAQ — Amazon Athena 查詢與工作群組常見問題
Q1 — 我該如何最快地降低 Athena 查詢成本？
最快產生影響的方法是將 CSV 或 JSON 資料轉換為帶有 Snappy 壓縮的分區 Parquet，並使用與分區欄位匹配的 WHERE 子句。轉換透過 CTAS 或 Glue ETL 作業執行一次；從那時起，每場查詢僅讀取相關分區和所請求的欄位，且大小為壓縮後的位元組。根據工作負載的選擇性，典型的降幅為 10 到 1000 倍。工作群組資料掃描限制是安全網，而非最佳化手段 — 它們取消失控的查詢，但不會使合法查詢變得更便宜。錯誤答案是「調優 SQL」— 如果底層儲存強制執行全掃描，Athena 的計畫程式也無能為力。
Q2 — 何時應使用分區投影而不是 MSCK REPAIR TABLE 或 Glue 爬蟲？
每當分區值遵循可預測模式時，請使用分區投影 — 例如日期範圍、每小時貯體、一組已知區域代碼、列舉中的租戶 ID。分區投影完全消除了目錄往返，可擴展到數百萬個邏輯分區而不會減慢查詢計畫程式，並移除了執行 MSCK REPAIR TABLE 或排程爬蟲的維運負擔。當分區值不可預測、資料由無法承諾分區命名慣例的外部系統交付，或者資料表足夠小以至於維運簡單性勝過目錄成本時，請使用 MSCK REPAIR TABLE 或 Glue 爬蟲。對於涉及「高分區計數」或「查詢計畫緩慢」的 DEA-C01 考試情境，分區投影是正確答案。
Q3 — 如何防止分析師意外執行掃描數 TB 的查詢？
為每個分析師團隊建立一個專屬的 Athena 工作群組，並組態一個合理的單場查詢資料掃描限制 — 沙盒為 10 GB，分析師團隊為 100 GB，工程工作群組則更高。Athena 會取消任何掃描量超過限制的單個查詢，並在帳單爆炸前向分析師返回錯誤。結合每個工作群組的時間窗口限制（例如，每個工作群組每天 1 TB）作為第二道安全網，以防止使用者執行許多累計產生高額帳單的小型查詢。為每個工作群組貼上標籤以進行成本分配，以便財務部門可以在 Cost Explorer 中查看每個團隊的支出。在生產帳戶中強制禁用預設工作群組。
Q4 — 什麼時候應該使用 Athena vs Redshift Spectrum vs S3 Select？
S3 Select 適用於應用程式讀取單個 S3 物件的一部分 — 將篩選條件下推到 S3 以節省檢索頻寬。它無法聯結、無法聚合、無法跨越多個物件。Athena 適用於跨一個或多個 S3 物件的隨機 SQL，具有完整的 SQL 語義，包括聯結、聚合、視窗函數和聯合查詢。Redshift Spectrum 適用於基於 Redshift 的分析平台，需要在同一場查詢中將 S3 資料湖表聯結到 Redshift 叢集表 — Spectrum 作為 Redshift 查詢的一部分執行，而不是獨立執行。決策規則：應用程式讀取一個物件 => S3 Select；隨機分析師對資料湖執行 SQL => Athena；現有 Redshift 叢集聯結到 S3 資料 => Redshift Spectrum。
Q5 — CTAS 如何融入資料湖架構？
CTAS 是將原始擷取區轉換為精選查詢區最常見的模式。管道：擷取將 CSV 或 JSON 存放在 s3://bucket/raw/，一個排程的 CTAS 作業執行 CREATE TABLE curated_dataset WITH (format='PARQUET', partitioned_by=ARRAY['year','month','day']) AS SELECT ... FROM raw_dataset WHERE ...，精選資料表在 Glue 資料目錄中註冊，儀表板和分析師僅查詢精選資料表。CTAS 執行是管道支付的一次性掃描成本；下游查詢則永遠支付較低的 Parquet 成本。對於超過 100 個分區 CTAS 限制的極大資料集，請在後續查詢中使用 INSERT INTO 附加額外的分區。
Q6 — Athena 可以查詢另一個 AWS 帳戶中的資料嗎？
可以，透過跨帳戶 Glue 資料目錄存取。資料擁有者帳戶在其 Glue 資料目錄中註冊 S3 前置詞，並透過 Lake Formation 跨帳戶授權或 Glue 資料目錄資源政策授予取用者帳戶權限。取用者帳戶建立一個指向來源資料庫的資源連結，Athena 查詢資源連結就像查詢本地資料表一樣。S3 儲存貯體政策也必須授予取用者帳戶對底層 S3 物件的讀取權限，如果使用了 SSE-KMS，則 KMS 金鑰政策必須允許解密。DEA-C01 考試將此設為「跨業務單位的共用資料湖」情境；答案是 Lake Formation 跨帳戶授權加上 S3 儲存貯體政策加上 KMS 金鑰政策。
Q7 — Athena Notebooks 與 Glue 和 SageMaker 有什麼關係？
Athena Notebooks 是由 Athena 管理的 Apache Spark 筆記本，按 DPU 小時計費，並與 Glue 資料目錄緊密整合。對於已經在 Athena 主控台且需要 Python 加 Spark 的分析師來說，它們是阻力最小的路徑。Glue Notebooks 是 Glue ETL 開發經驗的一部分，執行在相同的 Spark 後端，專為原型設計將成為 Glue 作業的 ETL 程式碼而設計。SageMaker Studio Notebooks 是通用的 ML 和資料科學筆記本，可以從 Glue 目錄讀取，但側重於 ML 工作流程。對於 DEA-C01，重點在於分析師背景下的隨機 Spark 使用 Athena Notebooks，以及 ETL 開發使用 Glue Notebooks；SageMaker 在很大程度上超出了考試指南的範圍。
延伸閱讀 — Athena 官方 AWS 文件
權威的 AWS 來源包括 Athena 使用者指南（概念、分區投影、工作群組、CTAS）、Athena 聯合查詢文件（連接器、資料來源、IAM）、Athena Notebooks 文件（Spark 工作階段、筆記本生命週期）以及用於目錄管理的 Glue 資料目錄文件。AWS 大數據部落格有多篇關於分區投影、CTAS 管道模式和工作群組成本控制案例研究的深入探討文章。AWS Well-Architected Data Analytics Lens 涵蓋了分析階段的 Athena。AWS Samples GitHub 存儲庫包含了基於 Athena 的資料湖模式的端到端範例架構。最後，Skill Builder DEA-C01 Exam Prep Standard Course 有一個專門的分析模組，以情境形式講解了規範的 Athena 陷阱。