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.

這個領域涵蓋了可靠且大規模地將原始資料導入資料平台的模式、AWS 服務以及操作細節。資料工程師必須在批次和串流的進入點之間做出選擇，確保資料的編目和可發現性，並針對吞吐量、可重播性及故障模式進行設計。關鍵的 AWS 建構模組包括：用於批次處理的 S3 和 Glue、用於串流處理的 Kinesis 和 Firehose、用於資料庫遷移和 CDC 的 DMS，以及用於臨時性 (ad-hoc) 和推送式 (push-based) 擷取的 API/事件驅動元件 (API Gateway, Lambda, SNS, SQS, S3 events)。

使用 AWS Glue 和 S3 進行批次擷取

Glue 是將批次資料擷取至 S3 和您的資料目錄的主要託管式 ETL 和中繼資料解決方案。典型的模式是：將原始檔案存放到 S3 (使用不同的 raw/zone 前綴)，執行 Glue crawler 來推斷結構 (schema) 並填入 Glue Data Catalog，然後執行 Glue ETL 任務 (Spark) 來進行轉換、分割 (partition)、轉換為列式儲存格式 (Parquet/ORC)，並將優化後的資料寫回 S3。設定 crawler 時，需使用適當的分類器 (classifier) (內建的 CSV/JSON/Parquet 或自訂的 grok/regex)，並給予 crawler 一個具有 s3:GetObject/s3:ListBucket 和 glue:catalog 權限的 IAM 角色——缺少這些權限是常見的操作錯誤。

在設定 Glue 任務和 crawler 時，請使用以下主控台/CLI 模式和開關選項：

• 建立 crawler：

undefined

，並使用

undefined

啟動。

• Glue 任務：

undefined

；啟用任務書籤 (job bookmarks) 以避免重複處理。 Glue 與其他替代方案的決策標準：

• 當您需要託管的 Spark ETL、結構探索以及與 Athena/Redshift Spectrum 的目錄整合時，請使用 Glue。
• 當您需要專門的叢集調校、自訂函式庫或長時間運行的叢集時，請使用 EMR。
• 對於小檔案的輕量級轉換，請使用簡單的 Lambda 或 Glue on-demand。

使用 Kinesis Data Streams 和 Firehose 進行串流擷取

Kinesis Data Streams (KDS) 用於具備重播、消費者控制和精細擴展能力的即時擷取。一個 Kinesis shard 提供 1 MB/秒或 1,000 筆記錄/秒的寫入容量，以及 2 MB/秒的讀取容量；使用

undefined

建立串流，並使用

undefined

放入資料。分割區索引鍵 (Partition key) 決定了 shard 的分配；分割區索引鍵的基數 (cardinality) 過低會導致熱點 shard (hot shards)——可透過增加索引鍵的熵 (entropy) 或在後面加上雜湊值來避免。使用

undefined

來擴展 shard 數量，或啟用 On-Demand 模式以進行自動擴展。

Firehose 是一個交付串流服務，專為近乎即時地交付至目的地 (S3, Redshift, OpenSearch, Splunk) 而優化，具備內建的緩衝、壓縮和可選的 Lambda 轉換功能。使用 BufferingHints 設定緩衝：buffer_size (MB) 和 buffer_interval (秒)，以在交付延遲和成本之間進行調整；啟用壓縮 (GZIP, Snappy)，並設定一個處理用的 Lambda 進行記錄層級的轉換。主要差異：

• Kinesis Data Streams：
  • 即時、支援多個消費者、可重播保留的資料、需明確管理 shard
  • 每個 shard 有吞吐量限制 (1MB/1k 寫入)，必須設計分割區索引鍵
• Kinesis Data Firehose：
  • 託管式交付到目的地、自動重試/退避、無法重播已交付的記錄
  • 支援緩衝 (大小/時間)、壓縮、透過 Lambda 轉換、為 Redshift 載入提供 S3 暫存區

當您需要重播、強大的消費者控制或多個下游消費者時，選擇 KDS；當您需要以最少的操作開銷，簡單地將資料交付和轉換到 S3/Redshift/OpenSearch 時，選擇 Firehose。

使用 DMS 進行資料庫遷移和 CDC

AWS DMS 用於同質/異質性遷移和持續性複寫 (CDC)。部署一個複寫執行個體 (

undefined

)，其大小需能應付吞吐量，而大小的決策取決於變更率、完整載入的資料量以及任務的平行度。DMS 任務類型：

• full-load：僅複製現有資料
• cdc：串流持續的變更
• full-load + cdc：初始載入後，繼續串流變更 使用適當的引擎設定 (JDBC/連線字串) 來配置端點，在來源端啟用補充日誌 (supplemental logging) 或外掛程式，並提供一個 JSON 的資料表對應 (table-mapping) 來篩選/包含資料表。對於以 MySQL 為基礎的來源，DMS CDC 需要啟用二進位日誌 (binlog) 並在來源端設定適當的 binlog_format (建議為 ROW)；對於 PostgreSQL，您必須啟用邏輯複寫和一個像 wal2json 的外掛程式，或使用複寫槽 (replication slots)。透過 CloudWatch 指標和任務日誌來監控任務；調整 batchApplyEnabled 和 maxFullLoadSubTasks 以優化吞吐量。

full-load 和 CDC 之間的決策標準：當您需要停機時間最短的遷移時，使用 full-load+CDC；當初始載入已由其他機制完成後，使用僅 CDC 模式進行持續複寫。務必驗證結構對應，並使用具代表性的資料量來執行測試遷移。

基於 API 與事件驅動的擷取模式

API 與事件適用於推送式擷取與協同運作。常見模式：

• API Gateway -> Lambda -> Firehose/Kinesis：適用於客戶端推送 JSON 事件的場景。使用 API Gateway 的節流 (throttling) 與 Lambda 的並行控制來提供背壓 (backpressure) 並強制執行冪等性標頭 (idempotency headers)。
• S3 事件通知：透過主控台或 aws s3api put-bucket-notification-configuration 設定儲存貯體通知，將物件建立事件傳送至 Lambda、SQS 或 SNS；使用前綴/後綴篩選器來限制觸發。若要實現扇出 (fan-out)，可將 S3 事件路由至 SNS 主題，再分發到多個 SQS 佇列/Lambda 訂閱者，以便在不耦合的情況下將相同事件交付給多個消費者。
• 使用 SQS 與 SNS 進行持久、解耦合的擷取：SQS 用於基於拉取 (pull-based) 的工作者處理，並具備可見性逾時 (visibility timeout)；SNS 用於推送式扇出 (push fan-out)。

維運考量與 CLI 模式：

• 為 Lambda/SQS 的失敗情況使用 DLQ (Dead-Letter Queue)；在 SNS 訂閱上設定重試策略。
• 對於來自 API 的高吞吐量串流，建議批次處理至 Kinesis 或 Firehose，而非同步寫入下游，以避免阻塞 API 客戶端。

常見陷阱與決策標準

• 混淆 Kinesis Data Streams (可重播、分片自行管理) 與 Firehose (託管交付、不可重播)：當您需要重播或多個消費者時，選擇 KDS；若僅需直接的交付管道，則選擇 Firehose。
• 忘記 Glue crawler 的 IAM 權限：務必附加一個 IAM 角色，授予 s3:GetObject/s3:ListBucket 以及 glue:CreateTable/UpdateTable/DeleteTable 權限，以便 crawler 能夠填充 Data Catalog。
• DMS CDC 缺少二進位日誌/邏輯複寫：在啟動 CDC 任務前，需在 MySQL 上啟用 binlog (ROW 格式)，或在 PostgreSQL 上啟用邏輯複寫與 wal2json。
• 分割區索引鍵 (partition key) 的基數 (cardinality) 過低導致熱分片 (hot shards)：透過雜湊 (hashing)、包含高基數屬性或增加分片數量來提高分割區索引鍵的基數；監控 Put/Get 的節流指標。
• Firehose 緩衝過多或緩衝設定不當導致高延遲：根據可接受的延遲與請求量，調整 buffer_size 與 buffer_interval。
• 僅依賴 S3 事件通知而未使用 DLQ 或重試機制：使用 SNS/SQS 扇出或帶有 DLQ 的 Lambda，以避免事件遺失並確保持久的扇出。

實務問題：使用案例情境

RetailCo 公司收集行動裝置的點擊流 (高流量即時數據) 和每日夜間的產品目錄檔案；他們需要即時儀表板和一個整合的分析資料湖。

1. 將點擊流擷取到 Kinesis Data Streams，分割區索引鍵由使用者會話 (user session) + 雜湊後的分片後綴組成；使用 Kinesis Data Analytics 或 Lambda/Kinesis Client Library 建立消費者以進行即時處理。
2. 使用 Kinesis Data Firehose 搭配一個轉換用的 Lambda，將豐富化後的串流輸出以 Parquet 格式持久化到 S3，用 Snappy 壓縮，並可選擇性地載入到 Redshift Spectrum 進行分析。
3. 將每日夜間的目錄檔案放置在 S3 的 raw/ 路徑下，並執行排程的 Glue crawler 來更新 Glue Data Catalog，然後執行 Glue ETL 任務將其轉換為分割後的 Parquet 格式，存放在 curated zone (策展區)。
4. 使用 S3 事件通知 -> SNS -> Lambda 來觸發輕量級的中繼資料更新或使快取失效；將交付路由到 SQS 以進行持久的下游處理。
5. 監控 Kinesis 分片指標 (IncomingBytes, IncomingRecords, PutRecords.Success)，並使用 UpdateShardCount 或 On-Demand 模式的串流來應對增長；啟用 CloudWatch 警報。

AWS 最佳實踐的理由：分離即時與批次處理路徑，當需要重播和消費者隔離時使用 Kinesis Data Streams，使用 Firehose 進行到 S3/目標的託管交付，並維護一個 Glue Data Catalog 以便於資料探索及與 Athena/Redshift 的查詢整合。

所有領域 · 數據儲存與資料湖架構 →

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

瀏覽 Amazon →