Amazon Athena、AWS Lake Formation 與 Amazon QuickSight 共同構成 AWS data lake 的分析層。SAA-C03 考試的任務說明 3.5 要求你設計高效能的資料擷取與轉換解決方案，而 Athena、Lake Formation 與 QuickSight 正是考試用來測驗你對 serverless 查詢、集中式治理與商業智慧掌握程度的三大服務。這個主題是 SAA-C03 藍圖中情境題最密集的部分之一，因為一道 data lake 題目可能同時混合臨時 SQL、細粒度權限、儀表板嵌入，以及 Athena vs Redshift vs EMR 的經典選擇。因此，熟練掌握 Amazon Athena、AWS Lake Formation 與 Amazon QuickSight，大約能影響正式考試中五到七道題的得分。
本學習指南涵蓋 SAA-C03 考試會測驗的每一個 Amazon Athena 功能（包含 Athena Federated Query、Athena workgroups、query result reuse，以及結合欄位格式的分區策略）、每一個必須記熟的 AWS Lake Formation 概念（blueprints、權限模型、用於 ABAC 的 LF-Tags、row-level 與 column-level security，以及資料篩選），案例分析中會出現的 Amazon QuickSight 功能（SPICE、嵌入式分析、ML Insights、row-level security），Amazon OpenSearch Service 在文字與日誌搜尋中的角色，以及 Amazon Athena vs Amazon Redshift vs Amazon EMR 的決策框架。最後以考生最常答錯的五道 FAQ 作為收尾。
AWS 上的 Data Lake 與分析架構是什麼
Data lake 是一個集中式儲存庫，可任意規模地存放結構化、半結構化與非結構化資料，通常建構在 Amazon S3 上，並讓多種分析服務直接就地讀取資料，無需移動資料。在 AWS 的術語中，data lake 是 S3 加上 AWS Glue Data Catalog（元資料層），由 AWS Lake Formation（權限層）治理，再由 Amazon Athena（serverless SQL）、Amazon Redshift Spectrum（倉儲級 SQL）或 Amazon EMR（Spark 與 Hadoop）查詢，最後由 Amazon QuickSight 視覺化呈現。
為什麼 data lake 模式在 SAA-C03 特別受青睞
SAA-C03 考試偏好 data lake 模式，因為它符合五大架構支柱：成本優化（S3 儲存費用低廉，Athena 僅按掃描的 TB 數計費）、安全（Lake Formation 在 IAM 與 KMS 之上提供細粒度存取控制）、可靠（S3 提供十一個九的耐久性）、在分區與欄位格式的加持下具備高效能，以及因目錄跨服務共享而具備高營運效率。任何考試情境只要提到「存放所有原始資料」、「隨需查詢」、「不同團隊需要不同視角」或「為業務單位建立儀表板」，解答幾乎都是 Amazon Athena 加上 AWS Lake Formation 加上 Amazon QuickSight。
考試反覆使用的參考分析架構
考試持續圍繞同一條參考管線：擷取端（Amazon Kinesis Data Firehose 或 AWS DMS）將原始資料落地至 Amazon S3，AWS Glue crawlers 將 schema 登錄至 AWS Glue Data Catalog，AWS Lake Formation 套用權限，Amazon Athena 對 S3 資料執行臨時 SQL，Amazon QuickSight 建立儀表板，Amazon OpenSearch Service 為日誌與文字子集建立索引以供搜尋。請熟記這條管線；SAA-C03 情境題所描述的都是它的各種變形。
白話文解釋 Athena、Lake Formation 與 QuickSight
Amazon Athena、AWS Lake Formation 與 Amazon QuickSight 聽起來可能很抽象，以下三個類比有助於在 SAA-C03 考試中具體理解這些服務。
類比一 — 誠品書店（綜合書店）
把你的公司 data lake 想像成一家大型的誠品書店。
- 書架上的書就是 Amazon S3 中的原始檔案。
- 書目資料庫就是 AWS Glue Data Catalog——它告訴你每本書在哪個樓層、哪個書架、哪個位置。
- 書店經理就是 AWS Lake Formation——他決定哪位讀者可以翻閱哪個區域、哪個章節，甚至哪個段落（row-level 與 column-level security）。他也能發放會員識別卡（LF-Tags），凡是持有藍色卡的會員，都可以進入所有藍色標籤的書區。
- 閱覽桌就是 Amazon Athena——你帶著一個 SQL 問題坐下來，Amazon Athena 就地翻閱書本，不需要借走，並按照翻閱的頁數向你收費。
- 牆上的精選海報就是 Amazon QuickSight 儀表板——為不想自己翻書的人提供濃縮的視覺洞察。
- 快速搜尋終端機就是 Amazon OpenSearch Service——輸入關鍵字，立即取得相符的段落。
如果 SAA-C03 題目描述一個多團隊以不同方式、不同權限查詢的中央儲存庫，這個書店類比告訴你答案就是由 AWS Lake Formation 治理的 data lake，上層搭載 Amazon Athena 與 Amazon QuickSight。
類比二 — 開卷考試
Amazon Athena 的行為就像一場開卷考試。
- 你不需要事先將任何資料載入資料庫；資料就靜靜留在 Amazon S3，就像書本放在書架上。
- 你用寫答案的方式下 SQL 查詢——Amazon Athena 只翻閱與你問題相關的頁面。
- 如果你的「教科書」按章節整齊分類（partitions），並以精簡格式印刷（Apache Parquet 或 ORC），Amazon Athena 幾秒鐘就能完成，且只收取它讀取的頁數費用。
- 如果你的教科書是一疊亂糟糟的 CSV，Amazon Athena 仍然能回答，但需要翻閱更多頁面，費用也更高。
這就是 SAA-C03 關於 Amazon Athena 成本與效能的核心教訓：分區加上欄位格式，等於掃描更少位元組，等於更低的 Amazon Athena 費用與更快的回應速度。
類比三 — 門禁卡系統
AWS Lake Formation 就像一套企業門禁卡系統。
- 你的 IAM 身分是你在前台建檔的名字。
- 你的 Lake Formation 權限是你門禁卡上的 RFID 授權——「這張卡可以進入 A 和 B 資料庫、X 和 Y 資料表、第 1 到第 4 欄，但只能看到 region = APAC 的那幾列資料。」
- LF-Tags 是貼在門禁卡上的彩色貼紙——「所有貼有藍色貼紙的卡片可以開啟所有藍色房間」，這樣管理員就不需要逐一更新每張卡片。
- Data filters 是單一房間內的局部存取——你可以進入會議室，但只能坐在前三個座位。
任何 SAA-C03 題目只要提到「不同分析師必須看到不同欄位」或「承包商只能看到彙總後的列資料」，都是 AWS Lake Formation 細粒度存取的考題，而不是 IAM 考題。
Amazon Athena — S3 上的 Serverless SQL、計費方式與分區策略
Amazon Athena 是一項互動式查詢服務，可對 Amazon S3 中儲存的資料執行標準 ANSI SQL，無需管理任何伺服器。它基於 Presto 和 Trino 構建，以 AWS Glue Data Catalog 作為元資料存放區，並按掃描資料的 TB 數計費。Amazon Athena 是 SAA-C03 中臨時 SQL、日誌分析，以及所有「不搬移資料即可查詢 data lake」情境的預設答案。
必須熟知的 Amazon Athena 核心運作機制
Amazon Athena 直接從 Amazon S3 讀取資料，無需佈建叢集，也無需規劃容量。你可以在 Amazon Athena 主控台、透過 JDBC/ODBC 驅動程式，或透過 StartQueryExecution API 提交查詢，Amazon Athena 會回傳結果，並在 Amazon Athena 查詢結果 S3 儲存貯體中儲存一份副本。在多數區域，Amazon Athena 收取每 TB 掃描 USD 5.00 的費用（請確認最新定價），每次查詢最低計費 10 MB，DDL 陳述式免費。
Amazon Athena Federated Query
Amazon Athena Federated Query 讓你對非 S3 來源執行相同的 SQL，例如 Amazon DynamoDB、Amazon RDS、Amazon Redshift、Amazon DocumentDB、Amazon ElastiCache、HBase on Amazon EMR、SAP HANA、Snowflake 以及自訂來源。它透過從 AWS Serverless Application Repository 部署的 AWS Lambda 資料來源連接器運作，每個連接器會將 Amazon Athena 的查詢片段轉換為目標存放區的原生 API。在 SAA-C03 考試中，任何情境說到「對 S3 和 DynamoDB 執行單一 SQL join」或「不需 ETL 即可查詢地端資料庫」，就指向 Amazon Athena Federated Query。
Amazon Athena workgroups
Amazon Athena workgroups 是 Amazon Athena 內部的隔離與治理基本單元。Workgroup 可讓你區隔使用者、團隊與應用程式；強制執行每次查詢與每個 workgroup 的資料掃描上限；將 Amazon Athena 使用量指標發布至 CloudWatch；要求查詢結果加密；並控制查詢結果寫入的 Amazon S3 位置。你可以為每個 workgroup 指派不同的 IAM 政策，這是大型組織向不同業務單位分攤 Amazon Athena 費用的方式。資料使用量控制上限是 SAA-C03 常見的考試陷阱——上限設定於 workgroup 層級，當查詢超過掃描閾值時可自動取消。
Amazon Athena query result reuse
Amazon Athena query result reuse 是一項節省成本的功能，可將查詢結果快取到可設定的最長時間（最多 7 天）。在快取窗口內重新執行相同查詢時，Amazon Athena 會回傳快取結果，掃描資料量為零，因此費用也為零。此功能可在查詢層級或 workgroup 層級啟用。針對 SAA-C03 中「同一個儀表板查詢每 15 分鐘執行一次，我們想降低 Amazon Athena 成本」的情境，啟用 query result reuse 是第一個答案。
要降低 Amazon Athena 的成本與延遲，對 data lake 永遠要做三件事。第一，依高基數的 predicate 欄位（例如日期、區域或租戶）對 Amazon S3 中的資料進行分區。第二，以欄位格式儲存檔案——Apache Parquet 或 Apache ORC。第三，使用 Snappy 或 ZSTD 壓縮。分區讓 Amazon Athena 在查詢時跳過不需要的檔案，欄位格式讓 Amazon Athena 只讀取 SQL 涉及的欄位，壓縮則減少掃描的位元組數。三者合用，通常可將 Amazon Athena 成本降低 90% 以上。 Source ↗
分區策略與 partition projection
分區將一張資料表分散到多個 S3 前綴，讓 Amazon Athena 在查詢時裁剪不需要的檔案。經典的 Hive 式分區使用類似 s3://bucket/table/year=2026/month=04/day=20/ 的目錄名稱。對於擁有數千個分區的資料表，你可以啟用 partition projection，它將分區元資料儲存在資料表屬性中，而非 AWS Glue Data Catalog，從而免除執行 MSCK REPAIR TABLE 或 Glue crawlers 的需要。每當情境提到「非常大量的分區」或「每分鐘有新分區產生」，partition projection 就是 SAA-C03 的答案。
Apache Parquet 與 Apache ORC
Apache Parquet 與 Apache ORC 是欄位式檔案格式。由於 Amazon Athena 按掃描資料量計費，而 SQL 通常只參照眾多欄位中的少數幾個，欄位格式相較於列式 JSON 或 CSV，可將 Amazon Athena 的成本降低 30% 至 90%。Parquet 是 SAA-C03 的預設推薦格式。AWS Glue ETL 任務可將 CSV 或 JSON 轉換為 Parquet，Amazon Data Firehose 則可在寫入 Amazon S3 之前，即時將記錄轉換為 Parquet。
Athena 效能最佳化 — 分區、欄位格式與壓縮
Amazon Athena 的效能幾乎完全取決於它需要從 Amazon S3 讀取多少資料。SAA-C03 考試測驗四種最佳化手段。
手段一 — 分區裁剪
Amazon Athena 利用 WHERE 子句跳過整個分區。一個在以 dt 分區的資料表上過濾 WHERE dt = '2026-04-20' 的查詢，只會讀取單日的檔案。沒有分區 predicate 的查詢則掃描所有資料。分區裁剪完全免費，應是任何 SAA-C03 情境的第一個最佳化選項。
手段二 — 欄位格式
以 Apache Parquet 或 Apache ORC 儲存資料，讓 Amazon Athena 只載入 SQL 所涉及的欄位。從三十個欄位中 SELECT 三個欄位，相較於對 CSV 執行相同的 SELECT，掃描的位元組數約只有十分之一。
手段三 — 壓縮
Snappy 和 ZSTD 通常可將典型資料壓縮四到十倍，且支援分割，這對平行讀取很重要。GZIP 壓縮率更高，但不支援分割，因此 Amazon Athena 無法有效地分散工作。
手段四 — 檔案大小與數量
非常小的檔案會造成 Amazon Athena 的 listing 額外負擔。建議將檔案大小維持在 128 MB 至 1 GB 之間。大量微小檔案（small-file problem）是 SAA-C03 的經典陷阱；解決方式是使用 AWS Glue 或 Amazon EMR 合併檔案。
依最常使用的 WHERE predicate 欄位進行分區。以 Snappy 壓縮的 Apache Parquet 格式儲存資料。將檔案大小維持在 128 MB 至 1 GB 之間。使用 Athena workgroups 控制掃描上限。為重複執行的儀表板啟用 Athena query result reuse。這五個手段是 SAA-C03 每一道 Amazon Athena 成本最佳化題目的核心。 Source ↗
AWS Lake Formation — 集中式 Data Lake 治理與細粒度存取控制
AWS Lake Formation 是將原始 S3 data lake 轉化為受治理 data lake 的服務。它提供一個統一的地方來登錄 Amazon S3 位置、在 AWS Glue Data Catalog 中定義資料庫與資料表，並在資料庫、資料表、欄位、列與儲存格層級授予權限。AWS Lake Formation 權限由整合引擎強制執行，包括 Amazon Athena、Amazon Redshift Spectrum、Amazon EMR（搭配 runtime roles）、AWS Glue 與 Amazon QuickSight。
AWS Lake Formation 如何取代手動 S3 政策
在 AWS Lake Formation 出現之前，你要透過撰寫 S3 儲存貯體政策、IAM 政策與 KMS 金鑰政策來授予 data lake 存取權。有了 AWS Lake Formation，你以授予關聯式資料庫權限的方式來授予權限——GRANT SELECT ON TABLE sales.orders TO IAM_ROLE arn:aws:iam::...:role/Analyst。AWS Lake Formation 而非 S3 儲存貯體政策，才是具有最終決定權的存取控制層。當一個主體透過 Amazon Athena 查詢時，AWS Lake Formation 會核發臨時 S3 憑證，其範圍精確限定在該主體被允許看到的欄位與列。
AWS Lake Formation blueprints
AWS Lake Formation blueprints 是預建的工作流程，可將資料從常見來源擷取至 data lake。Blueprints 包括資料庫快照、資料庫增量載入，以及日誌檔案擷取（AWS CloudTrail、Elastic Load Balancing 存取日誌、AWS Classic Load Balancer 日誌）。Blueprint 會在背後自動產生 AWS Glue crawlers、任務與觸發器。在 SAA-C03 考試中，任何情境說到「以最少自訂程式碼快速將地端資料庫引入 data lake」，就指向 Lake Formation blueprint。
AWS Lake Formation 權限模型
AWS Lake Formation 權限定義在目錄物件上——資料庫、資料表與欄位——而非 S3 路徑。主要有兩種權限類型：資料權限（SELECT、INSERT、DELETE、ALTER、DROP、DESCRIBE）以及可授予權限（誰可以向其他人授予權限）。權限是累加的，任何查詢路徑只要缺少對應的 Lake Formation 授權，即使 IAM 主體擁有 s3:GetObject，也會被拒絕。
用於屬性型存取控制（ABAC）的 LF-Tags
LF-Tags 是你附加到資料庫、資料表或欄位上的鍵值對；你再授予主體存取特定標籤組合的所有資源。例如，將所有 PII 欄位標記為 sensitivity=pii，並授予 data-scientist 角色僅能讀取 sensitivity=public 的資源。透過 LF-Tags 實現 ABAC，遠比在數千張資料表上逐一授予明確權限簡單許多。每當情境提到「許多資料表、許多主體、標籤型策略」，SAA-C03 考試就會使用 LF-Tags。
LF-Tag 是 AWS Lake Formation 中的鍵值標籤，讓你在 AWS Glue Data Catalog 中實現屬性型存取控制。授權以標籤表達式而非明確的資源 ARN 為單位，因此治理規模可擴展至數千張資料表而無需逐一列舉。 Source ↗
Row-level 與 column-level security
AWS Lake Formation column-level security（稱為欄位篩選）限制主體可見的欄位。Column-level security 是 SAA-C03 中「分析師可以看到訂單總額，但不能看到客戶 PII」的解答模式。AWS Lake Formation row-level security（稱為列篩選）根據篩選表達式限制主體可見的列。Row-level security 是 SAA-C03 中「歐洲分析師只能看到 region = EU 的訂單」的解答模式。AWS Lake Formation 中的單一 data filter 可同時結合列篩選與欄位篩選，形成一個可重複使用的物件，再授予給主體。
資料篩選 — 儲存格層級安全性
AWS Lake Formation data filtering 將列篩選與欄位篩選合併為名為 data filters 的具名物件。一個 data filter 可包含列篩選表達式、包含或排除的欄位清單，並附加到特定的資料表。當主體透過 Amazon Athena 或 Amazon Redshift Spectrum 查詢時，AWS Lake Formation 會透明地套用 data filter。結果是儲存格層級安全性——允許的列與允許的欄位的交集——完全不需要改寫 SQL。
如果考試情境要求對 data lake 資料表實施 column-level、row-level 或儲存格層級的存取控制，答案是 AWS Lake Formation data filters 與 LF-Tags，而不是自訂的 IAM 與 S3 儲存貯體政策。原始 IAM 與 S3 只能授予或拒絕整個物件的存取；它們無法隱藏特定欄位或列。AWS Lake Formation 是唯一能提供與 Amazon Athena、Amazon Redshift Spectrum 及 Amazon EMR 整合的細粒度 data lake 治理服務。 Source ↗
Lake Formation 權限 vs S3 儲存貯體政策 — 多層存取控制
AWS Lake Formation 並不取代 IAM 或 S3 儲存貯體政策——它是疊加在其上的一層。SAA-C03 考試經常測驗評估順序。
三個層次
第一層是 IAM——主體必須擁有針對 Amazon Athena 或 Amazon Redshift API 動作的 IAM 權限（例如 athena:StartQueryExecution）。第二層是 AWS Glue Data Catalog 資源政策與 AWS Lake Formation 權限——只有當主體對請求的欄位與列擁有 SELECT 授權，AWS Lake Formation 才會核發 S3 憑證。第三層是底層的 S3 儲存貯體政策與 KMS 金鑰政策——AWS Lake Formation 所假設的 S3 資料存取角色需要 S3 與 KMS 權限。
Lake Formation 管理員
AWS Lake Formation 管理員是可以登錄 S3 位置、定義 LF-Tags 並授予權限的 IAM 主體。你在 Lake Formation 主控台中指定 Lake Formation 管理員。在 SAA-C03 中，Lake Formation 管理員（管理 Lake Formation 治理）與 data lake 消費者（執行 Amazon Athena 查詢）之間的區別是常考題。
AWS Lake Formation 治理透過 Amazon Athena、Amazon Redshift Spectrum、Amazon EMR 或 AWS Glue 進行的查詢。它不治理直接呼叫 s3:GetObject 的主體。如果你的安全態勢要求只有 Lake Formation 整合引擎才能讀取 data lake，你還必須限制 S3 儲存貯體政策，拒絕非 Lake Formation 角色的直接物件存取。許多 SAA-C03 考生忘記了 S3 這一層，誤以為 Lake Formation 是萬能的解決方案。 Source ↗
Amazon QuickSight — BI 儀表板、SPICE 記憶體引擎與 ML Insights
Amazon QuickSight 是 AWS 的雲端原生商業智慧服務。它以按使用者或按工作階段計費的方式，提供互動式儀表板、分頁報表、嵌入式分析與機器學習驅動的洞察。Amazon QuickSight 原生整合 Amazon Athena、Amazon Redshift、Amazon RDS、透過 AWS Lake Formation 存取的 Amazon S3、Salesforce，以及透過 Direct Connect 或 private link 存取的地端資料庫。
SPICE — 記憶體加速引擎
SPICE（Super-fast, Parallel, In-memory Calculation Engine）是 Amazon QuickSight 內部的欄位式記憶體快取。匯入 SPICE 的資料集以記憶體速度查詢，不受底層來源影響。SPICE 容量以每 GB 購買，每位 Amazon QuickSight 使用者通常有預設的 SPICE 配額。針對 SAA-C03 中「儀表板必須在數千名檢視者下保持回應，同時 Amazon Athena 成本必須維持低廉」的情境，SPICE 是答案——每小時刷新一次 SPICE，讓檢視者存取 SPICE，而非每次點擊都觸發 Amazon Athena 查詢。
嵌入式分析
Amazon QuickSight 嵌入式分析讓你可以將儀表板與創作體驗直接嵌入你的 SaaS 產品或內部入口網站，並以按工作階段計費的方式隨終端使用者活動彈性擴展。嵌入模式有兩種：registered-user embedding（每位終端使用者擁有 Amazon QuickSight 身分）與 anonymous embedding（終端使用者未經驗證，僅以你應用程式的工作階段識別）。嵌入式分析是 SAA-C03 中「SaaS 供應商想以低成本向數千名客戶使用者提供儀表板」的標準答案。
ML Insights
Amazon QuickSight ML Insights 利用內建機器學習偵測異常、預測未來數值，並產生自動敘述（儀表板的自然語言摘要），完全不需要撰寫任何 ML 程式碼。Amazon Q in QuickSight 更進一步，以自然語言問答延伸此功能——終端使用者輸入「上季利潤率最高的五個產品是什麼？」即可獲得答案。在 SAA-C03 中，這是「業務使用者想要 ML 驅動的儀表板，但沒有資料科學家」的解答模式。
QuickSight 中的 row-level security
Amazon QuickSight row-level security（RLS）在單一共享資料集中限制每位使用者或群組可見的列。你在一個權限資料集中定義 RLS 規則，將使用者對應到允許的列篩選值。QuickSight 中的 RLS 與 AWS Lake Formation row-level security 互補——Lake Formation 在 data lake 查詢層強制執行，QuickSight RLS 則在匯入的 SPICE 資料集上強制執行。SAA-C03 考試可能出現任一模式；正確答案取決於限制應在資料到達 QuickSight 之前發生（Lake Formation），還是在 QuickSight 內部發生（QuickSight RLS）。
當 Amazon QuickSight 透過 Amazon Athena、Amazon Redshift Spectrum 或 AWS Glue Data Catalog 查詢受 Lake Formation 治理的 data lake 時，AWS Lake Formation 權限會自動針對 Amazon QuickSight 主體強制執行。這意味著你可以在 AWS Lake Formation 中集中管理一次細粒度存取政策，讓它同時適用於 SQL 使用者與 Amazon QuickSight 儀表板，無需在兩個地方重複設定規則。 Source ↗
Athena vs Amazon Redshift — 臨時查詢 vs 資料倉儲的決策
這是 SAA-C03 分析類題目中被測驗最多次的單一區別。
Amazon Athena — 何時選用
當資料已存放在 Amazon S3、查詢為臨時或不頻繁、你希望以按掃描量計費的 serverless 定價避免閒置成本、不同團隊需要對同一批檔案有不同的視角，以及你想避免將資料 ETL 進倉儲時，Amazon Athena 是正確答案。Amazon Athena 本質上是 serverless，無需預熱時間，閒置時不產生費用。
Amazon Redshift — 何時選用
當你需要 PB 級的資料倉儲搭配複雜 join 及數百位業務使用者的重複查詢、需要對精選資料集市提供次秒級儀表板延遲、擁有可受益於 Reserved Instance 定價的可預測工作負載，或需要物化視圖、預存程序與 Amazon Redshift ML 等功能時，Amazon Redshift 是正確答案。Amazon Redshift Serverless 透過自動擴展容量與閒置暫停模糊了界線，但 Amazon Redshift 仍定位為「正規倉儲」，而 Amazon Athena 定位為「就地查詢 data lake」。
Amazon Redshift Spectrum — 橋接方案
Amazon Redshift Spectrum 讓 Amazon Redshift 叢集透過 AWS Glue Data Catalog 直接查詢 Amazon S3 中的資料，方式與 Amazon Athena 相同，但在 Amazon Redshift SQL 工作階段內執行，因此你可以將倉儲資料表與 data lake 資料表進行 join。在 SAA-C03 考試中，每當情境需要「將倉儲事實資料表與外部 S3 檔案 join，且不載入 S3 檔案」，就會出現 Amazon Redshift Spectrum。
Amazon EMR — 何時選用
當你需要對 Apache Spark、Apache Hadoop、Apache Hive、Apache HBase、Presto、Trino 或 Apache Flink 進行完整的程式化控制；當你執行長時間的批次作業，例如 TB 級 ETL、機器學習前處理或圖形處理；以及當你能透過任務機群使用 Spot Instances 節省成本時，Amazon EMR 是正確答案。Amazon EMR 預設不是 serverless（雖然 Amazon EMR Serverless 存在），且需要管理叢集生命週期。
SAA-C03 出題者喜歡設計三選一陷阱。Amazon Athena 適用於對 Amazon S3 進行無基礎設施的臨時 SQL。Amazon Redshift 適用於擁有專用容量與物化視圖的高並發企業資料倉儲。Amazon EMR 適用於需要框架層級控制的 Apache Spark 或 Apache Hadoop 程式碼優先的大數據處理。如果題目提到「臨時、不頻繁、serverless SQL」，選 Amazon Athena。如果提到「數千位 BI 使用者、次秒級儀表板、ETL 進精選資料集市」，選 Amazon Redshift。如果提到「Spark 作業、Hadoop、自訂程式碼、TB 級轉換」，選 Amazon EMR。 Source ↗
Amazon OpenSearch Service — 搜尋與日誌分析
Amazon OpenSearch Service 是受管的 OpenSearch（及舊版 Elasticsearch）引擎，可對文字與時間序列資料建立索引，提供次秒級搜尋。它與 Amazon Athena 互補——Amazon Athena 回答「依區域彙總營收」（分析 SQL），而 Amazon OpenSearch Service 回答「在過去 15 分鐘內找出所有包含 ERROR 的日誌行」（文字搜尋與可觀測性）。
SAA-C03 中何時選用 OpenSearch
當工作負載為日誌分析（應用程式日誌、AWS CloudTrail、VPC Flow Logs、Elastic Load Balancing 存取日誌）、全文搜尋（商品目錄搜尋、wiki 搜尋）、搭配 OpenSearch Dashboards 的即時可觀測性，或使用 Security Analytics 外掛程式的安全資訊與事件管理（SIEM）時，選用 Amazon OpenSearch Service。SAA-C03 常見的管線是 Amazon Data Firehose → Amazon OpenSearch Service 用於日誌，同時 Amazon Data Firehose → Amazon S3 → Amazon Athena 用於長期分析。
OpenSearch Serverless
Amazon OpenSearch Serverless 透過獨立地自動擴展索引與搜尋工作負載的 OpenSearch Compute Units（OCUs），免除了叢集規模調整的需要。當情境說「搜尋流量不固定、不需要容量規劃、按使用量付費」時，它就是 SAA-C03 的答案。
建立與保護 Data Lake — Bronze/Silver/Gold 分區架構
多區域（或稱獎章式）data lake 模式是 SAA-C03 考試的架構參考模式。
Bronze（原始）區
Bronze 區存放資料從來源到達時的原始、未修改資料——不強制執行 schema，通常保留原始格式（JSON、CSV、XML）。擷取來源包括 Amazon Kinesis Data Firehose、AWS DMS、AWS DataSync 或直接由生產者寫入。AWS Lake Formation 登錄 S3 位置，並授予嚴格的權限（通常只開放給 ETL 角色）。
Silver（精選）區
Silver 區存放已清理、去重、強制執行 schema 的資料，通常以 Apache Parquet 格式並依擷取日期分區。AWS Glue 或 Amazon EMR 將 bronze 轉換為 silver。AWS Lake Formation 使用 LF-Tags 向分析師角色授予特定欄位的 SELECT 權限。
Gold（可用）區
Gold 區存放業務就緒的彙總資料與維度模型，專為特定 BI 使用案例設計。AWS Glue 或 Amazon Redshift 物化 gold 資料表。Amazon QuickSight 儀表板透過 Amazon Athena 或 Amazon Redshift Spectrum 讀取 gold 區資料。
使用 LF-Tags 進行區域層級治理
為每張資料表指派 LF-Tag zone=bronze|silver|gold。授予 ETL 角色存取 zone=bronze,zone=silver。授予分析師角色存取 zone=silver,zone=gold。授予業務使用者角色僅存取 zone=gold。一個 LF-Tag 階層即可擴展至數千張資料表。這是 SAA-C03 考試獎勵的參考模式。
視覺化策略 — QuickSight vs 第三方 BI 工具
SAA-C03 很少點名 Tableau 或 Looker 等第三方 BI 工具，但確實會考架構整合方式。
連接模式
第三方 BI 工具透過 JDBC/ODBC 連接 Amazon Athena，透過 JDBC/ODBC 連接 Amazon Redshift，或直接從 Amazon S3 擷取資料。只要工具透過 Amazon Athena 或 Amazon Redshift Spectrum 查詢，三種模式都遵守 AWS Lake Formation 的 column-level 與 row-level 權限。從第三方工具直接以 s3:GetObject 存取，會繞過 AWS Lake Formation 治理。
何時選用 Amazon QuickSight
當你想要按工作階段計費、與 AWS Identity Center 緊密整合、SPICE 擴展性、SaaS 產品的嵌入式分析、Amazon Q in QuickSight 的自然語言問答，以及免維護基礎設施時，選用 Amazon QuickSight。當組織已有企業授權協議、需要複雜的精確像素分頁報表，或 Amazon QuickSight 不提供的進階客製化功能時，選用第三方工具。
必須記熟的關鍵數字（Athena 每 TB 定價、QuickSight SPICE 容量）
SAA-C03 經常測驗數字閾值而非文字描述。
- Amazon Athena 定價：多數區域每 TB 掃描 USD 5.00，每次查詢最低計費 10 MB，DDL 免費。
- Amazon Athena query result reuse 最長快取時間：7 天。
- Amazon Athena 資料使用量控制上限：設定於 workgroup 層級，可取消超過掃描閾值的查詢。
- Apache Parquet 建議檔案大小：128 MB 至 1 GB。
- AWS Lake Formation 權限範圍：資料庫、資料表、欄位、列、儲存格。
- AWS Lake Formation data filter：每個（資料表、主體）授權一個 filter。
- Amazon QuickSight Standard Edition vs Enterprise Edition：Enterprise 新增大規模 SPICE、row-level security、稽核、每小時刷新。
- Amazon QuickSight SPICE 預設使用者配額：Enterprise 使用者通常每人 10 GB，可額外購買 GB-month 容量。
- Amazon QuickSight 嵌入式分析：anonymous embedding 以工作階段計費（30 分鐘工作階段）。
- Amazon QuickSight ML Insights：僅在 Enterprise Edition 中提供。
- Amazon OpenSearch Service OCU：OpenSearch Serverless 中的索引 OCU 與搜尋 OCU 可獨立擴展。
考試前務必根據 AWS 文件核實最新數字——定價是最容易變動的細節。
常見考試陷阱 — Athena vs Redshift 互動查詢、Lake Formation vs Glue Catalog
SAA-C03 分析類題目使用一組重複出現的陷阱。
陷阱一 — 互動查詢中 Athena vs Redshift 的混淆
考生有時對任何 BI 儀表板題目都選 Amazon Redshift。這在資料已存放於 Amazon S3 且儀表板刷新頻率較低時是錯誤的——Amazon Athena 加上 Amazon QuickSight SPICE 更便宜也更簡單。Amazon Redshift 只在高並發、重複查詢的次秒級回應和精選資料集市占主導地位時才是優勝。
陷阱二 — Lake Formation vs AWS Glue Data Catalog 的混淆
AWS Glue Data Catalog 是元資料存放區。AWS Lake Formation 是其上的權限層。你不能沒有 AWS Glue Data Catalog 就使用 AWS Lake Formation，但可以在沒有 AWS Lake Formation 的情況下使用 AWS Glue Data Catalog（僅 IAM 型權限）。當題目詢問 column-level 或 row-level security 時，必須使用 AWS Lake Formation。
陷阱三 — Athena Federated Query vs 執行 ETL
如果情境說「對 Amazon DynamoDB 和 Amazon S3 執行一次性 SQL」，選 Amazon Athena Federated Query，而不是將 DynamoDB 複製到 Amazon S3 的 AWS Glue ETL 任務。Federated Query 避免了資料移動。
陷阱四 — QuickSight SPICE vs 即時查詢
如果情境說「數百名檢視者、資料每小時刷新且穩定」，將資料載入 SPICE。如果情境說「即時操作儀表板，每次刷新都必須看到最新毫秒的資料」，使用直接查詢（即時連線）存取來源。不要對所有情況都預設使用 SPICE。
陷阱五 — OpenSearch vs Athena 用於日誌搜尋
對於「在過去 15 分鐘內找出這個錯誤字串」，Amazon OpenSearch Service 是正確答案。對於「彙總過去 30 天的每小時錯誤率」，在 Amazon S3 日誌上使用 Amazon Athena 更便宜。許多情境會同時使用兩者——OpenSearch 用於熱搜尋，Athena 用於冷分析。
陷阱六 — EMR Serverless vs Athena
如果情境需要 Apache Spark 程式碼（PySpark、Scala、DataFrames），即使是 serverless 執行，答案也是 Amazon EMR Serverless。Amazon Athena 僅限 SQL。不要因為 Amazon Athena 是 serverless 就在程式碼優先的 ETL 場景選用它。
陷阱七 — Partition projection vs Glue crawlers
對於頻繁產生數百萬個分區的資料表，partition projection 在成本與資料新鮮度上都優於 AWS Glue crawlers。Crawlers 適合探索新資料表；projection 適合已知資料表上的高基數分區持續增長。
分析架構模式 — 擷取 → 儲存 → 建立目錄 → 查詢 → 視覺化
SAA-C03 的標準分析管線串聯了本主題的每一個服務。
- 擷取 — Amazon Kinesis Data Firehose（串流）、AWS DMS（資料庫 CDC）、AWS DataSync（檔案傳輸）或 AWS Transfer Family（SFTP）。Firehose 可即時轉換為 Parquet 並動態分區。
- 儲存 — Amazon S3 以 bronze/silver/gold 區域組織，並依日期分區。
- 建立目錄 — AWS Glue crawlers 或手動資料定義語言（DDL）填充 AWS Glue Data Catalog。
- 治理 — AWS Lake Formation 登錄 S3 位置、指派 LF-Tags，並授予欄位／列／儲存格層級的權限。
- 轉換 — AWS Glue ETL 或 Amazon EMR 將 bronze 轉換為 silver 再轉換為 gold，強制執行 schema 與資料品質。
- 查詢 — Amazon Athena 用於臨時 SQL，Amazon Redshift Spectrum 用於倉儲 join，Amazon EMR 用於 Spark 工作負載，Amazon OpenSearch Service 用於文字與日誌。
- 視覺化 — Amazon QuickSight 儀表板由 SPICE 驅動，搭配面向 SaaS 消費者的嵌入式分析，以及 Amazon Q in QuickSight 的自然語言問答。
請熟記此管線及服務順序。SAA-C03 分析類題目有很大一部分描述的正是這條管線的某個片段。
FAQ — Athena、Lake Formation 與 QuickSight 前六大常見問題
Q1. 在 SAA-C03 中，何時應選 Amazon Athena 而非 Amazon Redshift？
當資料已存放在 Amazon S3、查詢為臨時或不頻繁，且你希望以按掃描量計費的 serverless 方式避免閒置成本時，選 Amazon Athena。當你需要 PB 級倉儲、高並發次秒級儀表板、物化視圖、預存程序，或通往精選資料集市的傳統 ETL 管線時，選 Amazon Redshift。Amazon Redshift Serverless 是介於兩者之間的選項——你想要倉儲功能但不想調整叢集大小時的折衷方案。
Q2. AWS Lake Formation 與 AWS Glue Data Catalog 有何不同？
AWS Glue Data Catalog 是元資料層——資料庫、資料表與欄位 schema。AWS Lake Formation 是其上的治理層——LF-Tags、column-level 權限、row-level 權限與 data filters。AWS Lake Formation 沒有 AWS Glue Data Catalog 就無法運作，但如果不需要細粒度存取控制，也可以單獨使用 catalog 搭配純 IAM 權限。在 SAA-C03 中，細粒度存取永遠意味著 AWS Lake Formation。
Q3. LF-Tags 是什麼？何時使用它們而非明確授權？
LF-Tags 是資料庫、資料表或欄位上的鍵值標籤，讓你透過標籤表達式（屬性型存取控制）授予權限。當組織擁有許多資料表與許多主體時，使用 LF-Tags——標記一次比在每個資源上逐一授予明確權限更具擴展性。對於規模小或靜態的 schema，使用明確授權即可。
Q4. 如何在不讓 Amazon Athena 成本爆炸的情況下，讓 Amazon QuickSight 儀表板擴展至數千名檢視者？
將儀表板資料集匯入 SPICE，並以合理的頻率刷新（例如每小時）。檢視者查詢 SPICE 的速度等同記憶體速度，而非每次點擊都觸發 Amazon Athena，從而避免重複掃描費用。在刷新步驟本身結合 Amazon Athena query result reuse，並在不同檢視者需要看到不同列子集時啟用 Amazon QuickSight row-level security。
Q5. SAA-C03 中 Amazon Athena vs Amazon EMR vs Amazon Redshift vs Amazon OpenSearch Service 的快速判斷規則是什麼？
Amazon Athena 適用於 Amazon S3 上的 serverless SQL（臨時、不頻繁、成本效益高）。Amazon Redshift 適用於高並發資料倉儲（企業 BI、精選資料集市、次秒級儀表板）。Amazon EMR 適用於程式碼優先的大數據處理（Spark、Hadoop、自訂框架）。Amazon OpenSearch Service 適用於文字搜尋與日誌分析（可觀測性、全文搜尋、SIEM）。讀題時，找出主要動詞——「查詢」、「倉儲」、「用 Spark 轉換」或「搜尋日誌」——選擇對應的服務。
Q6. 如果使用者擁有直接的 s3:GetObject 權限，AWS Lake Formation 是否仍能保護資料？
不能。AWS Lake Formation 治理透過 Amazon Athena、Amazon Redshift Spectrum、搭配 runtime roles 的 Amazon EMR 或 AWS Glue 路由的查詢。擁有直接 s3:GetObject 與 s3:ListBucket 權限的主體可繞過 AWS Lake Formation。要使 AWS Lake Formation 成為唯一的存取路徑，必須收緊 S3 儲存貯體政策，拒絕除 AWS Lake Formation 資料存取角色以外的所有角色直接存取。這個深度防禦步驟是 SAA-C03 的常見考試陷阱。