大規模資料分析與串流架構

大規模資料分析是 AWS Certified Solutions Architect Professional（SAP-C02）考試最核心的架構主題。Associate 等級的考試把資料分析當成單一服務選擇題（Amazon Athena、還是 Amazon Redshift、還是 Amazon EMR），Professional 等級的考試則把大規模資料分析視為多帳號、多團隊、多區域的治理難題：一個擁有 500 名分析師的組織，如何在不違反 GDPR、不重複儲存、不讓每個團隊都擠過同一條中央 ETL 瓶頸的前提下，把精選資料集分享給二十個產品團隊？SAP-C02 每個關於大規模資料分析的情境，都會把三個關切層疊加在一起——實體平面（位元組存放在哪裡、如何流動）、邏輯平面（誰擁有哪個資料集、誰使用它），以及治理平面（誰可以看哪個欄位、哪列資料、哪個儲存格、在哪個法律依據下）。在 SAP-C02 中把大規模資料分析答對，一場考試通常能換來八到十二題的分數，這也是為什麼這是學習指南中篇幅最長的主題之一。

本學習指南涵蓋 SAP-C02 考試用來測試大規模資料分析的每個服務與模式：搭配 Apache Iceberg 及開放表格格式的 Amazon S3 銅、銀、金三層現代資料湖；AWS Glue Data Catalog 跨帳號聯邦以及 AWS Lake Formation LF-Tags 組織級列/欄安全；Amazon Kinesis Data Streams、Amazon Data Firehose、Amazon Managed Service for Apache Flink 與 Amazon MSK 的串流決策樹；Amazon Redshift RA3 加 Amazon Redshift Serverless 加 Amazon Redshift Spectrum 加聯邦查詢加並發擴展加物化視圖加 zero-ETL；Amazon DataZone 跨團隊治理門戶；透過 AWS Data Exchange、Amazon Redshift Data Sharing 與 AWS Resource Access Manager 進行的跨帳號資料共享；Amazon OpenSearch Service 用於可觀測性與搜尋；Amazon SageMaker Feature Store 與 lake house 整合；以及 AWS Glue Data Quality 加 Amazon Deequ 的大規模資料品質。本文以一個貫穿始終的情境——一個旗下有 20 支團隊、資料湖服務 500 名分析師、受 GDPR 約束的零售組織——串起所有知識點，讓你看清楚大規模資料分析在真實 SAP-C02 答案中的全貌。

大規模資料分析 — SAP-C02 心智模型

AWS 上的大規模資料分析不是單一服務；它是一個分層架構。SAP-C02 獎勵能指名每一層、並為該層選對服務的考生，而不是孤立地死背服務功能的考生。SAP-C02 考試的參考模型中有六個層次，每個情境都會對應其中一個或多個。

大規模資料分析的六個層次

第一層是擷取（ingestion）——把資料從操作型資料庫、應用程式、合作夥伴、SaaS 工具、IoT 裝置和點擊串流送進平台。這一層的 SAP-C02 服務包括 Amazon Kinesis Data Streams、Amazon Data Firehose、Amazon MSK、AWS Database Migration Service、AWS DataSync、AWS Transfer Family，以及從 Amazon Aurora 和 Amazon DynamoDB 到 Amazon Redshift 的 zero-ETL 整合。

第二層是儲存（storage）——實際的位元組。Amazon S3 是標準的資料湖底層；Amazon Redshift RA3 managed storage 是倉儲底層；Amazon OpenSearch Service storage 是搜尋底層。大規模資料分析在 SAP-C02 的關鍵洞察是：儲存與運算必須解耦，讓多個引擎可以讀取同一批位元組而不需複製。

第三層是目錄（catalog）——描述資料表、schema 和分區的詮釋資料層。AWS Glue Data Catalog 是預設選項；它向外聯邦到 Amazon EMR 上的 Hive Metastore、透過 Amazon Redshift Spectrum 外部 schema 聯邦到 Amazon Redshift，以及跨帳號的 Glue catalogs。大規模資料分析意味著一個跨越整個組織的目錄。

第四層是治理（governance）——權限、血緣、資料品質和稽核層。AWS Lake Formation 是 Amazon S3 支援的資料表之權限平面；Amazon DataZone 是面向業務的治理門戶；AWS Glue Data Quality 和 Amazon Deequ 是資料品質規則引擎；AWS CloudTrail 與 AWS Lake Formation 稽核日誌為合規收尾。

第五層是運算與查詢（compute and query）——讀取位元組並回傳答案的引擎。Amazon Athena 用於臨時無伺服器 SQL，Amazon Redshift Serverless 與 Amazon Redshift RA3 用於精選數據集市，Amazon EMR Serverless 用於 Apache Spark 工作負載，Amazon Managed Service for Apache Flink 用於串流分析，Amazon SageMaker 用於機器學習工作負載。大規模資料分析要求每個引擎都遵守同一套 Lake Formation 權限。

第六層是消費（consumption）——業務使用者實際互動的儀表板、筆記本、API 和嵌入式體驗。Amazon QuickSight 是原生 BI 工具；第三方 BI 工具透過 Amazon Athena 或 Amazon Redshift JDBC/ODBC 連線；Amazon DataZone 專案讓分析師獲得自助服務入口。

為什麼 SAP-C02 對大規模資料分析的要求高於 SAA-C03

SAA-C03 在大多數分析情境中會接受「Amazon Athena 加 AWS Lake Formation 加 Amazon QuickSight」的答案。當情境涉及二十支團隊、多帳號 AWS Organizations、PB 級儲存、次秒級並發、跨區域合規或主動-主動容錯時，SAP-C02 不會接受那個答案。Professional 等級的考試期待的是複合答案：跨帳號聯邦的 Lake Formation LF-Tags、用於精選數據集市的 Amazon Redshift RA3 加 Redshift Data Sharing、用於串流聚合的 Amazon Managed Service for Apache Flink、用於自助探索的 Amazon DataZone，以及附加在每張銀層資料表上的 AWS Glue Data Quality 規則。大規模資料分析在 SAP-C02 上永遠是多服務、多帳號的答案。

白話文解釋 Data Analytics at Scale on AWS

大規模資料分析的概念容易流於抽象，以下四個類比讓這套架構在 SAP-C02 備考中變得具體可記。

類比一：連鎖圖書館系統（圖書館聯盟）

單一圖書館很容易治理。一個橫跨二十個分館、服務五十萬讀者的全國圖書館系統，是完全不同層次的問題——這就是大規模資料分析的樣貌。

• 每個分館是一支團隊的 AWS 帳號，擁有自己的 Amazon S3 資料湖。
• 全國聯合書目是跨帳號聯邦的 AWS Glue Data Catalog——分館 A 的讀者可以坐在原位就查到放在分館 B 的書。
• 全國館務委員會是搭載 LF-Tags 的 AWS Lake Formation——他們制定規則，例如「所有標記 GDPR-EU 的書籍只能被持有 EU 居民識別碼的讀者借閱」，且每個分館都以相同方式執行。
• 自助查詢機是 Amazon DataZone——讀者輸入「季度營收」，查詢機列出每個有相符資料集的分館、擁有者是誰，以及如何申請存取。
• 館際互借服務台是 AWS Data Exchange 加 Amazon Redshift Data Sharing 加 AWS Resource Access Manager——當分館 A 想與分館 B（或合作夥伴）分享精選館藏時，這些服務移動的是許可，而不是書本。
• 閱覽室是查詢引擎——Amazon Athena 用於快速翻閱參考書，Amazon Redshift 用於深度研究，Amazon EMR 用於重新整理舊典籍。
• 善本珍藏室是存放冷封存資料的 Amazon S3 Glacier；時事展覽架是存放熱搜資料的 Amazon OpenSearch Service。

當 SAP-C02 情境描述二十支團隊、多個帳號、共享資料集和中央治理時，圖書館聯盟類比告訴你答案是：使用 Lake Formation 加 DataZone 加 Redshift Data Sharing 的大規模資料分析——而不是單一整合式資料倉儲。

類比二：現代廚房分工體系（廚房分工）

規模化餐廳廚房是由各個專責站點組成的分工體系，AWS 上的大規模資料分析運作方式如出一轍。

• 進貨碼頭是擷取層——Amazon Kinesis Data Streams、Amazon MSK 和 AWS DMS 接收原料（事件、CDC 串流、檔案）。
• 冷藏保鮮室是 Amazon S3 的銅層——所有東西原封不動地在這裡落地，就像蔬菜還在箱子裡。
• 前處理站是銀層——AWS Glue 作業或 Amazon EMR Serverless 清洗、去重並把食材重新封裝成 Apache Parquet 或 Apache Iceberg 表格。
• 擺盤站是金層——Amazon Redshift 物化視圖或 AWS Glue 作業組合出維度數據集市，外觀正好是客人（分析師）會看到的樣子。
• 出菜督導是 AWS Lake Formation——他們監看每道離開廚房的菜，確保受限食材不會出現在不該有它的餐盤上（列級、欄級和儲存格級安全）。
• 菜單是 Amazon DataZone——客人（分析師）只看得到他們被允許點的菜，並以業務語言描述。
• 主廚是資料治理委員會——他們決定哪些站點存在、哪些食譜是黃金標準，以及誰可以試菜。

每當 SAP-C02 情境詢問銅、銀、金三層、多團隊所有權和品質閘門時，廚房分工類比是正確的心智模型。大規模資料分析從來不是一個人包辦所有事；它是一套有明確交接點的分工體系。

類比三：工具箱（工具箱）

大規模資料分析的串流層讓許多考生感到困惑，因為 AWS 提供了太多功能重疊的服務。工具箱類比把每個服務固定到對應的使用情境。

• Amazon Kinesis Data Streams 是螺絲起子——低階、通用，讓你完全掌控 producer 和 consumer，保留期長達 365 天。當你需要自己寫 consumer 程式碼並需要毫秒級控制時，就拿起它。
• Amazon Data Firehose 是釘槍——高吞吐、單發、設定好目的地就開槍。當你的工作是「把這條串流落地到 Amazon S3（或 Amazon OpenSearch Service、或 Amazon Redshift、或 Splunk、或第三方 HTTP 端點）而不需要寫 consumer 程式碼」時，就拿起它。
• Amazon Managed Service for Apache Flink 是變速電動鑽——在 Apache Flink 中進行連續、有狀態、視窗化的運算。當你的工作是「在每秒百萬筆事件中為每個使用者計算一分鐘滾動平均值」時，就拿起它。
• Amazon MSK 是工業車床——完整的 Apache Kafka 語義、分區、consumer group、exactly-once 處理、分層儲存。當組織已深度投資 Apache Kafka 生態系並需要相容性時，就拿起它。
• Amazon Kinesis Data Analytics for Apache Flink Studio（現已整合入 Managed Service for Apache Flink）是台式砂輪機——用於串流 SQL 和 Python 的互動式筆記本。

工具箱類比回答了 SAP-C02 最常見的陷阱：「Amazon Kinesis Data Streams 還是 Amazon MSK？」正確的選擇是適合工作的工具，考試獎勵與情境語言相符的選擇。

類比四：保險單（保險）

大規模的資料品質與治理就像整個資料分析平台的保險單。

• AWS Glue Data Quality 規則是每月保費——你每天付出少量運算成本，在壞資料污染金層之前就發現它。
• Amazon Deequ 是自助居家驗屋——基於程式庫的規則框架，在 Amazon EMR 或 Amazon SageMaker 上執行，當你需要比 Glue Data Quality 開箱即用更豐富的規則時使用。
• AWS Lake Formation LF-Tags 是附加條款——一個 tag 表達式涵蓋一千張資料表，GDPR 分類變更一次就到處生效。
• Amazon DataZone 血緣（lineage）是理賠紀錄——儀表板出問題時，血緣追蹤顯示每一個上游跳躍點，讓你對症下藥（並修正正確的 bug）。

大規模資料分析若沒有資料品質與治理就等於沒有保險；第一個事故就會抹掉所有價值。SAP-C02 獎勵從第一天就把品質和治理接線進去的答案，而不是事後才補上的。

現代資料湖 — S3 銅、銀、金三層與 Apache Iceberg

資料湖是 AWS 大規模資料分析的儲存骨幹。SAP-C02 考試期望你熟知多層區域模式、開放表格格式選項和目錄聯邦設計。

組織級的銅、銀、金三層

在 SAA-C03，你學習了銅（原始）、銀（清洗後）、金（可消費）的單帳號模式。到了 SAP-C02 的規模，每個層次都進一步分區。銅層是每個來源系統的落地區，由擷取團隊所有，依監管政策保留。銀層是共享的精選層，由中央資料平台團隊所有，由 AWS Glue ETL 或 Amazon EMR Serverless 作業寫入，且這些作業也會執行 AWS Glue Data Quality 規則。金層是多所有者的——每個產品團隊在自己的 AWS 帳號中擁有自己的金層數據集市，並註冊到聯邦的 AWS Glue Data Catalog，讓其他團隊可以探索和查詢。

Apache Iceberg、Apache Hudi 與 Delta Lake — 開放表格格式

Amazon S3 上的原始 Apache Parquet 檔案不支援交易、schema 演化或時間回溯。開放表格格式透過在 Parquet 檔案上方加入詮釋資料層來解決這個問題。Apache Iceberg 是 AWS 上的一等公民——原生支援 Amazon Athena、Amazon Redshift、AWS Glue、Amazon EMR 和 AWS Lake Formation。Apache Hudi 和 Delta Lake 也受 Amazon EMR 和 AWS Glue 支援，但 Apache Iceberg 是 SAP-C02 遇到「我們需要資料湖上的 ACID 交易、列級更新與刪除、schema 演化和時間回溯」時的預設答案。

在大規模資料分析中，Apache Iceberg 之所以重要，是因為 GDPR「被遺忘權」請求需要列級刪除，而原始 Parquet 無法有效表達。Apache Iceberg 刪除檔案加上排程的 compaction 作業，把「忘掉這位客戶」轉化為一條 SQL 語句。

跨帳號的 Glue Data Catalog 聯邦

大規模資料分析幾乎都橫跨 AWS Organizations 中的多個 AWS 帳號。單一中央 Glue Data Catalog 可能成為瓶頸，因此 AWS 支援 Glue Data Catalog 聯邦：每個生產帳號保有自己的 Glue Data Catalog，消費帳號則註冊指向生產方的聯邦目錄。AWS Lake Formation 透過 AWS Resource Access Manager 仲介跨帳號授權。在 SAP-C02 的大規模資料分析中，聯邦是預設做法，永遠不應提議在帳號間手動複製目錄條目。

大規模資料分析的檔案排列選擇

依查詢最常篩選的欄位分區（通常是事件日期和租戶 ID）。檔案大小保持在 128 MB 到 1 GB 之間。銀層和金層的 Apache Parquet 使用 ZSTD 壓縮；銅層使用 Snappy，因為這個階段寫入吞吐量比壓縮率更重要。對 Apache Iceberg 資料表執行排程 compaction 以防小檔案碎片化。對擁有數百萬分區的 Amazon Athena 資料表啟用 partition projection，避免 AWS Glue crawler 執行時的額外開銷。這些選擇與 SAA-C03 相同，但在 SAP-C02 層級，它們必須在全部二十支團隊中一致地應用——這正是 AWS Glue Data Quality 和 Amazon DataZone 的用武之地。

組織級的 Lake Formation — LF-Tags、列/欄安全與跨帳號共享

AWS Lake Formation 是 AWS 大規模資料分析的治理主力。在 SAP-C02 的規模下，手動授權行不通；LF-Tags 不是可選項。

20 支團隊的 LF-Tag 本體

預先設計 LF-Tag 本體。標準組織使用四個維度：zone（銅、銀、金）、domain（finance、marketing、product、ops）、sensitivity（public、internal、confidential、restricted、pii）和 geography（us、eu、apac）。每個資料庫、資料表和敏感欄位都帶有完整的 tag 集合。授權以 tag 表達式表示——例如「EU 分析師群組對 geography=eu AND sensitivity IN (public, internal, confidential) AND zone IN (silver, gold) 擁有 SELECT 權限」。一次 tag 變更即可對數千張資料表重新授權。這就是大規模資料分析如何保持可治理性。

組織級的列級和欄級安全

AWS Lake Formation 資料篩選器把列篩選表達式與包含或排除的欄位清單結合在一起。在組織規模下，你為每個敏感性-地理-業務領域組合建立一個篩選器，並將其授予對應角色。EU-retail-analyst 角色獲得列篩選為 region = 'EU'、且排除 customer_pii_email 欄位的資料篩選器。US-retail-analyst 角色獲得列篩選為 region = 'US' 的對應篩選器。當 GDPR 範圍變更時，你只需編輯篩選器，而不必修改每一個查詢。Amazon Athena、Amazon Redshift Spectrum、AWS Glue 和 Amazon EMR 全都自動遵守該篩選器。

跨帳號 Lake Formation 共享

AWS Lake Formation 支援兩種跨帳號共享模式。在具名資源共享中，你把特定資料表授予特定帳號；AWS Lake Formation 使用 AWS Resource Access Manager 傳送共享，消費帳號接受它。在 LF-Tag 共享中，你把 tag 表達式授予一個帳號；任何之後獲得相符 tag 的資料表都會自動對消費方開放——這才是大規模資料分析可擴展的模式。消費帳號透過 Amazon Athena 或 Amazon Redshift Spectrum 以自己的 IAM 角色查詢；Lake Formation 提供具範圍限制的 S3 憑證。

Lake Formation 搭配 AWS Organizations 服務級授權

在 AWS Organizations 中，AWS Lake Formation 支援授權給整個組織、一個組織單位（OU），或特定帳號。授權給 OU 意味著該 OU 中新加入的帳號會自動繼承存取權。這是當 SAP-C02 情境說「新的產品團隊應能在無需手動上線流程的情況下取得對共享金層的存取權」時，考試所獎勵的模式。

GDPR 特定的 Lake Formation 模式

在大規模資料分析中，三個 Lake Formation 模式對 GDPR 合規最為關鍵。第一，使用 sensitivity=pii LF-Tags 標記每個 PII 欄位，並只向資料保護長角色授予存取權。第二，對 gdpr_consent = true 使用列級篩選器，讓查詢自動排除已撤回同意的紀錄。第三，使用 Apache Iceberg 列級刪除加上由「被遺忘權」請求觸發的 Apache Iceberg DELETE FROM 語句。AWS CloudTrail 加 AWS Lake Formation 稽核日誌可向稽核人員證明執行情況。

大規模串流分析 — Kinesis、Firehose、Managed Flink、MSK 決策樹

串流是 SAP-C02 大規模資料分析的第二根支柱。考試測試 Amazon Kinesis Data Streams、Amazon Data Firehose、Amazon Managed Service for Apache Flink 和 Amazon MSK 之間的決策樹。

Amazon Kinesis Data Streams — 通用串流

Amazon Kinesis Data Streams 是 AWS 的基礎串流服務。它把資料分割為 shard（佈建模式），或自動擴展 shard（隨需模式）。保留期可設定從 24 小時到 365 天。Kinesis Data Streams 的正確使用情境是：需要多個獨立 consumer 以不同速度讀取同一條串流、需要長達一年的重播、需要毫秒延遲並完全掌控 consumer 程式碼，以及已有 AWS Lambda、AWS Glue 串流或 Amazon Kinesis Client Library 應用程式從串流讀取資料。

Amazon Data Firehose — 零程式碼交付

Amazon Data Firehose（前身 Amazon Kinesis Data Firehose）是無程式碼的串流交付服務。它依大小或時間緩衝，可選擇性地以 AWS Lambda 轉換，可選擇性地轉換為 Apache Parquet 或 Apache ORC，並寫入 Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、Snowflake 或通用 HTTP 端點。Firehose 的正確使用情境是：目的地是其中一個支援的 sink、能接受 60 秒以上的延遲，以及不想管理 consumer。在大規模資料分析中，Firehose 是 Amazon S3 銅層擷取的預設選項。

Amazon Managed Service for Apache Flink — 有狀態串流運算

Amazon Managed Service for Apache Flink（前身 Amazon Kinesis Data Analytics）執行 Apache Flink 應用程式，用於有狀態、視窗化、exactly-once 的串流運算。正確使用情境是：需要計算每個使用者的 session 聚合值、滑動視窗指標、串流對串流 join 或複雜事件處理。Managed Flink 從 Amazon Kinesis Data Streams、Amazon MSK 或 Amazon MSK Serverless 讀取，並寫入 Apache Flink 支援的任何 sink。在大規模資料分析中，Managed Flink 是串流聚合資料近即時落地至金層資料表的所在地。

Amazon MSK — Apache Kafka 相容性

Amazon Managed Streaming for Apache Kafka（Amazon MSK）執行具有完整協定相容性的真實 Apache Kafka。Amazon MSK 的正確使用情境是：組織已使用 Apache Kafka、需要具有 exactly-once 語義的 consumer group、需要更豐富的 Apache Kafka 生態系（Apache Kafka Connect、Apache Kafka Streams、Confluent Schema Registry 相容工具），或需要長保留串流的分層儲存。Amazon MSK Serverless 是適用於可變吞吐量的自動擴展選項。

大規模資料分析的串流決策樹

從頂端開始。目的地是 S3、Redshift、OpenSearch、Splunk、Snowflake 或 HTTP 其中之一，且沒有自訂 consumer 邏輯？使用 Amazon Data Firehose。運算是有狀態的視窗聚合或串流 join？使用從 Kinesis Data Streams 或 Amazon MSK 讀取的 Amazon Managed Service for Apache Flink。組織已標準化在 Apache Kafka 協定和工具上？使用 Amazon MSK。否則，使用搭配 AWS Lambda 或 AWS Glue 串流 consumer 的 Amazon Kinesis Data Streams。這個四分支決策樹幾乎可以回答每道關於大規模資料分析串流的 SAP-C02 題目。

大規模 Redshift — RA3、Serverless、Spectrum、Federated Query、Zero-ETL

Amazon Redshift 是大規模資料分析的資料倉儲支柱。SAP-C02 測試六項在 SAA-C03 中不會出現的 Redshift 功能。

Amazon Redshift RA3 Managed Storage

RA3 節點類型（ra3.xlplus、ra3.4xlarge、ra3.16xlarge）將運算與儲存解耦。資料存放在 Redshift Managed Storage（RMS）中，底層由 Amazon S3 支撐，運算節點在本機 SSD 上快取熱工作集。你可以獨立擴展運算和儲存；可以暫停和恢復；可以在尖峰時段執行並發擴展叢集以增加容量。RA3 是任何佈建式 Redshift 答案的 SAP-C02 預設選項——DS2 和 DC2 是舊世代。

Amazon Redshift Serverless

Amazon Redshift Serverless 完全省去叢集調整的步驟。你指定基礎 Redshift Processing Unit（RPU）容量；Serverless 在負載時自動向上擴展，閒置時自動暫停。計費依 RPU-秒計算。在大規模資料分析的 SAP-C02 場景中，Redshift Serverless 是工作負載不可預測（開發/測試、臨時分析、不頻繁但密集的作業）或想要省去叢集管理複雜度時的正確選擇。RA3 佈建式仍是全天候 24x7 穩定生產工作負載的正確選擇，因為 Reserved Instance 定價和可預測的容量更為重要。

Amazon Redshift Spectrum — 就地讀取資料湖

Amazon Redshift Spectrum 讓 Redshift 叢集透過在 AWS Glue Data Catalog 中註冊的外部 schema（並由 AWS Lake Formation 強制執行）直接查詢 Amazon S3 上的資料。這就是 Redshift session 如何在不載入資料的情況下，把倉儲事實資料表與資料湖銀層 Apache Iceberg 資料表 join 在一起。在大規模資料分析中，Spectrum 是讓金層倉儲保持精簡、同時仍能回答需要原始湖資料的問題的橋梁。

Amazon Redshift Federated Query

Amazon Redshift Federated Query 讓 Redshift 直接對 Amazon RDS for PostgreSQL、Amazon Aurora PostgreSQL、Amazon RDS for MySQL 和 Amazon Aurora MySQL 執行 SQL。這與讀取 Amazon S3 的 Amazon Redshift Spectrum 不同。Federated Query 是 SAP-C02 回答「在不執行 ETL 的情況下，執行把倉儲資料表與操作型資料庫資料表 join 在一起的原生 Redshift SQL」的答案。在大規模資料分析中，federated query 常被 zero-ETL 整合取代。

Amazon Redshift Concurrency Scaling

Redshift Concurrency Scaling 在主叢集的並發查詢槽耗盡時新增暫時性運算叢集，只計費那些暫時性叢集運行的秒數。每個 Redshift 叢集每 24 小時正常運作可獲得一小時免費的 concurrency scaling，足以應付大多數工作負載。在大規模資料分析中，啟用 concurrency scaling 是應對 500 名分析師尖峰而不過度調整基礎叢集大小的最划算方法。

Amazon Redshift Materialized Views

物化視圖預先計算並儲存查詢結果。自動更新在底層資料變更時重新執行視圖；增量更新只更新受影響的列。在大規模資料分析中，針對 Redshift 的金層儀表板幾乎都應該建立在物化視圖之上——查詢達到次秒級，Amazon QuickSight 對數百位並發使用者保持響應，而底層事實資料表只在更新期間被讀取。

Zero-ETL 整合

Zero-ETL 整合把來自 Amazon Aurora MySQL、Amazon Aurora PostgreSQL、Amazon RDS for MySQL 和 Amazon DynamoDB 的資料近即時複製到 Amazon Redshift，無需任何黏合程式碼，也無需 ETL pipeline。來源資料表在寫入後數秒內就像原生 Redshift 資料表一樣出現在 Redshift 中。在大規模資料分析的 SAP-C02 情境中，zero-ETL 是每當情境說「我們希望操作型資料能在數秒內用於分析，而不需要建立和維運 ETL pipeline」時的答案。

跨帳號資料共享 — Redshift Data Sharing、AWS Data Exchange、AWS RAM

大規模資料分析幾乎都需要跨 AWS 帳號共享即時資料集——在產品團隊之間、在子公司之間，以及與外部合作夥伴之間。SAP-C02 測試各共享服務之間的差異。

Amazon Redshift Data Sharing

Amazon Redshift Data Sharing 讓生產方 Redshift 叢集無需複製資料，就能與一個或多個消費方 Redshift 叢集共享即時資料表、視圖和 schema。消費方以自己的憑證查詢，支付自己的運算費用，且永遠看到最新資料。支援 RA3 佈建式和 Redshift Serverless。這是 SAP-C02 回答「財務團隊的倉儲必須跨帳號查詢行銷團隊倉儲的即時資料，而不需要夜間摘錄」的答案。

AWS Data Exchange

AWS Data Exchange 是第三方資料集的市集，包括 Amazon S3 資料集、Amazon Redshift 資料集和 Amazon API Gateway API。資料提供者發布；訂閱者收到授權，並可透過原生服務查詢（Amazon S3 資料集用 Amazon Athena、Redshift 資料集用 Amazon Redshift Data Sharing）。在大規模資料分析中，AWS Data Exchange 是「在不建立自訂擷取 pipeline 的情況下，把第三方金融資料納入我們的資料湖」的正確答案。

AWS Resource Access Manager（AWS RAM）

AWS Resource Access Manager（AWS RAM）是通用的跨帳號資源共享服務，AWS Lake Formation 在底層使用它。在大規模資料分析中，你很少直接呼叫 AWS RAM——Lake Formation 已將其抽象化——但當 SAP-C02 考試描述 S3 存取授權層時，可能會直接點名 AWS RAM。

Amazon S3 跨帳號存取模式

除了 Lake Formation 之外，Amazon S3 還支援三種 SAP-C02 考試期望你熟知的跨帳號存取模式。第一，S3 儲存桶政策授予其他帳號 s3:GetObject 或 s3:ListBucket。第二，每帳號的 S3 Access Points 簡化大型權限集合。第三，S3 Access Grants（較新）將 IAM 身分對映到特定 S3 前綴，無需編輯儲存桶政策。在大規模資料分析中，所有目錄感知的內容優先使用 Lake Formation；只對非表格化的大量資料（圖像、影片、原始日誌）使用 S3 存取模式。

Amazon DataZone — 大規模自助治理門戶

Amazon DataZone 是大規模資料分析面向業務的治理門戶。它架設在 AWS Lake Formation 和 AWS Glue Data Catalog 之上，提供 SAA-C03 不測試的自助服務體驗。

Amazon DataZone 提供什麼

Amazon DataZone 提供業務詞彙表（把技術欄位名稱對映至業務術語）、資料產品目錄（發布附有 SLA 和所有權的精選資料集）、存取申請工作流程（分析師申請存取，資料所有者核准，Lake Formation 授權自動生效）、血緣追蹤（上游到下游的追溯），以及環境範本（每個 DataZone 專案獲得預設好的 Amazon Athena 工作群組、Amazon Redshift 存取和 AWS Glue 資料庫）。在大規模資料分析中，Amazon DataZone 是把原始 Lake Formation 轉化為 500 名分析師真正想用的產品的關鍵。

DataZone 的網域與專案模型

DataZone **網域（domain）**是頂層租戶——通常每個組織一個。在網域內，專案（project）是協作單位——每個產品團隊有一個專案。專案發布帶有詮釋資料、所有權和 SLA 的資料資產（data asset）（資料表、儀表板、機器學習模型）。其他專案透過存取申請工作流程訂閱資料資產。在大規模資料分析中，網域-專案-資產是考試使用的心智模型。

什麼時候 Amazon DataZone 是正確答案

當情境描述自助資料探索、業務友善的詮釋資料、跨團隊存取申請工作流程、跨 Glue 作業和 Redshift 載入的血緣視覺化，或每個團隊的標準化分析環境佈建時，選擇 Amazon DataZone。如果情境說「分析師找不到正確的資料集」或「每次存取申請都需要兩週，因為要開工單、做 Lake Formation 授權、做 Redshift 授權、改 Athena 工作群組」，答案就是 Amazon DataZone。

大規模 OpenSearch — 可觀測性、搜尋與 Serverless

Amazon OpenSearch Service 為大規模資料分析補全了文字密集型和時間序列可觀測性工作負載的拼圖。

OpenSearch Service 佈建叢集

Amazon OpenSearch Service 佈建叢集在依節點數量和執行個體類型調整大小的索引上，提供全文搜尋、聚合和 OpenSearch Dashboards。在大規模資料分析中，OpenSearch Service 處理日誌分析（Amazon Data Firehose -> OpenSearch）、產品目錄搜尋（應用程式驅動的索引寫入）和 SIEM（Amazon OpenSearch Service Security Analytics 外掛）。

Amazon OpenSearch Serverless

Amazon OpenSearch Serverless 在索引 OpenSearch Compute Units（OCU）和搜尋 OCU 上獨立自動擴展。你定義一個集合（時間序列、搜尋或向量搜尋），OpenSearch Serverless 負責容量管理。在大規模資料分析中，OpenSearch Serverless 是流量可變時的正確選擇——例如，有流量尖峰的面向客戶產品搜尋，或間歇性的 SIEM 調查工作負載。

組織級可觀測性的 OpenSearch

在 20 支團隊和 500 名分析師的規模下，集中式可觀測性本身就成為大規模資料分析的問題。模式：AWS CloudWatch Logs Subscription Filters 把日誌輸送到 Amazon Data Firehose；Firehose 同時寫入 Amazon S3（冷封存和長期 Athena 查詢）和 Amazon OpenSearch Service（最近 30 天的熱搜）。這個分層模式在控制 OpenSearch 叢集大小——以及成本——的同時，保留了透過 Amazon Athena 查詢任何時間點資料的能力。

用於檢索增強生成的 OpenSearch 向量搜尋

Amazon OpenSearch Serverless 支援向量搜尋集合，SAP-C02 考試已開始在機器學習情境中測試它。一個在產品目錄上建立 RAG 的零售組織，以 Amazon Bedrock 嵌入產品描述，把嵌入向量存放在 OpenSearch Serverless 向量集合中，並從生成式應用程式執行語義搜尋。在大規模資料分析中，這是分析平面與機器學習平面相交的地方。

SageMaker Feature Store 與 Lake House 整合

大規模機器學習與大規模資料分析緊密耦合，因為兩個引擎都需要相同的精選特徵。

Amazon SageMaker Feature Store

Amazon SageMaker Feature Store 是受管的特徵儲存庫。它有兩個 store：線上 store（用於即時推論的低延遲鍵值查詢，以類 DynamoDB 引擎為後端）和離線 store（以 Amazon S3 為後端，採 Apache Iceberg 或 Apache Parquet 格式，在 AWS Glue Data Catalog 中註冊，可由 Amazon Athena、Amazon Redshift Spectrum 和 Amazon EMR 查詢）。在大規模資料分析中，離線 store 就是一張資料湖資料表——ML 團隊建立的任何特徵都自動對分析師開放，並受相同的 AWS Lake Formation 政策治理。

Lake House 模式

Lake house 把資料湖（Amazon S3 加 Apache Iceberg 加 AWS Glue Data Catalog）與資料倉儲（Amazon Redshift RA3 加 Redshift Managed Storage）統一在一起。查詢在合理的地方執行——Amazon Redshift 用於精選數據集市的次秒級儀表板查詢，Amazon Athena 用於資料湖資料表的臨時探索，Amazon EMR Serverless 用於 Apache Spark 工作負載——但它們全部遵守相同的 AWS Lake Formation 權限並讀取相同的 Apache Iceberg 資料表。這是 SAP-C02 的標準「lake house」答案，SageMaker Feature Store 自然地嵌入其中。

大規模資料品質 — Glue Data Quality 與 Amazon Deequ

沒有資料品質執行機制的大規模資料分析是技術負債。SAP-C02 測試兩個特定工具。

AWS Glue Data Quality

AWS Glue Data Quality 讓你在資料表上宣告 Data Quality Definition Language（DQDL）規則——例如「欄位 order_id 必須唯一」、「欄位 email 必須符合正規表達式」、「欄位 revenue 必須非負」。規則可按需執行、按排程執行，或在 AWS Glue ETL 作業內執行。結果被記錄為資料品質分數，可以阻擋下游作業或發布到 Amazon EventBridge。在大規模資料分析中，AWS Glue Data Quality 是預設選項，因為它與 AWS Glue Data Catalog 和 AWS Lake Formation 開箱即用地整合。

Amazon Deequ

Amazon Deequ 是由 AWS 開發的開源程式庫，用於在 Apache Spark DataFrames 上執行單元測試風格的資料品質檢查。Deequ 在 Amazon EMR、Amazon EMR Serverless 和 AWS Glue 的 Apache Spark 執行階段上運行。它支援異常偵測、欄位分析和約束驗證。在大規模資料分析中，當規則過於複雜以致 DQDL 難以表達，或組織已有 Spark 資料平台時，Deequ 是正確選擇。

Pipeline 中的品質閘門

在每次銀層寫入時接入 AWS Glue Data Quality 規則——規則失敗時把該批次標記為壞資料並隔離。在每次金層物化時接入第二層規則——規則失敗時阻擋物化視圖更新並通知負責團隊。在大規模資料分析中，雙層品質閘門防止壞資料到達 500 名分析師的儀表板。

零售情境 — 20 支團隊、500 名分析師、GDPR、端到端設計

整合所有內容，以下是 SAP-C02 零售情境的參考設計：一個擁有 20 支產品團隊、資料湖服務 500 名分析師，且負有 GDPR 義務的零售組織。

帳號結構

使用 AWS Organizations，以 OU 劃分生產者（每個團隊的擷取和銀層所有權）、消費者（每個團隊的金層數據集市和分析師存取）、中央治理（Lake Formation 管理員帳號）和資料平台（共享服務：Amazon DataZone 網域、AWS Glue Data Catalog 中樞、Amazon Redshift 資料共享生產者）。每個團隊有一個生產者帳號和一個消費者帳號。

擷取設計

操作型 Amazon Aurora PostgreSQL 資料庫透過 zero-ETL 整合複製到 Amazon Redshift。點擊串流事件從店面流經 Amazon Kinesis Data Streams，再到 Amazon Managed Service for Apache Flink（用於即時 session 聚合）和 Amazon Data Firehose（用於以 Apache Parquet 格式原始事件封存到 Amazon S3 銅層）。合作夥伴資料透過 AWS Data Exchange 匯入。

儲存設計

每個生產者帳號的銅層——原始事件和原始 CDC，依監管規定保留。共享資料平台帳號的銀層——清洗後的 Apache Iceberg 資料表，依事件日期和租戶分區，由 AWS Glue ETL 作業加上 AWS Glue Data Quality 規則寫入。每個消費者帳號的金層——由各團隊擁有的數據集市，同樣使用 Apache Iceberg，透過 AWS Glue Data Catalog 聯邦公開。

治理設計

中央治理帳號中的 AWS Lake Formation 持有 LF-Tag 本體——zone、domain、sensitivity、geography。PII 欄位依適用情況標記 sensitivity=pii 和 geography=eu 或 geography=us。資料篩選器強制執行每國列限制。跨帳號授權在 OU 層級使用 LF-Tag 共享——零售 OU 中的每個消費者帳號會自動以已清除的敏感度等級看到標記 domain=retail 的銀層資料表。Amazon DataZone 提供 500 名分析師的自助服務入口。

查詢與消費設計

每個消費者帳號的 Amazon Redshift Serverless 用於互動式分析和金層數據集市，並從中央財務倉儲使用 Redshift Data Sharing，讓每個團隊都能看到即時的企業財務數據。每個消費者帳號的 Amazon Athena 用於對銀層和金層 Apache Iceberg 資料表執行臨時 SQL。每個團隊的 Amazon QuickSight 搭配 SPICE 用於儀表板，並嵌入店長的內部工具。Amazon OpenSearch Serverless 用於門市級操作搜尋和可觀測性。

GDPR 合規設計

「被遺忘權」請求觸發跨每張包含客戶 ID 的資料表的 Apache Iceberg DELETE FROM，由 AWS CloudTrail 和 AWS Lake Formation 稽核日誌核實。對 gdpr_consent = true 的列級篩選器在每個分析師查詢中自動排除未同意的紀錄。跨境資料傳輸控制由 geography LF-Tags 強制執行——美國籍分析師根本無法被授予包含 geography=eu AND sensitivity=pii 的 tag 表達式。

資料品質與機器學習設計

AWS Glue Data Quality 規則在每次銅層到銀層的轉換中執行完整性、唯一性和新鮮度檢查。Amazon EMR Serverless 上的 Amazon Deequ 每晚對完整銀層執行統計分析。Amazon SageMaker Feature Store 離線 store 是銀層中的 Apache Iceberg 資料表；線上 store 為店面的即時推薦推論提供服務。

這個組合設計是 SAP-C02 大規模資料分析的標準答案。考試呈現的每個變體都是這條 pipeline 的其中一個切片。

SAP-C02 大規模資料分析的常見陷阱

陷阱一：單帳號分析思維

從 SAA-C03 移入的考生會為 20 支團隊的組織提議單一 Amazon Athena 工作群組和單一 Lake Formation 管理員。SAP-C02 期望搭配 Lake Formation LF-Tag 跨帳號共享的多帳號 AWS Organizations 設計。在大規模資料分析中，單帳號答案是錯誤的。

陷阱二：用具名共享取代標籤型共享

隨著組織規模增長，具名 Lake Formation 共享變得難以管理。SAP-C02 獎勵 LF-Tag 共享。如果情境暗示「數十張資料表」或「每週新增資料表」，就選擇標籤型共享。

陷阱三：在 Zero-ETL 存在時使用 Redshift Federated Query

Redshift Federated Query 較舊，需要你寫跨資料庫 join。Zero-ETL 整合會自動近即時複製來源資料以供分析使用。當情境提到 Aurora MySQL 或 Aurora PostgreSQL 時，zero-ETL 通常是更好的答案。

陷阱四：Kinesis Data Streams 對 Amazon MSK

Amazon MSK 不因為是 Apache Kafka 就永遠更好。如果情境沒有提到 Apache Kafka、Apache Kafka Connect 或 consumer group，Kinesis Data Streams 更簡單也更便宜。SAP-C02 考試刻意植入這些關鍵字。

陷阱五：GDPR 場景使用原始 Parquet 而非 Apache Iceberg

「被遺忘權」需要列級刪除。Amazon S3 上的原始 Apache Parquet 無法有效表達列級刪除。Apache Iceberg 可以。每當情境提到 GDPR、被遺忘權或列級合規刪除時，Apache Iceberg 就是答案的一部分。

陷阱六：Amazon DataZone 對 AWS Lake Formation

DataZone 是使用者體驗層；Lake Formation 是強制執行層。當問題問的是欄級強制執行時選 DataZone 是錯的；當問題問的是分析師自助探索時選 Lake Formation 也是錯的。仔細閱讀痛點所在。

陷阱七：OpenSearch 用於長期分析

Amazon OpenSearch Service 針對全文搜尋和近期時間範圍的分析最佳化。不要提議把 OpenSearch 當作五年歷史分析的主要儲存——那個用途請使用 Amazon S3 加 Amazon Athena；OpenSearch 只用於熱窗口。SAP-C02 測試分層模式。

陷阱八：QuickSight SPICE 用於即時操作儀表板

SPICE 是依排程更新的快取。如果情境要求在持續更新資料上達到次秒級延遲（例如店長查看當前小時銷售額的即時視圖），應使用直接查詢搭配物化視圖的 Amazon Redshift，而不是 SPICE。

大規模資料分析必背數字

• Amazon Kinesis Data Streams 保留期：24 小時到 365 天（延長保留期另行計費）。
• Amazon Kinesis Data Streams 隨需模式：每條串流最多 200 MB/s 或每秒 200,000 筆記錄，自動擴展。
• Amazon Data Firehose 緩衝設定：Amazon S3 目的地為 1 MB 到 128 MB，以及 60 到 900 秒。
• Amazon MSK 分層儲存：主層加上無限低成本分層；讀取超過主層保留期的資料會透明地從分層取得。
• Amazon Redshift RA3 managed storage：與運算解耦；依每 GB-月計費。
• Amazon Redshift Concurrency Scaling：主叢集每 24 小時使用可獲得一小時免費。
• Amazon Redshift Data Sharing：即時存取，零複製，跨帳號和跨區域（適用於 RA3 和 Serverless）。
• Amazon Redshift zero-ETL 來源：Amazon Aurora MySQL、Amazon Aurora PostgreSQL、Amazon RDS for MySQL、Amazon DynamoDB（請核實目前清單）。
• AWS Lake Formation LF-Tags：每個目錄最多 50 個 tag 鍵，每個鍵最多 1,000 個值（請核實目前配額）。
• Amazon DataZone 網域：通常每個組織一個；專案嵌套在內。
• Apache Iceberg 時間回溯：可依時間戳記或快照 ID 查詢任何過去的快照。
• Amazon OpenSearch Serverless：獨立的索引 OCU 和搜尋 OCU；向量集合用於 RAG。
• AWS Glue Data Quality：DQDL 規則，每次執行產生資料品質分數，與 Amazon EventBridge 整合。

考試前請務必核實 AWS 目前文件中的配額與限制——大規模資料分析服務演進迅速。

FAQ — SAP-C02 大規模資料分析熱門問題

Q1. 什麼時候應該選 Apache Iceberg 而非純 Apache Parquet？

每當資料湖需要 ACID 交易、列級更新或刪除（例如 GDPR 被遺忘權）、不重寫歷史的 schema 演化，或基於快照的時間回溯時，選擇 Apache Iceberg。只在只有附加、不可變的資料集（例如原始銅層事件日誌）時，才選純 Apache Parquet。在 SAP-C02 中，任何提到 GDPR、監管刪除、schema 變更或時間點重現的情境，都指向 Apache Iceberg。AWS 上的大規模資料分析愈來愈以 Apache Iceberg 為預設，因為 Amazon Athena、Amazon Redshift、AWS Glue、Amazon EMR 和 AWS Lake Formation 都原生支援它。

Q2. Amazon Kinesis Data Streams、Amazon MSK 還是 Amazon Data Firehose — SAP-C02 獎勵哪一個？

三者可能同時出現在同一個情境中。目的地是支援的 sink（Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、Snowflake、HTTP）且能接受分鐘級延遲和零 consumer 程式碼時，Amazon Data Firehose 是正確選擇。需要多個獨立 consumer、毫秒延遲、自訂 consumer 邏輯或長達 365 天重播時，Amazon Kinesis Data Streams 是正確選擇。組織以 Apache Kafka 協定和生態系為標準（Apache Kafka Connect、consumer group、Schema Registry）時，Amazon MSK 是正確選擇。需要有狀態串流運算（視窗聚合、join）時，在你選擇的 Kinesis Data Streams 或 MSK 之上疊加 Amazon Managed Service for Apache Flink。大規模資料分析通常在同一條 pipeline 的不同部分同時使用三者。

Q3. AWS Lake Formation 如何把治理擴展到 20 支團隊、500 名分析師的組織？

透過 LF-Tags 加上跨帳號 LF-Tag 共享加上 Amazon DataZone。預先設計四維度的 LF-Tag 本體（zone、domain、sensitivity、geography）。透過慣例在 AWS Glue ETL 期間自動套用 tag。把 tag 表達式授予 principal 和 OU——永遠不要授予明確的資料表名稱。透過 AWS Lake Formation 跨帳號 LF-Tag 共享（底層使用 AWS Resource Access Manager）跨帳號分享 tag。在頂層疊加 Amazon DataZone 以提供面向業務的探索和存取申請工作流程。這個設計可以擴展，因為新增一張資料表是 tag 指派問題，而不是授權撰寫問題；新增消費者是 OU 上線問題，而不是逐資料表的問題。

Q4. Amazon Redshift RA3、Redshift Serverless 還是 Redshift Spectrum — 如何選擇？

它們是互補的，而非競爭。穩定全天候 24x7 生產倉儲受益於 Reserved Instance 定價和可預測容量時，選擇 Amazon Redshift RA3 佈建式。工作負載不可預測或間歇性時——開發/測試環境、臨時分析、具有突發查詢模式的每個團隊數據集市、不需要叢集管理的簡便性勝過小額運算溢價的工作負載——選擇 Amazon Redshift Serverless。從 RA3 或 Serverless 使用 Amazon Redshift Spectrum 在 Amazon S3 資料湖資料表上就地查詢——它不是 RA3 或 Serverless 的替代品，而是兩者的功能。大規模資料分析通常組合使用三者：中央財務倉儲使用 RA3、每個團隊使用 Serverless、Spectrum 用於把倉儲事實資料表與資料湖銀層資料表 join 在一起。

Q5. 如何在 AWS 上的大規模資料分析中處理 GDPR 合規？

四個機制共同運作。第一，用 sensitivity=pii LF-Tags 標記每個 PII 欄位，並透過 tag 表達式限制存取——永遠不要把 PII 存取授予一般分析師角色。第二，對 gdpr_consent = true 使用 AWS Lake Formation 列級資料篩選器，讓撤回同意的紀錄自動從每個查詢中消失。第三，以 Apache Iceberg 儲存資料表，讓「被遺忘權」請求轉化為具有列級刪除的 DELETE FROM SQL 語句，並排程 Iceberg compaction 以物理移除已刪除的列。第四，在每個帳號啟用 AWS CloudTrail 和 AWS Lake Formation 稽核日誌以向稽核人員證明執行情況，並使用 Amazon DataZone 血緣追蹤顯示 PII 的流向。GDPR 約束下的大規模資料分析需要全部四個機制——缺少任何一個就是合規缺口。

Q6. Amazon DataZone 在 AWS Lake Formation 已提供的基礎上何時能增加價值？

當痛點是探索、工作流程或業務詮釋資料，而非強制執行時。Lake Formation 回答「這個 principal 是否被允許讀取這個欄位？」——它不回答「我們資料湖中哪 3,000 張資料表中有哪張包含按門市劃分的季度營收？」或「我向誰申請行銷歸因資料集的存取權？」或「這個儀表板怎麼追溯回來源系統？」。Amazon DataZone 透過業務詞彙表、資料產品目錄、存取申請工作流程和血緣視覺化來回答這些問題。在擁有數百名分析師的大規模資料分析中，純 Lake Formation 部署在技術上正確，但在實踐中沒有 DataZone 風格的入口覆蓋其上就無法使用。

Q7. 操作型資料分析應使用 Zero-ETL 整合還是 Amazon Redshift Federated Query？

Zero-ETL 是針對來自 Amazon Aurora MySQL、Aurora PostgreSQL、Amazon RDS for MySQL 和 Amazon DynamoDB 的操作型資料進行近即時分析的首選。複製自動在數秒內發生，來源資料表作為原生 Redshift 資料表出現，且無需維運任何 ETL pipeline。Amazon Redshift Federated Query 適用於互動式 SQL 查詢較小的操作型資料表，且查詢時的新鮮度比持續吞吐量更重要，以及 zero-ETL 尚未支援該來源引擎的情況。在 SAP-C02 中，如果情境指名受支援的 zero-ETL 來源並說「無需 ETL 的近即時分析」，zero-ETL 是答案。如果情境指名 RDS 上的 PostgreSQL 或 MySQL 且有互動查詢的跨資料庫 join 需求，Federated Query 更適合。

Q8. 在 500 名分析師的大規模資料分析中，如何讓 Amazon Athena 成本可預測？

五個槓桿。第一，為每個團隊執行 Amazon Athena 工作群組，設定每個查詢和每個工作群組的掃描限制，讓失控的查詢無法掃描整個資料湖。第二，把所有銀層和金層資料表以 Apache Iceberg（或至少以 Snappy 或 ZSTD 壓縮的 Apache Parquet）儲存，並依最常用的 WHERE 述詞分區。第三，在工作群組層級啟用 Amazon Athena 查詢結果重用，讓重複的儀表板查詢以零掃描成本傳回快取結果。第四，把頻繁的次秒級儀表板從 Amazon Athena 移至 Amazon Redshift 物化視圖或 Amazon QuickSight SPICE。第五，使用 AWS CloudTrail 加 Amazon Athena 工作群組的 CloudWatch 指標，每週識別成本最高的十個查詢並改寫它們。在大規模資料分析中，成本控制永遠是政策加資料佈局加快取的組合——而不是任何單一技巧。

摘要 — SAP-C02 大規模資料分析

AWS 上的大規模資料分析是分層架構問題，而不是服務選擇問題。SAP-C02 考試期待跨越擷取（Amazon Kinesis、Amazon MSK、zero-ETL）、儲存（Amazon S3 加 Apache Iceberg 加 Amazon Redshift RA3 managed storage）、目錄（AWS Glue Data Catalog 聯邦）、治理（AWS Lake Formation LF-Tags 加跨帳號共享，以及 Amazon DataZone 用於探索）、運算（Amazon Athena、Amazon Redshift Serverless、Amazon EMR Serverless、Amazon Managed Service for Apache Flink）和消費（Amazon QuickSight 加嵌入式分析加 SageMaker Feature Store）的複合答案。一個擁有 20 支團隊、500 名分析師、受 GDPR 約束的零售組織，正好覆蓋到這六個層次的每一個，這也是 SAP-C02 考試為何如此依賴這個情境的原因。把六個層次記熟、把串流決策樹記熟、把 Redshift 功能矩陣記熟，以及把 Lake Formation 加 DataZone 的分工記熟，大規模資料分析就會成為考試中投報率最高的主題之一。