Amazon SAP-C02: 資料庫與分析 — 學習指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

屬於 AWS Solutions Architect Professional SAP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

交易型資料庫、擴展模式與快取

選擇 Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server)、Amazon Aurora 還是 Amazon DynamoDB，首先要從工作負載的特性開始分析：嚴格的關聯式結構描述和複雜的交易所，適合使用 RDS/Aurora；而大規模擴展、個位數毫秒級的查詢以及彈性的結構描述，則適合使用 DynamoDB。Aurora 透過分散式儲存提供高吞吐量，並具備複本自動擴展、快速容錯轉移、用於跨區域讀取的 Global Database，以及低延遲的災難復原能力。RDS Multi-AZ 提供同步複寫以確保高可用性，但無法擴展讀取能力；讀取複本 (RDS/Aurora) 則是用來處理讀取密集型的工作負載。對於鍵值快取和微秒級延遲的需求，ElastiCache (Redis 或 Memcached) 可減輕資料庫負載；MemoryDB for Redis 則在需要資料具備高可用性與可恢復性的情境下，增加了持久性與 Redis 相容的資料儲存能力。常見的陷阱包括：低估連線數限制 (例如 MySQL 的最大連線數)、未使用連線池 (Connection Pooling) (導致 Lambda/容器產生大量連線)、因不良的鍵值設計造成 DynamoDB 中的熱分割區 (hot partition)，以及忽略快取收回 (eviction) 與設計，導致資料過時。決策上的權衡通常圍繞在成本、效能與彈性之間：預配置的 Aurora/大型 RDS 執行個體成本較高，但能降低延遲並簡化交易；而採用隨需或自動擴展模式的 DynamoDB 雖可降低營運成本，卻需要謹慎的結構描述與容量規劃。加密、自動備份、PITR (時間點復原) 以及跨區域複寫模式，都應根據 RPO/RTO 的要求來選擇。

資料湖、ETL 與分析查詢引擎

S3 是標準且耐用的資料湖儲存；設計時應圍繞著分割 (partitioning)、欄位式格式 (Parquet/ORC)、壓縮與檔案合併 (compaction) 來進行，以實現具成本效益的查詢。AWS Glue 與 AWS Glue Data Catalog 提供無伺服器的 ETL、結構描述探索與目錄建立功能；Lake Formation 則為受治理的資料湖增加了集中式存取控制、精細的權限管理以及跨帳戶共享的能力。對於互動式分析，Amazon Athena 可直接查詢 S3 中的資料 (無伺服器、按查詢付費)，而 Amazon Redshift (支援 RA3/Iceberg) 則為複雜的商業智慧 (BI) 與關聯查詢 (join) 提供了高效能的託管式 MPP 資料倉儲。使用 Redshift Spectrum 可以從 Redshift 中查詢 S3 資料，而無需將所有資料都載入倉儲。Kinesis Data Firehose 是一個託管式的擷取路徑，可將串流事件傳送到 S3 或 Redshift。常見的架構陷阱包括：過多的小檔案導致 Athena/Redshift 的高額開銷、選擇不當的分割鍵 (partition key) 造成資料傾斜 (skew)，以及未能將檔案合併或轉換為欄位式格式。權衡點在於延遲與成本：Athena 對於臨時性 (ad-hoc) 查詢的營運成本較低；Redshift 則以較高的預配置成本提供更強的持續性效能。透過 Glue/Lake Formation 實現的資料治理與血緣關係 (lineage) 對於法規遵循及多團隊共同擁有權至關重要。

串流、即時處理與搜尋

即時資料擷取與處理可使用 Kinesis Data Streams (基於 shard 的吞吐量與順序保證)、Kinesis Data Firehose (託管式傳送到目的地)、Kinesis Data Analytics (SQL/Apache Flink 處理)，或是針對 Kafka 相容需求的 Amazon MSK。當需要直接與 AWS 原生無伺服器服務整合時，選擇 Kinesis；當客戶端依賴 Kafka 生態系的工具時，則選擇 MSK。「至少一次」的交付語意 (At-least-once delivery semantics)、shard 數量限制、消費者平行處理能力，以及未能配置足夠的 shard，都是常見的營運陷阱。為了下游的快速搜尋與可觀測性，Amazon OpenSearch Service 提供了索引、近乎即時的搜尋以及內建的 Kibana 儀表板；索引生命週期管理與溫/冷層 (warm/cold tiers) 則可降低舊資料的儲存成本。使用 Kinesis + Lambda 或 Kinesis + KDA 的組合，可以在將事件持久化到 OpenSearch 或 S3 之前，對其進行擴充或轉換。由於重試或重播會導致重複資料，因此應在消費者端設計冪等性 (idempotency) 與重複資料刪除 (deduplication) 的機制。決策標準需在吞吐量與延遲之間取得平衡：擁有大量 shard 的 Kinesis 支援高吞吐量，但會增加成本與管理複雜度；Firehose 雖減輕了消費者的負擔，但提供的轉換彈性較小。

遷移、複寫、治理與維運韌性

Database Migration Service (AWS DMS) 與 Schema Conversion Tool (SCT) 是同質與異質搬遷的主要遷移工具，能夠實現持續的異動資料擷取 (CDC)。遷移模式包含 rehost (直接遷移)、replatform (平台轉換，例如移轉至 Aurora)，以及在適當情況下重構至 DynamoDB 或無伺服器架構。使用 DMS 時應搭配遷移前與遷移後的驗證、平行資料表複製，並謹慎處理 LOB/LOBLOB。跨帳戶與跨區域複寫需要 KMS 金鑰的存取權限、VPC peering 或 Transit Gateway，以及網路頻寬規劃；當需要跨區域的低延遲讀取時，Global Databases 和讀取複本是替代方案。治理與安全性必須包含用於資料共享的 Lake Formation、IAM 最小權限原則、針對 S3 和 RDS 快照的資源政策，以及使用 VPC 端點/PrivateLink 以避免公有網路出口流量。維運上的陷阱包含監控不足 (錯失複本延遲)、未測試容錯移轉/runbook，以及大量傳輸期間隱藏的出口流量成本。備份、PITR 策略與自動化復原都會影響 RTO/RPO 的權衡取捨；應結合複寫以提高可用性，並搭配定期備份以滿足長期保留和合規性要求。

實務問題：使用案例情境

情境：Acme Retail 在一個多帳戶的 AWS Organization 中營運一個電子商務平台，其生產環境工作負載位於 us-east-1 和 europe-west-1。他們將點擊流和交易事件儲存到 S3，並營運一個地端的 OLTP 資料庫，該資料庫必須以最少的停機時間遷移到 AWS。

挑戰：將 OLTP 資料庫遷移到一個高可用、可跨區域讀取擴展的目標，同時在 S3 上建立一個具備即時擷取和查詢能力的受治理分析資料湖。

建議方法：

使用 AWS DMS 搭配 SCT 進行結構描述轉換，並設定從地端資料庫到位於 us-east-1 的 Amazon Aurora (Global Database) 的持續 CDC，同時在 europe-west-1 建立一個 Aurora 讀取複本。
透過 Amazon Kinesis Data Streams 和 Firehose 擷取點擊流與交易事件；將原始事件緩衝並以 Parquet 格式交付到 S3，並按日期和區域進行分割。
使用 AWS Glue 將 S3 資料編目，透過 Lake Formation 強制執行存取控制，並使用 Glue jobs (或 Glue Studio) 執行 ETL 以產出整理過的資料集；再透過 Amazon Athena 和 Redshift Spectrum 將其提供給分析師使用。
加入 ElastiCache (Redis) 以對熱門產品和會話資料進行高讀取快取；使用 CloudWatch 實作端到端的監控，在 Aurora 上啟用增強型監控，並用 runbook 驗證容錯移轉。

理由：此方法使用 DMS CDC 將停機時間降至最低，透過 Aurora Global Database 提供低延遲的全域讀取，建立一個受治理的 S3 資料湖以實現分析敏捷性，並透過快取和解耦的串流擷取來降低 OLTP 系統的負載，這一切都符合企業韌性和效能的最佳實踐。

← 儲存與資料管理 · 所有領域 · 遷移與現代化 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →