Amazon DEA-C01: 數據查詢與分析 — 學習指南

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

屬於 Amazon Data Engineer Associate DEA-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

此領域涵蓋設計、調校與操作支援大型資料集分析查詢及商業智慧 (BI) 的 AWS 服務。其重點在於跨 Athena、Redshift、OpenSearch 和 QuickSight 的符合成本效益、高效能的查詢模式，以及它們如何與 S3、Glue 和交易型儲存互通。要精通此領域，需要在儲存格式、資料分割、運算類型和資料放置之間取得平衡，以最小化掃描的位元組數和網路偏斜，同時提供低延遲的洞見。

Amazon Athena 查詢最佳化

Athena 的定價取決於掃描的位元組數，因此實體資料佈局和中繼資料是主要的調校手段。使用欄式格式 (Parquet 或 ORC) 搭配壓縮 (Parquet 使用 Snappy，ORC 使用 Zlib/ORC 選項) 來減少資料大小和 CPU 使用量。根據高基數、會用於查詢過濾的欄位 (如日期、區域) 來分割資料，並在 Glue 資料目錄中註冊分割區。典型的模式如下：

• 將資料寫入 S3，路徑類似 s3://bucket/events/date=2026-08-02/，並使用 Glue 爬蟲或 MSCK REPAIR TABLE 來填入分割區。
• 使用

undefined

來強制執行欄式壓縮。

• 透過 WHERE 子句引用分割鍵，來使用投影 (projection) 與分割區裁剪 (partition pruning)，以避免掃描不需要的分割區。

當查詢需要與交易型儲存進行聯結 (join) 時，可使用 Athena Federated Query (Lambda 連接器) 來執行與 RDS、DynamoDB 或 Redshift 的跨來源聯結。連接器會部署為 Lambda 函數，並在 Athena 中註冊為資料來源；主控台操作流程範例：Athena > Data sources > Connectors > New。決策標準：

• 當 RDS/DynamoDB 中的資料量不大，或需要將一個小的維度資料表與一個大的 S3 資料集聯結時，使用 Federated Query。
• 對於重複性的大量聯結，應將營運資料擷取並具體化 (materialize) 到 S3 (Parquet 格式)，將聯結成本轉移到單次的 ETL 流程，然後使用 Athena 進行重複讀取。

Amazon Redshift 查詢調校與分佈

Redshift 的效能關鍵在於分佈樣式 (distribution style) 和排序鍵 (sort key)，它們能最小化資料移動並啟用區域對應 (zone mapping)。根據以下決策點選擇 DIST 樣式：

• DISTKEY (KEY)：當需要根據高基數的聯結鍵來聯結大型資料表時很有用；如果兩個資料表共享相同的 DISTKEY，可以避免資料重新分佈。
• ALL：將一個小的維度資料表複製到所有節點，以避免聯結時的網路洗牌 (network shuffles)。
• EVEN：適用於無法預測的工作負載或沒有合適鍵值時的預設選項；可避免熱點 (hotspots)。
• AUTO：當您沒有明確的指引時，讓 Redshift 根據資料表大小和工作負載來選擇。

在用於範圍過濾器 (range filters) 或 ORDER BY 的欄位上定義 SORTKEY，以啟用區域對應並減少磁碟讀取。常見的操作指令：

undefined

• 定期使用 VACUUM 和 ANALYZE：

undefined

；監控 SVV_TABLE_INFO 和 STL_QUERY 以了解偏斜和分佈指標。 Redshift Spectrum 讓您能透過 Glue 資料目錄查詢 S3 的外部資料表。使用以下指令建立外部結構描述 (external schema)：

undefined

Spectrum 與原生 Redshift 的決策標準：

• 對於不常查詢、儲存在 S3 的大型冷資料，或用於分層資料架構時，使用 Spectrum。
• 將熱門、經常聯結的資料集保留在 Redshift 內部以獲得高效能；當與 Spectrum 聯結時，選擇 DISTKEY 來共置 (colocate) 聯結鍵，或使用重新分佈來最小化網路 I/O。

Amazon OpenSearch Service 用於日誌分析

OpenSearch 針對擷取和快速、臨時的日誌分析進行了最佳化；其索引和叢集組態決定了吞吐量和成本。索引設計與生命週期：

• 使用像 logs-YYYY.MM.DD 這樣的索引模式，並透過索引範本設定 index.number_of_shards (小索引：1 個分片；大索引：多個分片，大小約 10–50 GB) 和 index.number_of_replicas 以確保可用性。
• 設定索引生命週期政策 (ILM)，讓索引在熱 (hot)、溫 (warm)、冷 (cold) 和 UltraWarm 層之間轉換以控制成本；UltraWarm 可降低歷史資料在熱節點上的儲存成本。 分片 (sharding) 與複本 (replicas) 會影響查詢和索引效能：
• 更多分片能增加平行處理能力但也會增加額外開銷；根據堆積 (heap) 和 CPU 來調整每個節點的分片數量。
• 複本能提升讀取吞吐量和容錯能力；根據查詢並行性和服務等級協議 (SLA) 來設定複本數量。 操作指令與主控台模式：
• 使用 OpenSearch Dev Tools (或 curl) 來 PUT 索引範本和 ILM 政策，並透過叢集健康狀態 API 進行監控。分配節點屬性並使用分片分配感知 (shard allocation awareness) 來防止熱點問題。 決策標準：
• 當對歷史日誌的查詢延遲要求可以容忍較高的讀取延遲，以換取較低的儲存成本時，選擇 UltraWarm。
• 將最近的索引保留在熱節點上，以支援快速的彙總和儀表板。

QuickSight 用於 BI 與視覺化

QuickSight 提供快速的儀表板，主要有兩種擷取模式：SPICE (記憶體內) 和直接查詢。SPICE 為儀表板提供次秒級的效能，適合重複讀取；而直接 SQL 查詢 (到 Athena、Redshift、RDS) 則較適合非常大的資料集或頻繁變動的資料。關鍵組態與最佳實務：

• 在主控台中建立資料集：New dataset > Choose source (Athena/Redshift/RDS/OpenSearch) > Import to SPICE 或 Use direct query。
• 對於每日/近乎即時的需求，使用排程的 SPICE 重新整理；透過時間戳記分割來設定增量重新整理，以限制資料移動量。 安全性與治理：
• 透過 QuickSight 的使用者/群組對應和資料集規則來實作資料列層級安全性。
• 對於跨帳戶的資料存取，部署 IAM 角色和資源型許可，讓 QuickSight 得以擔任 (assume)。 決策標準：
• 對於有大量同時觀看人數和可預測重新整理時段的儀表板，使用 SPICE。
• 當資料新鮮度至關重要或 SPICE 容量受限時，使用直接查詢；可結合計算欄位和參數來提供互動式的使用者體驗。

常見陷阱與決策標準

• Athena 根據掃描的資料量收費 — 務必根據查詢述詞 (query predicates) 進行分割 (partition)，並以壓縮過的 (Snappy/Zlib) 欄式格式 (Parquet/ORC) 儲存，以減少掃描的位元組數。
• 在低基數 (low-cardinality) 欄位上使用 Redshift DISTKEY 會導致資料傾斜 (data skew) — 請為 DISTKEY 選擇高基數的連接鍵 (join keys)，或對小型維度資料表使用 DISTSTYLE ALL。
• Redshift Spectrum 外部資料表需要 Glue Data Catalog — 確保目標區域已啟用 Glue，且 IAM 角色允許 Redshift 存取該目錄。
• OpenSearch 分片 (shard) 數量與大小設定錯誤 — 避免過多的小型分片；將分片大小設定為數十 GB，並使用 ILM 將較舊的索引移至 UltraWarm 以節省成本。
• 在 Redshift 進行大量載入後忘記執行 RUN ANALYZE/VACUUM — 排程執行 ANALYZE 與 VACUUM 以更新統計數據並回收磁碟空間，從而獲得最佳的查詢計畫。
• QuickSight SPICE 容量溢位與資料過時 — 規劃 SPICE 容量，使用增量重新整理，或針對即時需求切換到直接查詢 (direct query)。

實務問題：使用案例情境

Acme Retail 需要每日的 BI 報告，其中結合了 Amazon RDS 中的交易訂單、S3 中的點擊流事件 (clickstream events) 以及 DynamoDB 的使用者設定檔，同時有成本限制，且儀表板對於近期資料的重新整理需在分鐘內完成。

1. 將 S3 中的點擊流資料轉換為以日期分割的 Parquet 格式，使用 Snappy 壓縮，並透過 crawler 在 AWS Glue 中註冊中繼資料 (metadata)。
2. 使用 Athena 對 S3 進行 ad-hoc 查詢，並部署 Federated Query 連接器以對 RDS 和 DynamoDB 執行小型維度資料表的連接；如果查詢重複執行，則將頻繁的連接結果具體化 (materialize) 為 Parquet 格式。
3. 佈建 Redshift 以進行繁重的分析型連接：將匯總的快照載入 Redshift，在高基數的 customer_id 上設定 DISTKEY，並在 order_date 上定義 SORTKEY；使用 Spectrum 處理 S3 中的冷歷史資料。
4. 使用每日索引模式 (daily index patterns) 將應用程式日誌擷取到 OpenSearch；應用 ILM 將近期的索引保留在熱節點 (hot nodes) 上，並將較舊的索引移至 UltraWarm 以節省成本。
5. 建立 QuickSight 儀表板：將近期的匯總資料匯入 SPICE，並透過排程的增量重新整理來達到分鐘級的感知回應速度，並對需要永遠保持最新的指標使用直接查詢。

理由：此方法透過分割與欄式格式將 Athena 的掃描成本降至最低，藉由適當的分配與排序鍵減少 Redshift 的網路資料交換 (network shuffle)，使用 Spectrum 避免在 Redshift 中儲存冷資料，應用 OpenSearch ILM 來優化儲存成本，並利用 SPICE 提供反應快速的儀表板，同時透過直接查詢保持關鍵資料的即時性。

← 數據編排與工作流程管理 · 所有領域 · 數據安全、治理與合規 →

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

瀏覽 Amazon →