批次 vs 串流資料攝取模式

批次 (Batch) 與串流 (Streaming) 擷取的決策是資料工程師在為新管道建立架構時最重要的單一選擇。它決定了哪些 AWS 服務可以選用、成本結構如何、維運團隊如何對故障發出警報，以及下游分析取用者將如何看待資料。DEA-C01 考試的社群研究指南 — Tutorials Dojo, ExamCert.App, Digital Cloud Training 以及熱門的 Medium 攻略 — 都指出了相同的痛點：考生低估了在延遲需求下選擇批次與串流的細微差別。考試中常設置情境題，其中錯誤答案是「Kinesis Data Firehose」，因為需求說明是「即時」(Firehose 是近乎即時)，或者是「Lambda」，因為需求是「無伺服器」(Lambda 有 15 分鐘的上限，會中斷長期的 ETL 作業)。正確區分批次與串流擷取意味著要對延遲分層、服務系列、成本維度以及規範陷阱瞭如指掌。

本學習筆記專為資料工程師的視角編寫。它涵蓋了現代 AWS 架構中資料擷取的含義、批次與串流的二分法、從亞秒級到每日的延遲分層、ETL vs ELT 權衡、AWS 服務決策樹、推送 vs 拉取模型、扇入與扇出模式、讀取時結構描述 vs 寫入時結構描述、等冪性與恰好一次語義、每種模式的成本維度以及困擾大多數考生的考試陷阱。到最後，批次與串流擷取的決策應該成為您在任何架構審查或考試情境中都能辯護的結構化選擇。

什麼是 AWS 資料工程中的資料擷取？

資料擷取 (Data Ingestion) 是將資料從來源系統移動到下游取用者可以進行分析的目的地的行為。來源包括操作資料庫 (RDS, DynamoDB, 本地部署 Oracle)、SaaS 應用程式 (Salesforce, ServiceNow, Stripe)、串流來源 (IoT 裝置, 應用程式事件日誌, 點擊流) 以及檔案共用 (NFS, SMB, HDFS, 其他帳戶中的 S3 儲存貯體)。目的地包括資料湖 (S3)、資料倉儲 (Redshift)、搜尋索引 (OpenSearch)、操作存放區 (DynamoDB, Aurora) 以及下游串流 (另一個 Kinesis 串流, SQS 佇列, Lambda 取用者)。

擷取層是操作世界與分析世界之間的邊界。如果出錯，每個下游管道都會付出代價 — 延遲的資料、丟失的記錄、結構描述漂移、重複的資料列、爆炸的 S3 帳單、來自不穩定作業的警報疲勞。如果做對了，下游管道就會變得枯燥、可預測且便宜。

兩種基本模式

每個擷取管道都屬於這兩種模式之一或兩者的混合。批次擷取 (Batch ingestion) 按排程成塊移動資料 — 每小時、每晚、每週。串流擷取 (Streaming ingestion) 在事件發生時持續移動資料 — 逐筆記錄或以秒為單位的微批次。選擇取決於下游取用者的延遲需求、來源的處理量特性、成本預算以及團隊可以負擔的維運複雜性。

批次擷取 — 排程作業與微批次

批次擷取是現代資料工程中較舊、較簡單且仍占主導地位的模式。大多數分析工作負載不需要亞秒級的新鮮度 — 昨天的銷售報告不會因為五分鐘前的交易而改變。批次擷取在每 GB 擷取成本上更便宜，更容易推理，且在發生故障時更容易復原。

經典批次 — 每小時、每日、每週

經典批次作業按固定排程執行。範例：每天 02:00，AWS Glue 透過 AWS Transfer Family 從 SFTP 伺服器讀取昨天的交易檔案，使用 PySpark 進行轉換，並將 Parquet 分區寫入 S3 資料湖。每小時整點，EMR 步驟透過 COPY 將最後一小時的 CDC 記錄從 DMS 複寫的 S3 複製到 Redshift。每週一次，SageMaker Processing 作業為建模團隊重新聚合客戶行為特徵。

關鍵特徵：資源使用可預測、易於監控（已知作業的成功或失敗）、相對於相同資料量的串流來說成本較低，且易於回填 (backfill)（只需使用不同的日期範圍重新執行）。缺點：資料至少有一個批次間隔的新鮮度延遲，這對於欺詐檢測、即時個人化、IoT 警報以及需要亞分鐘新鮮度的操作儀表板來說是錯誤的。

微批次 (Micro-Batch) — 混合甜點區

微批次介於經典批次和純串流之間。微批次管道不是每小時執行一次大型作業，而是每隔一段很短的時間（例如每 60 秒）處理一次小塊資料，並使用相同的批次工具。AWS Glue Streaming 作業、EMR 上的 Spark Structured Streaming，甚至每分鐘排程的 Lambda 呼叫都屬於這一類。延遲降至秒到分鐘級別，同時保留了批次的維運簡單性。

微批次是大多數「近乎即時」需求的務實答案。它也是 Kinesis Data Firehose 的底層引擎，Firehose 在將記錄以微批次寫入 S3 之前會緩衝 60-900 秒。

何時批次優於串流

當下游取用者是報告、每小時或更慢重新整理的儀表板、機器學習訓練管道、每月對帳、監管提交，或任何新鮮度以小時衡量即可接受的工作負載時，請選擇批次。當來源資料以批次形式到達時 — 例如每日檔案投放或每晚資料庫提取 — 批次也是正確的，因為先將其轉換為串流會增加零價值和顯著的複雜性。

串流擷取 — 持續事件流

串流擷取將資料視為無界的事件序列，必須在事件到達時對其進行處理。心態的轉變是從「處理這個有限的區塊」轉變為「以有界的延遲對每個事件做出反應」。

亞秒級延遲與無界資料集

串流管道的目標是從事件建立到取用者可見，端到端延遲在亞秒級到個位數秒級。資料集沒有終點 — IoT 感測器永遠發送，點擊流事件永遠流動，交易日誌永遠追加。維運指標從「作業是否成功」轉向「我的疊代器生命週期 (iterator age) 是多少、我的取用者延遲 (consumer lag) 是多少、我的處理中訊息數是多少」。

串流的真實使用案例

即時欺詐評分：一筆交易進入 Kinesis Data Streams，Lambda 或 Flink 取用者根據部署的 ML 模型對其進行評分，並在 200 毫秒內返回批准或拒絕決策。IoT 遙測：數千台裝置將讀數推送到 Kinesis，聚合器計算移動平均值，並在溫度超過閾值時觸發警報。點擊流個人化：使用者點擊產品，事件流經 MSK，Flink 更新使用者的工作階段個人檔案，下一次頁面渲染使用更新後的個人檔案。

ETL vs ELT — 載入前或載入後轉換

轉換時機的決策位於更廣泛的擷取架構中，並決定了您選用哪些 AWS 服務。

ETL — 載入前轉換

在 ETL (Extract, Transform, Load) 中，轉換發生在來源與目的地之間。AWS Glue、EMR 和 Lambda 是常見的轉換引擎，它們讀取原始資料，應用結構描述強制執行、聯結、聚合和驗證，然後將乾淨的精選資料寫入目的地。目的地是「簡報就緒」的 — Redshift 金級資料表、S3 中可由 Athena 查詢的 Parquet 分區。

當目的地運算成本昂貴 (Redshift)、當下游取用者期望乾淨的結構描述、當原始資料必須為了合規而捨棄，或當轉換過於複雜而無法推送到查詢時執行時，ETL 非常適用。

ELT — 載入後轉換

在 ELT (Extract, Load, Transform) 中，原始資料首先存入目的地，轉換作為下游步驟執行。Redshift COPY 載入原始資料，然後具體化視圖 (materialized views) 或排程的 SQL 作業進行轉換。S3 存放原始區 (raw zone)，然後 Glue 或 Athena CTAS 產生精選區 (curated zones)。EMR Hudi/Iceberg 資料表讓您更新插入 (upsert) 原始資料並使用 SQL 建立精選視圖。

當儲存成本便宜（S3 始終便宜，具有受管儲存的 Redshift RA3 也便宜）、當運算資源彈性且僅在查詢時付費、當資料科學家想要存取原始資料進行探索，以及當下游轉換比完整 ETL 作業的編排更簡單時，ELT 非常適用。

現代湖倉 (Lake House) 混合模式

大多數生產環境中的 AWS 管道都是混合的。原始資料透過 DataSync、AppFlow 或 Kinesis Firehose 存入 S3 原始區 (E + L)。Glue 或 EMR 建置精選的 Parquet 分區 (T)。Redshift Spectrum 查詢精選區，或者 Redshift COPY 將子集拉入熱資料表中以進行亞秒級的 BI 查詢 (再次 E + L)。ETL 與 ELT 之間的界限變得模糊 — 對於考試而言，重要的是辨識哪個服務扮演哪個角色。

延遲分層 — 即時、近乎即時、批次

延遲需求是 AWS 服務選擇的第一道過濾器。請記住三個層級。

即時 (Real-Time, 低於 1 秒)

從事件建立到取用者可見，端到端低於一秒。服務：具有自定義取用者的 Kinesis Data Streams、具有自定義 Kafka 取用者的 Amazon MSK、用於串流處理的 Amazon Managed Service for Apache Flink、具有預佈建並行性的 Lambda、用於狀態的 MemoryDB。使用案例：欺詐評分、即時競價、線上推薦、IoT 警報。

近乎即時 (Near-Real-Time, 秒到分鐘級)

端到端延遲在秒到分鐘範圍內。服務：Kinesis Data Firehose (60-900 秒緩衝)、Glue Streaming 作業、由 S3 PUT 事件觸發的 Lambda、具有批次處理功能的 EventBridge Pipes。使用案例：操作儀表板、日誌聚合、異常偵測、行銷事件漏斗。

批次 (Batch, 小時到天)

端到端延遲在小時到天範圍內。服務：AWS Glue 排程作業、EMR 排程叢集、AWS Batch、排程的 Step Functions 工作流程、觸發 Lambda 或 Glue 的 EventBridge Scheduler、DMS 全量載入任務。使用案例：每晚報告、監管 ETL、ML 訓練資料重新整理、每日對帳。

服務選擇決策樹

AWS 資料工程擷取領域非常廣泛。結構化的決策樹可以在幾秒鐘內將其過濾到正確的服務。

步驟 1 — 是串流還是批次？

如果事件是持續的且下游需要亞分鐘反應：串流。如果事件按排程成塊到達或分析延遲可以接受：批次。

步驟 2 — 對於串流，選擇正確的服務系列

具有 Kafka 生態系統（現有的本地部署 Kafka、Kafka Connect、結構描述登錄期望）的亞秒級延遲：MSK。具有 AWS 原生簡單性的亞秒級延遲：Kinesis Data Streams。無需自定義取用者程式碼即可近乎即時地遞送到 S3/Redshift/OpenSearch：Kinesis Data Firehose。具有視窗化功能的具狀態事件時間串流處理：Managed Service for Apache Flink。具有篩選功能的輕量級事件路由：EventBridge Pipes。

步驟 3 — 對於批次，按來源類型和體積選擇

資料庫 CDC 和全量載入：AWS DMS。SaaS 應用程式 (Salesforce, ServiceNow, Stripe)：AppFlow。檔案共用 (NFS/SMB/HDFS)：DataSync。PB 級離線傳輸：Snowball。重度轉換的 ETL：AWS Glue 或 EMR。輕量級無伺服器處理：由 S3 事件或 EventBridge Scheduler 觸發的 Lambda。

步驟 4 — 考慮成本和維運開銷

EC2 上的自我管理 Kafka：在極高處理量下每位元組最便宜，維運負擔最高。MSK Provisioned：受管 Kafka，由您調整代理程式大小。MSK Serverless：零代理程式管理，按需定價。Kinesis Data Streams：按碎片 (shard) 計費，針對不可預測的工作負載提供按需模式。Kinesis Data Firehose：按記錄計費，全受管。Glue：按 DPU 小時計費，可針對批次進行擴展。Lambda：按呼叫次數加上持續時間計費，對於低體積事件驅動最便宜。

推送 vs 拉取擷取模型

除了批次 vs 串流外，擷取架構還按誰發起資料移動而拆分。

推送模型 (Push Models) — 來源驅動遞送

在推送模型中，來源主動將資料遞送到目的地。生產者對 Kinesis Data Streams 呼叫 PutRecord、寫入 MSK 主題、發佈到 API Gateway 或觸發引發 Lambda 的 S3 PUT 事件。推送是串流的理想選擇，也適用於資料工程師無法執行拉取代理程式的來源系統。

拉取模型 (Pull Models) — 目的地驅動提取

在拉取模型中，目的地按排程輪詢或掃描來源。Glue 爬蟲走訪 S3 前置詞、AppFlow 提取 Salesforce 記錄、DMS 將 RDS 複寫到 S3、AWS Transfer Family 接收上傳的檔案。拉取是批次的預設選擇，也適用於具有穩定 API 的來源系統。

混合模式很常見

許多真實架構結合了兩者：DynamoDB Streams（從 DDB 推送）進入 Lambda（從串流拉取）進入 Kinesis Firehose（推送到 S3）。辨識這種混合特性是 DEA-C01 級別架構設計的一部分。

扇入 (Fan-In) 與 扇出 (Fan-Out) 模式

串流架構很少只有一個生產者和一個取用者。扇入和扇出模式是基礎。

扇入 — 許多生產者對應一個串流

扇入將許多小生產者合併到一個合併的串流中。數千台 IoT 裝置寫入一個 Kinesis Data Stream，其中碎片按分區鍵分配負載。數百個微服務將事件發佈到一個 MSK 主題。扇入簡化了下游取用並集中了監控。

扇出 — 一個串流對應許多取用者

扇出讓多個獨立的取用者在不互相干擾的情況下處理同一個串流。Kinesis Data Streams 支援增強型扇出 (Enhanced Fan-Out, EFO)，為每個取用者提供每個碎片專屬的 2 MB/s 讀取管道。MSK 取用者群組讓獨立應用程式按自己的進度讀取同一個主題。如果沒有扇出，取用者會競爭共享的碎片讀取處理量，並互相拖慢速度。

讀取時結構描述 (Schema-on-Read) vs 寫入時結構描述 (Schema-on-Write)

結構描述何時被強制執行？選擇會影響成本和可靠性。

寫入時結構描述 — 在擷取時強制執行

寫入時結構描述在擷取時強制執行結構描述。不符合要求的記錄在到達目的地之前會被拒絕。具有嚴格類型的 Redshift COPY、驗證 Kafka 生產者的 Glue Schema Registry 以及具有欄位級映射的 DMS 都強制執行寫入時結構描述。優點：下游資料乾淨、對生產者錯誤能快速失敗、分析查詢可預測。缺點：結構描述演進需要協調生產者和取用者的更改；被拒絕的記錄需要死信 (dead-letter) 策略。

讀取時結構描述 — 延遲到查詢時執行

讀取時結構描述將原始資料接受到湖中，並在查詢時應用結構描述。帶有 Athena 的 S3 原始區（Glue 資料目錄為 SELECT 應用結構描述）、具有結構描述演進的 Iceberg 資料表以及 Hudi 資料表都延遲了強制執行。優點：擷取速度快、生產者與取用者無耦合、結構描述可以演進而不破壞歷史資料。缺點：當原始資料格式錯誤時會出現查詢時錯誤、較難對生產者漂移發出警報。

如何選擇

寫入時結構描述適用於受監管的工作負載、低延遲分析以及穩定成熟的管道。讀取時結構描述適用於探索性資料科學、結構描述靈活的來源（JSON API、半結構化日誌）以及湖泊架構（拒絕有效資料的成本超過了延遲偵測到結構描述錯誤的成本）。

等冪性 (Idempotency) 與 恰好一次 (Exactly-Once) 語義

可靠的資料管道需要仔細處理重試和重複。

等冪性 — 相同操作，相同結果

等冪操作無論應用多少次，都會產生相同的最終狀態。如果重複的 ID 被去重，那麼插入以交易 ID 為鍵的記錄就是等冪的。具有序列號的 PutRecord、S3 PutObject（覆蓋）以及 Glue 作業書籤（狀態追蹤）都是等冪的。

恰好一次 — 強大保證

恰好一次 (Exactly-once) 語義保證每筆記錄即使在發生故障時也只會被處理一次。Kinesis Data Streams 加上具有檢查點功能 (checkpointing) 的 Kinesis 用戶端程式庫 (KCL) 透過「至少一次遞送加上取用者端去重」來近似實現恰好一次。具有 Kafka 交易和等冪生產者的 MSK 在 Kafka 層級提供恰好一次。具有檢查點功能的 Managed Service for Apache Flink 為串流處理提供恰好一次。

為什麼重要

如果沒有恰好一次，短暫的取用者崩潰加上重新啟動可能會導致收入重複計算、重新套用費用或產生重複的欺詐警報。DEA-C01 考試會詢問類似「取用者在批次中途崩潰，記錄會發生什麼」的情境 — 答案取決於架構是否具有檢查點、等冪生產者或僅提供至少一次遞送。

成本維度比較

服務選擇也是一種成本最佳化練習。

按碎片 / 按 PUT 定價 — Kinesis Data Streams

Kinesis Data Streams 按碎片小時 (shard-hour) 計費（在 us-east-1 為 $0.015/hr），加上每百萬次 PUT 記錄。按需模式將碎片小時替換為按每 GB 擷取率計費。成本隨處理量擴展；在預佈建模式下，閒置串流仍會產生碎片小時費用。

按記錄定價 — Kinesis Data Firehose

Kinesis Data Firehose 按每 GB 擷取量計費（在 us-east-1 為 $0.029/GB），沒有最低限制。格式轉換、動態分區和 VPC 遞送會增加每 GB 附加費。對於低到中等容量的資料，這是通往 S3 的最便宜路徑；對於高處理量串流，成本會累積。

DPU 小時 — AWS Glue

Glue ETL 作業按每 DPU 小時收費（標準 Spark 工作節點為 $0.44/DPU-hour）。Glue Streaming 和 Glue Studio 作業遵循相同的模型。Glue 爬蟲按 DPU 小時收費，每項作業最低計費 10 分鐘。成本隨資料量和轉換複雜性擴展。

按呼叫次數 — Lambda

Lambda 按請求次數加上持續時間的每 GB 秒計費。對於低容量的事件驅動擷取（每天低於數百萬個事件），Lambda 是最便宜的路徑。超過該容量，Kinesis 或 Glue Streaming 在每事件成本上更具優勢。

白話文解釋 — Batch vs Streaming Ingestion

批次與串流的選擇是一種權衡，僅憑名稱會錯過工程現實。三個具體的類比可以使結構變得直觀。

類比 1 — 餐廳食材配送對比現場點餐

想像一家繁忙的餐廳。每天一次，一輛冷藏卡車停在後門，卸下一天的蔬菜、蛋白質和乾貨 — 這種遞送就是批次擷取 (batch ingestion)。廚房知道它會來，準備好了工作人員接收，有空間存放所有東西，並且可以將整個貨件作為一個單元處理。如果卡車晚到了兩個小時，沒人會恐慌；明天的準備工作只需順延即可。現在想像一位顧客在櫃檯點咖啡。咖啡師接單、煮咖啡、蒸牛奶，並在 90 秒內將杯子遞回 — 這種訂單流就是串流擷取 (streaming ingestion)。訂單持續到達，每個訂單都單獨處理，即使延遲 60 秒也會產生顯見的隊列。

食材配送使用堆高機、托盤車、大型冰箱 — 這是批次的重型基礎設施 (Glue, EMR, Snowball)。咖啡師工作站使用單台濃縮咖啡機、奶泡機、杯架 — 這是串流的輕量級單事件基礎設施 (Kinesis, Lambda, MSK)。試圖為每位顧客開一輛卡車到櫃檯是荒謬的；試圖批次處理一百份飲料訂單後再開始煮咖啡也會失敗。這兩種擷取模式的存在是因為現實世界中這兩種資料流模式都存在。

類比 2 — 郵政郵件卡車對比電話通話

想像發送同一商務訊息的兩種方式。選項一：郵政郵件卡車 — 您寫信、投進郵箱、郵政服務每天收集兩次郵件、通宵分揀、明天送達。端到端延遲：24-48 小時。選項二：電話通話 — 您撥號、接收者接聽、您講話、他們立即聽到。端到端延遲：不到一秒。

郵政系統是批次擷取 — 每個遞送週期處理量高（一輛卡車裡有數千封信）、每件成本低、遞送窗口可預測、易於復原（信件丟失？明天補發）。電話通話是串流擷取 — 每次通話處理量最低（一次對話）、每分鐘成本較高、亞秒級延遲、較難復原（通話中途斷線？您必須重新撥號並記住剛才講到哪裡）。郵件和電話之間的選擇無關偏好，而是關乎訊息是否必須立即獲得確認。每月的帳單透過郵件發送。醫療緊急情況則打電話。選錯管道會浪費金錢或冒生命危險。DEA-C01 考試的工作原理也是如此。

類比 3 — 季度庫存盤點對比實時收銀機

想像一家零售店追蹤銷售的兩種方式。第一種是季度庫存盤點 — 每三個月，商店停業一個週末，員工實體清點貨架和倉庫中的每件商品，系統與正式庫存進行對帳。這就是批次擷取 — 衡量時刻的準確度高、工作量大、頻率低，且資料在幾乎整個季度內都是過時的。第二種是實時收銀機 — 每次顧客購買商品，條碼掃描都會立即扣除庫存並更新儀表板。這就是串流擷取 — 每場事件持續擷取、儀表板始終是最新的，但需要維護更多的基礎設施（每台收銀機都聯網、每筆交易都記錄）。

一家小店可能只執行季度盤點 — 便宜、簡單，且對流動緩慢的商品來說，過時資料是可以接受的。擁有數百萬 SKU 的連鎖店則兩者兼具 — 收銀機用於實時追蹤，季度盤點用於對帳。DEA-C01 考試的情境題中，正確答案可能是實時收銀機模式 (Kinesis)，而錯誤答案則提供季度盤點 (Glue 排程)。辨識哪種模式符合需求是核心技能。

批次與串流擷取的常見考試陷阱

DEA-C01 考試設置了一套固定的陷阱。請記住這五個。

陷阱 1 — 將 Firehose 用於即時需求

情境說「1 秒內進行即時欺詐偵測」並提供 Kinesis Data Firehose 作為答案。錯誤。Firehose 的最小緩衝間隔為 60 秒，充其量只是近乎即時。正確答案是 Kinesis Data Streams 加上 Lambda 或 Flink 取用者。

陷阱 2 — 將 Lambda 用於長時間運行的批次 ETL

情境描述了一個處理 100 GB 資料、時長 4 小時的轉換作業，並提供 Lambda 作為無伺服器答案。錯誤。Lambda 有 15 分鐘的硬性超時限制。正確答案是 AWS Glue 或 EMR，適合處理此類規模和時長的轉換。

陷阱 3 — Glue 爬蟲將每個檔案視為獨立的資料表

情境描述了單個 S3 前置詞下具有不同結構描述版本的檔案，並詢問為什麼爬蟲會建立數十個資料表。原因是爬蟲的結構描述啟發式演算法判定這些檔案不夠相似，無法歸類為同一個資料表。修復方法是設定爬蟲的 TableGroupingPolicy=CombineCompatibleSchemas 並保持整潔的分區佈局 — 而不是移除爬蟲。

陷阱 4 — 混合架構中的推送與拉取混淆

情境描述了 Kinesis Data Streams 饋送 Lambda，Lambda 寫入 DynamoDB。考試詢問哪一端是推送，哪一端是拉取。生產者推送到 Kinesis (PutRecord)；Lambda 由 Kinesis 觸發器呼叫（從 Kinesis 角度是推送，但 Lambda 的輪詢器在底層是從串流拉取）。從生產者的角度看，該架構是端到端推送；在 Lambda 端則內部是拉取。

陷阱 5 — 將批次與「總是緩慢」混淆

考生假設批次總是意味著數小時的延遲。錯誤。使用 Glue Streaming 或 EMR 上的 Spark Structured Streaming 的微批次可以提供秒到分鐘級的延遲，同時保持批次的維運簡單性。考試設置的情境中，微批次可能是「近乎即時」需求的正確答案，而純串流 (Kinesis Data Streams + Flink) 和純批次 (Glue 每小時排程) 都是干擾項。

關鍵數字與必須記住的事實

延遲分層

• 即時：端到端低於 1 秒 (Kinesis Data Streams + 自定義取用者, MSK + 自定義取用者, Managed Flink)
• 近乎即時：秒到分鐘 (Kinesis Data Firehose 60-900s 緩衝, Glue Streaming, Lambda S3 觸發)
• 批次：小時到天 (Glue 排程, EMR 排程, DMS 全量載入)

Kinesis Data Streams 處理量

• 每個碎片 1 MB/s 寫入
• 每個碎片 2 MB/s 讀取（共享）或每個取用者每個碎片 2 MB/s 讀取（增強型扇出）
• 每個碎片每秒 1000 筆記錄寫入

Kinesis Data Firehose 緩衝

• 緩衝大小：1-128 MB
• 緩衝間隔：60-900 秒（最小 60 秒）
• 輸出目的地：S3, Redshift (透過 S3), OpenSearch, HTTP 端點, Splunk, Snowflake

擷取的 Lambda 限制

• 15 分鐘硬性超時
• 最大 10 GB 記憶體
• 同步承載量 (payload) 6 MB，非同步承載量 256 KB

Glue ETL 定價

• 每 DPU 小時 $0.44（標準工作節點）
• 每次作業最低計費 10 分鐘
• G.1X: 1 DPU, G.2X: 2 DPU, G.4X: 4 DPU, G.8X: 8 DPU 每個工作節點

FAQ — 批次與串流擷取常見問題

Q1 — 我該如何在 Kinesis Data Streams 和 Kinesis Data Firehose 之間做出選擇？

決策取決於三個因素：延遲、自定義取用者程式碼以及目的地靈活性。當延遲需求為亞秒級、當您需要自定義取用者邏輯（篩選、豐富、根據不同規則分支到多個目的地）或當您需要長時間保留（長達 365 天）時，請選擇 Kinesis Data Streams。當 60 秒以上的延遲可以接受、當目的地是 S3/Redshift/OpenSearch/HTTP 且您不想編寫取用者程式碼，以及當您想要受管緩衝、格式轉換（JSON 到 Parquet）和動態分區時，請選擇 Kinesis Data Firehose。DEA-C01 考試反覆測試這種區別 — 請先看延遲需求，然後再做選擇。

Q2 — Lambda 什麼時候不適合用於資料擷取？

當滿足以下任何一項時，Lambda 就不適合：處理時長超過 15 分鐘（Lambda 硬性超時）；記憶體需求超過 10 GB；承載量同步超過 6 MB 或非同步超過 256 KB；工作負載是持續的高處理量（此時按碎片或按 DPU 的成本優於按次呼叫的成本）；或者取用者需要跨呼叫的粘性狀態（Lambda 是無狀態的）。對於長時間運行的 ETL，請使用 Glue 或 EMR。對於極高處理量的串流，請使用具有 Flink 的 Kinesis。對於輕量級的事件驅動微型任務，Lambda 仍是正確選擇。

Q3 — 微批次和串流有什麼區別？

微批次使用批次工具處理小塊資料（60 秒到幾分鐘） — 如 Glue Streaming 作業、Spark Structured Streaming、排程的 Lambda。串流使用專門構建的串流引擎逐筆記錄（或在微小的每碎片批次中）處理資料 — 如 Kinesis Data Streams + KCL 取用者、MSK 取用者、Managed Flink。微批次的延遲下限是批次間隔（通常為 60 秒）；串流的延遲下限是亞秒級。在維運上，微批次較簡單 — 每批資料作為一個單元成功或失敗，重試語義清晰，等冪性容易實現。串流則較複雜 — 需要處理檢查點、水位線 (watermarks)、晚到資料、恰好一次語義。考試會詢問「近乎即時」加上「最小維運複雜度」指向微批次 (Glue Streaming) 而「即時」加上「具狀態處理」指向 Flink 的情境。

Q4 — 我該如何處理串流管道中的背壓 (Backpressure)？

背壓發生在取用者趕不上生產者時。症狀：Kinesis 中的疊代器生命週期增加、MSK 中的取用者延遲增長、PutRecord 呼叫受限。修復方法取決於瓶頸所在。如果是取用者瓶頸：增加 Lambda 並行度、增加 Flink 並行化、擴展 KCL 工作節點或使用增強型扇出以實現並行取用者路徑。如果是串流瓶頸：增加碎片 (KDS)、增加分區 (MSK) 或切換到按需容量。如果是生產者突發流量：增加緩衝層（Lambda 前面的 SQS, 作為取用者前面緩衝區的 MSK）。DEA-C01 考試測試考生是否理解疊代器生命週期和取用者延遲是診斷信號 — 先讀取這些信號，然後選擇修復方法。

Q5 — 什麼是恰好一次，為什麼它很難？

恰好一次語義保證每筆記錄即使在重試和故障情況下也只被處理一次。它之所以難，是因為至少一次（大多數串流系統中的預設值）加上取用者崩潰等於重複處理。真正的恰好一次需要等冪操作（取用者可以安全地套用同一記錄兩次而無副作用）或交易協調（取用者和目的地一起提交，或兩者都回滾）。具有 KCL 的 Kinesis 加上去重存放區 (具有序列號的 DynamoDB) 可以近似實現恰好一次。具有 Kafka 交易和等冪生產者的 MSK 在 Kafka 層級提供恰好一次。具有檢查點功能和端到端恰好一次接收端 (S3, Kafka) 的 Managed Flink 為串流處理提供真正的恰好一次。考試設置的情境如「取用者在中途重新啟動，防止重複」 — 答案取決於架構是否具有這些保證。

Q6 — 何時應為批次擷取選擇 AWS Glue 而非 EMR？

當工作負載是標準 ETL（讀取來源、轉換、寫入目標）且沒有特殊框架需求時、當您想要無伺服器且無需管理叢集時、當基於 DPU 的定價符合您的使用情況時，或當您想要與 Glue 資料目錄和資料品質原生整合時，請選擇 Glue。當您需要 Glue 選項之外的自定義 Spark 組態時、當工作負載直接使用 Hive/HBase/Presto/Trino 時、當您需要針對極高體積的長期執行叢集經濟效益時，或當開放資料表格式 (Iceberg, Hudi, Delta Lake) 需要 EMR 的成熟整合時，請選擇 EMR。對於大多數 DEA-C01 情境，Glue 在簡單性和受管維運方面勝出；當需求明確要求自定義 Spark 程式碼或非 Spark 框架時，EMR 勝出。

Q7 — 我該如何選擇推送和拉取擷取模型？

當來源是事件驅動的（IoT, 應用程式事件, S3 PUT 通知）、當您無法控制來源以致無法部署拉取代理程式或當延遲要求來源立即遞送時，請使用推送 (Push)。當來源具有穩定的 API (SaaS, RDBMS)、當您控制排程或當批次可以接受時，請使用拉取 (Pull)。DEA-C01 考試詢問的情境如「每天從 Salesforce 擷取」(pull, AppFlow)、「對 S3 上傳做出反應」(push, S3 事件通知 + Lambda) 或「從本地部署 Kafka 串流」(push, MSK Connect 或自我管理連接器)。辨識來源類型可以快速指向擷取模型。

延伸閱讀 — 官方 AWS 文件

批次與串流擷取模式的權威 AWS 來源包括：Build Modern Data Streaming Architectures on AWS 白皮書（涵蓋 Kinesis, MSK, Flink, 扇入/扇出, 即時對比近乎即時的區別）；Storage Best Practices for Data and Analytics Applications 白皮書（涵蓋擷取方法, S3 生命週期, 資料湖模式）；Big Data Analytics Options on AWS 白皮書（涵蓋 Glue, Athena, Redshift, EMR, MSK 服務比較）；AWS Glue Best Practices 白皮書（涵蓋 Glue ETL 維運模式, 作業書籤, 分區處理）；Kinesis Data Streams 開發人員指南；Amazon Data Firehose 開發人員指南；AWS Glue 開發人員指南；以及 AWS DMS 使用者指南。

AWS 大數據部落格有多篇關於擷取架構決策、Lambda 架構對比 Kappa 架構以及真實客戶案例研究的文章。AWS Well-Architected Data Analytics Lens 深入涵蓋了資料擷取支柱。Skill Builder 課程 Exam Prep Standard Course: AWS Certified Data Engineer – Associate (DEA-C01) 有一個網域 1 模組，透過動手實作情境講解了每種擷取服務。最後，AWS 解決方案庫提供了串流分析、即時欺詐偵測和批次 ETL 管道的參考架構，這些架構直接對應到 DEA-C01 考試情境。