Amazon Kinesis Data Streams 與 Firehose

Amazon Kinesis Data Streams 是 AWS 上的核心即時串流服務，Amazon Data Firehose 則是與其搭配的受管交付夥伴。在 AWS Certified Developer Associate（DVA-C02）考試的 Task Statement 1.1（開發託管於 AWS 的應用程式程式碼）中，考題會測試你能否在 Amazon Kinesis Data Streams 與 Amazon SQS 之間做出正確選擇、在不讓生產者遭到節流的前提下設定 shard 容量、撰寫能正確 checkpoint 的 KCL 消費者，以及透過 Amazon Data Firehose 將擷取的記錄交付至 Amazon S3、Amazon Redshift、Amazon OpenSearch Service 或 Splunk。Amazon Kinesis Data Streams 在每份 DVA-C02 考卷中至少出現三個情境題，而 Amazon Kinesis Data Streams vs Amazon SQS vs Amazon EventBridge 的決策矩陣，是 Domain 1 中單一最高價值的記憶重點。

本學習指南涵蓋 DVA-C02 範圍內所有 Amazon Kinesis Data Streams 概念：shard 與每秒 1 MB（或 1000 筆記錄）的寫入限制、每秒 2 MB 的讀取限制、partition key 與熱 shard 設計、On-Demand 與 Provisioned 容量模式、24 小時至 365 天的保留期、消費者的擴增扇出（enhanced fan-out）、具備聚合與壓縮功能的 Kinesis Producer Library（KPL）、使用 Amazon DynamoDB checkpoint 與租約的 Kinesis Client Library（KCL）、用於日誌檔案的 Amazon Kinesis Agent、Amazon Data Firehose 目的地（Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、HTTP 端點）搭配緩衝、Lambda 轉換、動態分區與 Apache Parquet / Apache ORC 轉換、用於串流 SQL 的 Amazon Managed Service for Apache Flink（前身為 Kinesis Data Analytics）、透過 SplitShard 與 MergeShards 進行 resharding，以及搭配指數退避的 ProvisionedThroughputExceededException 處理。預計整份考卷將有 6 到 10 題與這些 Amazon Kinesis Data Streams 主題相關。

Amazon Kinesis Data Streams 與 Firehose 是什麼？

Amazon Kinesis Data Streams 是一個無伺服器、耐久、有序、支援重播的串流服務。生產者寫入記錄，消費者讀取記錄，Amazon Kinesis Data Streams 在可設定的保留視窗內儲存每筆記錄（預設 24 小時，可延長至 365 天），任何消費者都能倒轉並重新讀取。Amazon Kinesis Data Streams 是現代 AWS 應用程式的即時神經系統：點擊流管線、IoT 遙測、日誌聚合、金融即時報價資料，以及來自 Amazon DynamoDB Streams 的變更資料捕獲（CDC），都透過 Amazon Kinesis Data Streams 流通。

Amazon Data Firehose（前身為 Amazon Kinesis Data Firehose）是 Amazon Kinesis Data Streams 的零程式碼兄弟服務。它接收一串記錄，交付至你選擇的目的地——Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、Snowflake 或一般 HTTP 端點——並可選用緩衝、AWS Lambda 轉換、動態分區，以及轉換為 Apache Parquet 或 Apache ORC。Amazon Data Firehose 屬於近即時（最短 60 秒緩衝，典型為 1 到 5 分鐘），而 Amazon Kinesis Data Streams 是真正的即時（擴增扇出消費者可達次秒級）。

Amazon Managed Service for Apache Flink（即更名後的 Kinesis Data Analytics）建立在 Amazon Kinesis Data Streams 之上，用來執行串流 SQL 與 Apache Flink 應用程式，適合視窗聚合、異常偵測及串流對串流的 join。

這三項服務共同構成 AWS 串流三角：Amazon Kinesis Data Streams 負責擷取、Amazon Managed Service for Apache Flink 負責處理、Amazon Data Firehose 負責交付。

Amazon Kinesis Data Streams 對 DVA-C02 的重要性

DVA-C02 Domain 1（使用 AWS 服務進行開發）佔考試比重 32%。Task Statement 1.1 明確列出「將應用程式與資料整合至適當的 AWS 服務（例如 Amazon SQS、Amazon SNS、Amazon Kinesis、Amazon EventBridge）」。V2.1 考試指南（2024 年 12 月 12 日）持續強調有序串流、重播語意與 Lambda 消費者。每道提到「即時」、「點擊流」、「次秒級」、「多個獨立消費者」或「重播 7 天」的情境題，都在指向 Amazon Kinesis Data Streams。

白話文解釋

Amazon Kinesis Data Streams 聽起來令人生畏，但三個直覺類比就能讓你豁然開朗。

類比一——捷運月台閘門

把 Amazon Kinesis Data Streams 想像成台北捷運的月台閘門系統。

• Shard 是月台上一道道的閘門通道。每道通道每秒最多能讓 1 MB 的旅客資料通過，或 1000 名旅客刷卡，以先到者為準。出站（讀取）速度更快，每道通道每秒最多 2 MB。
• Partition key 是旅客的悠遊卡 ID。閘門機器（Amazon Kinesis Data Streams）對卡號做 hash，把旅客導向固定的通道。同一張卡永遠走同一道閘門，這就是 Amazon Kinesis Data Streams 保持每位使用者、每台 IoT 裝置有序性的方式。
• 保留期 是系統保存刷卡記錄的時間。預設 24 小時，最長可保留 365 天，讓你回頭重播歷史記錄。
• 消費者 是出口端的查閱人員。標準查閱人員與所有其他人共用每道通道 2 MB/s 的讀取額度（最多五人共用）。擴增扇出查閱人員則擁有專屬管道，獨享完整的 2 MB/s，延遲低於 200 毫秒。
• Amazon Data Firehose 是月台末端的自動打包站：所有出站旅客資料被打包（緩衝），視需要重新整理（Lambda 轉換），再配送至倉庫（Amazon S3）、冷凍庫（Amazon Redshift）、口味索引（Amazon OpenSearch Service）或快遞員（Splunk 或 HTTP 端點）。

若考題說「次秒級延遲給自訂消費者」，選擇具擴增扇出的 Amazon Kinesis Data Streams 專用通道。若說「不寫程式就把記錄丟進 Amazon S3」，選擇 Amazon Data Firehose。

類比二——郵件分揀中心

Amazon Kinesis Data Streams 是一座郵件分揀中心。

• 生產者（Kinesis Producer Library、Kinesis Agent、AWS SDK 客戶端）是把信件卸貨到裝卸月台的郵務車。
• Partition key 是信封上的郵遞區號。中心對郵遞區號做 hash，將信件導入數條分揀線（shard）中的其中一條。
• Sequence number 是分揀機器蓋在每封信上的戳記時間戳，在同一個 shard 內單調遞增。
• Checkpoint 是郵務員休息前在架子上留下的最後讀取標記。回來後從標記處繼續——這正是 Kinesis Client Library（KCL）寫入 Amazon DynamoDB checkpoint 表格的運作方式。
• Lease 是中心發給每位郵務員的夾板：「你負責這條分揀線，直到你放下夾板為止。」若郵務員當機，另一位撿起夾板繼續作業。
• Amazon Data Firehose 是負責最後一哩路的社區郵差，零程式碼就能完成交付。

每道 Amazon Kinesis Data Streams 題目都能對應到這張圖。「熱 shard」就是某個郵遞區號的信件量是其他區的十倍。「Resharding」就是拆分或合併分揀線。

類比三——瑞士刀

Amazon Kinesis 是一把三刀片瑞士刀。

• 長刀片是 Amazon Kinesis Data Streams——你自己決定怎麼切、讓幾個消費者盯著，以及保留歷史多久。
• 開瓶器是 Amazon Data Firehose——為一項任務預先成型（交付）。轉一下，資料就落進 Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、Snowflake 或 HTTP。
• 剪刀是 Amazon Managed Service for Apache Flink——用 SQL 或 Java Apache Flink 程式碼，在即時串流上剪出預設模式（視窗聚合、異常偵測）。

若情境只說「交付到 Amazon S3 或 Amazon Redshift」，不要拿長刀片——開瓶器就夠了。

Amazon Kinesis Data Streams 架構——Shard、Partition Key、Sequence Number

Amazon Kinesis Data Streams 將記錄儲存在 shard 中。Shard 是 Amazon Kinesis Data Streams 的基本容量單位，理解 shard 合約是 DVA-C02 這個主題中最重要的事情。

Shard 容量（請精確記憶）

每個 shard，Amazon Kinesis Data Streams 保證：

• 寫入：每秒 1 MB 或每秒 1000 筆記錄，以先到達限制者為準。
• 讀取（傳統）：每秒 2 MB，由該 shard 上的所有標準消費者共用，每個 shard 每秒最多呼叫 5 次 GetRecords。
• 讀取（擴增扇出）：每個消費者專屬每秒 2 MB，不共用，透過 SubscribeToShard 推送，延遲低於 200 毫秒。

超過任何一項寫入限制，生產者就會看到 ProvisionedThroughputExceededException。傳統消費者超過讀取限制，會從 GetRecords 收到 ProvisionedThroughputExceededException，或在 CloudWatch 看到 ReadProvisionedThroughputExceeded。

Partition key——路由函式

每次對 Amazon Kinesis Data Streams 呼叫 PutRecord 都必須帶一個 partition key（UTF-8 字串，最長 256 字元）。Amazon Kinesis Data Streams 對 partition key 執行 MD5 hash，將產生的 128 位元整數對應至恰好一個 shard 所擁有的 hash key 範圍。相同 partition key 的所有記錄會依序落在同一個 shard 上。

Partition key 是你對每個 key 有序性的契約。若應用程式需要使用者 u-123 或感測器 iot-abc 的所有事件按序處理，請用使用者 ID 或感測器 ID 作為 partition key。切勿對高流量生產者使用固定 partition key（如 "default"）——所有記錄都會落在同一個 shard 上，形成永久熱 shard，無論你配置幾個 shard，整條串流都被限制在 1 MB/s。

Sequence number——排序令牌

Amazon Kinesis Data Streams 為每次成功的 PutRecord 指派一個以 shard 為範圍、單調遞增的 sequence number。Sequence number 並非跨 shard 的全域唯一值——它只在 shard 內部有序。消費者使用 sequence number 進行：

• Checkpoint（在當機後從 sequence number X 恢復）。
• 以 AT_SEQUENCE_NUMBER、AFTER_SEQUENCE_NUMBER、TRIM_HORIZON（最舊）或 LATEST（最新）呼叫 GetShardIterator。
• 當生產者重試時去重（相同應用程式資料，不同 sequence number——生產者端的冪等性是生產者自己的責任）。

容量模式——On-Demand 與 Provisioned

Amazon Kinesis Data Streams 提供兩種容量模式，選擇正確模式是 DVA-C02 常見的情境題。

Provisioned 模式

你預先指定 shard 數量，依 shard 小時數加上 PUT payload 單位計費，流量成長時需手動 reshard。最適合：

• 流量可預測且穩定。
• 成本敏感且能估算容量。
• 需要精細控制 partition key 分布。

On-Demand 模式

Amazon Kinesis Data Streams 自動擴縮 shard 容量以符合觀測到的流量，預設上限為每條串流每秒 200 MB 寫入與每秒 400 MB 讀取（可申請提高）。依寫入 GB 數及讀取 GB 數計費，無需呼叫 reshard API。最適合：

• 流量突發或無法預知。
• 重視零維運負擔勝過每 GB 成本。
• 正在建立新應用程式且希望快速上線。

同一條串流每 24 小時最多可在兩種模式間切換兩次。

保留期——預設 24 小時，最長 365 天

Amazon Kinesis Data Streams 在可設定的期間內保留每筆記錄，延伸保留是 DVA-C02 喜歡出的陷阱題。

• 預設保留期：24 小時。
• 延伸保留：標準定價最長 7 天，長期保留定價最長 365 天。

保留期有三個重要意義：

1. 重播：任何消費者都能將迭代器重設至 TRIM_HORIZON，重新處理視窗內的所有記錄。適合為新的下游消費者進行回填。
2. 災難復原：若 Lambda 消費者當機兩天，延伸保留給你時間修復並重播。
3. 合規：長期保留讓你保存不可竄改的附加專用事件歷史，無需複製到 Amazon S3。

生產者——SDK、Kinesis Producer Library 與 Kinesis Agent

Amazon Kinesis Data Streams 在 DVA-C02 中接受三種主要生產者路徑的寫入。

AWS SDK——PutRecord 與 PutRecords

直接 SDK 呼叫。PutRecord 一次寫入一筆記錄；PutRecords 每次呼叫最多批次寫入 500 筆記錄或 5 MB。當應用程式自行管理緩衝、在 AWS Lambda 內部（不建議使用長時間運行的 KPL 背景執行緒），或需要精細控制 partition key 與 sequence number 時，使用 SDK。

Kinesis Producer Library（KPL）——批次、壓縮、非同步

KPL 是一個非同步的 C++ 包裝函式庫（含 Java 與 Python 綁定），介於你的應用程式與 Amazon Kinesis Data Streams 之間。KPL 提供四項 SDK 呼叫端無法免費取得的重要功能：

• 聚合（Aggregation）：將許多小的使用者記錄合併成一筆 Amazon Kinesis Data Streams 記錄（最多 1 MB）。大幅降低 PUT payload 單位費用並獲得巨大的吞吐量提升。
• 批次（Batching）：自動將聚合後的記錄組成 PutRecords 呼叫。
• 退避重試：若某個 shard 被節流，KPL 透明地重試。
• CloudWatch 指標：內建每條串流與每個 shard 的指標。

下游消費者必須使用 Kinesis Client Library（KCL）來解聚合KPL 寫入的記錄，還原成使用者記錄——這個 KPL-KCL 配對是 DVA-C02 最愛測試的知識點。

Amazon Kinesis Agent——日誌檔案傳送至 Amazon Kinesis Data Streams

Amazon Kinesis Agent 是一個預先建置的 Java 常駐程式，在 Linux 伺服器上追蹤日誌檔案並將其寫入 Amazon Kinesis Data Streams 或 Amazon Data Firehose。支援 CSV 轉 JSON、多行模式、檔案輪替與至少一次交付。當你希望點擊流或網頁伺服器日誌不需撰寫自訂生產者程式碼就能流入 Amazon Kinesis Data Streams 時，使用 Amazon Kinesis Agent。

生產者錯誤處理——ProvisionedThroughputExceededException 與退避

這是 DVA-C02 中測試最頻繁的 Amazon Kinesis Data Streams 錯誤處理情境。

當生產者在某個 shard 上超過每秒 1 MB 或 1000 筆記錄時，API 回傳 ProvisionedThroughputExceededException（HTTP 400，錯誤碼 ProvisionedThroughputExceededException）。SDK 與 KPL 都會自動重試，但正確的開發者回應是分層處理：

1. 指數退避加抖動（Exponential backoff with jitter），從 100 ms 開始，每次重試加倍，上限幾秒，並加入隨機抖動，避免所有生產者同步重試。
2. 重新評估 partition key 分布。若某個 partition key 讓單一 shard 過熱，光是 reshard 無濟於事——需要換一個更好的 key。
3. Reshard（拆分熱 shard）以增加寫入容量。
4. 切換至 On-Demand 模式，若節流持續發生。
5. 使用 KPL，它已內建退避加聚合，實務上能消除大部分節流。

SDK 在達到設定的重試次數後會放棄；應用程式程式碼負責提供死信路徑（Amazon SQS、Amazon S3 或本機磁碟緩衝），確保記錄不會被靜默丟棄。

消費者——傳統與擴增扇出

Amazon Kinesis Data Streams 支援兩種消費者風格，其差異驅動著關於延遲與多消費者隔離的考題。

傳統（共用吞吐量）消費者

• 使用 GetRecords 拉取 API。
• 同一個 shard 上所有已註冊的傳統消費者共用 2 MB/s 讀取額度。
• 每個 shard 每秒最多 5 次 GetRecords 呼叫的硬性上限。
• 輪詢延遲：通常 200 毫秒到 1 秒。
• 費用低廉，無每消費者費用。
• 建議每個 shard 最多 1 到 2 個傳統消費者，超過 5 個後每個消費者都受害。

擴增扇出消費者

• 使用 SubscribeToShard HTTP/2 推送 API。
• 每個已註冊的消費者對每個 shard 獲得專屬 2 MB/s 讀取管道。
• 傳播延遲低於 200 毫秒。
• 每條串流最多 20 個擴增扇出消費者（預設配額）。
• 按消費者-shard-小時數及交付 GB 數額外收費。

Kinesis Client Library（KCL）——有狀態消費者與 Checkpointing

Kinesis Client Library（KCL）是為 Amazon Kinesis Data Streams 建立有狀態消費者的建議方式。KCL 解決了原始 SDK 無法處理的三個難題。

透過 Amazon DynamoDB 進行租約協調

KCL 建立一個 Amazon DynamoDB 表格（以你的應用程式命名），每個 shard 以一個租約表示。工作者程序以合作方式競爭租約：

• 一個工作者一次擁有一個 shard 租約。
• 租約以心跳間隔更新。
• 若工作者當機，其租約過期，另一個工作者接管。
• 當你增加工作者實例時，KCL 自動重新平衡租約。

透過 Amazon DynamoDB 進行 Checkpointing

KCL 將最後一個成功處理的 sequence number 記錄至同一個 Amazon DynamoDB 表格。當機或部署後，新的租約持有者從最後一個 checkpoint 恢復，提供至少一次的處理語意。

你必須在 record processor 中顯式呼叫 checkpointer.checkpoint()——通常是在一批記錄寫入下游儲存後。過度 checkpoint 會傷害 Amazon DynamoDB 的 WCU；checkpoint 頻率不足則在復原時增加重新處理量。

解聚合與關閉勾點

KCL 自動解聚合 KPL 聚合的記錄，在你的 record processor 上呼叫 initialize、processRecords 與 shutdown（resharding 後 shard 結束時以 TERMINATE 為原因，租約遺失時以 ZOMBIE 為原因），並提供錯誤處理原語。

AWS Lambda 作為 Kinesis 消費者——Batch Size、Bisect on Error、平行化因子

AWS Lambda 是無伺服器架構中最常見的 Amazon Kinesis Data Streams 消費者。Lambda 事件來源映射代你輪詢串流，並以一批記錄呼叫你的函式。

Batch size 與 batch window

• BatchSize：每次 Lambda 呼叫 1 到 10,000 筆記錄（預設 100）。
• MaximumBatchingWindowInSeconds：0 到 300 秒。Lambda 最多等待此時間以積累完整批次。

兩者搭配調校。大批次加長視窗能最大化吞吐量並最小化呼叫成本，但會提高端對端延遲，以及單次呼叫的爆炸半徑。

平行化因子

• ParallelizationFactor：1 到 10。將一個 shard 分割為最多 10 個並行的 Lambda 呼叫，保留每 partition key 的有序性，同時移除每個 shard 只有一個 Lambda 的瓶頸。

發生錯誤時對半分割批次

• BisectBatchOnFunctionError：true 或 false。發生錯誤時，Lambda 將失敗批次對半並重試，以 O(log n) 次呼叫隔離毒丸記錄，而非永遠重試整個批次。

ReportBatchItemFailures

從 Lambda 回應中回傳 batchItemFailures 清單，標識失敗的特定記錄 sequence number；Lambda 會 checkpoint 略過成功的記錄，只重試失敗的記錄，消除因單一記錄錯誤導致的完整批次重播。

起始位置與重試限制

• StartingPosition：TRIM_HORIZON（最舊）、LATEST（最新）或 AT_TIMESTAMP。
• MaximumRetryAttempts：-1（無限）到 10,000。
• MaximumRecordAgeInSeconds：60 到 604,800。超過此時間的記錄會被丟棄略過。
• OnFailure 目的地：用於耗盡重試次數的記錄，可指向 Amazon SNS 或 Amazon SQS。

Resharding——拆分與合併 Shard

隨著流量成長或縮減，你可以透過 resharding 來重新調整 Amazon Kinesis Data Streams（在 Provisioned 模式下）的 shard 結構。

SplitShard

將一個父 shard 拆分成兩個子 shard。使用拆分來：

• 讓某個熱 shard 的寫入容量加倍。
• 重新分布集中的 partition key 範圍。

拆分後父 shard 立即關閉。父 shard 上的既有記錄在保留期屆滿前仍可讀取；符合父 shard hash key 範圍任一半的新記錄流入兩個新子 shard。

MergeShards

將兩個相鄰的父 shard 合併成一個子 shard。使用合併來：

• 流量下降時降低成本。
• 爆量過後簡化串流結構。

只有 hash key 範圍相鄰的 shard 才能合併。

Resharding 生命週期規則

• 父 shard 變為 CLOSED，最終變為 EXPIRED（保留期後）。
• 消費者必須先排空父 shard 才能移至子 shard——KCL 自動處理此過程。
• Resharding 是控制平面操作；預期需要 30 秒到幾分鐘容量才會穩定。
• 將多次拆分合併成一次 resharding 行動，避免反覆震盪。

UpdateShardCount——快速通道

UpdateShardCount 可將整條串流擴縮至新的目標 shard 數量，無需手動進行拆分或合併的協調作業。支援每次呼叫最多擴增至兩倍或縮減至一半的當前數量，並受每日限制約束。

Amazon Data Firehose——零程式碼交付至 S3、Redshift、OpenSearch、Splunk 與 HTTP

Amazon Data Firehose 是串流資料的受管零程式碼交付管線。它緊鄰 Amazon Kinesis Data Streams 或接受直接 PUT，並以緩衝、可選轉換與可選格式轉換的方式，將記錄落地至下游系統。

來源

• Direct PUT：你的生產者直接呼叫 Amazon Data Firehose 的 PutRecord 或 PutRecordBatch API。
• Amazon Kinesis Data Streams：Firehose 讀取現有的 Amazon Kinesis Data Streams 作為來源。
• Amazon MSK：Firehose 從 Amazon Managed Streaming for Apache Kafka 讀取。
• AWS IoT、CloudWatch Logs、CloudWatch Events：原生整合。

目的地（DVA-C02 核心清單）

• Amazon S3——最常見的目的地。Firehose 以可設定的前綴寫入物件。
• Amazon Redshift——Firehose 先寫至 Amazon S3，再對 Amazon Redshift 叢集發出 COPY 命令。
• Amazon OpenSearch Service——Firehose 將記錄交付至 Amazon OpenSearch Service 網域索引，並同步備份至 Amazon S3。
• Splunk——Firehose 交付至 Splunk 的 HTTP Event Collector（HEC）端點。
• HTTP 端點——任何 HTTPS 端點（Datadog、New Relic、MongoDB、Sumo Logic、Coralogix 等）。
• Snowflake——原生 Snowflake 擷取。

緩衝——近即時的代價

Amazon Data Firehose 緩衝記錄，直到達到大小閾值或時間閾值，以先達到者為準。

• 緩衝大小：1 MB 到 128 MB（因目的地而異）。
• 緩衝間隔：60 秒到 900 秒。

最短端對端延遲即為緩衝間隔，這就是 Amazon Data Firehose 屬於「近即時」而非即時的原因。若需要次秒級延遲，請使用 Amazon Kinesis Data Streams 搭配直接消費者。

Lambda 轉換

將 AWS Lambda 函式附加至 Amazon Data Firehose，每個緩衝的記錄批次在交付前都會通過該函式。典型轉換包括：

• JSON 重塑、資料豐富、個人資料（PII）遮蔽。
• CSV 轉 JSON。
• 以 ProcessingFailed 結果過濾錯誤。

Firehose 自動將轉換失敗的記錄傳送至獨立的 Amazon S3 錯誤前綴以供重播。

動態分區

動態分區讓 Amazon Data Firehose 能從記錄內容本身推導 Amazon S3 前綴，使用 JQ 風格的運算式或 Lambda 函式。例如：依 customer_id 與 event_date 分區，讓 Amazon Athena 能剪枝 Amazon S3 讀取。動態分區在串流建立時啟用，之後無法切換。

格式轉換——Apache Parquet 與 Apache ORC

Amazon Data Firehose 可將傳入的 JSON 記錄轉換為 Apache Parquet 或 Apache ORC，並參照 AWS Glue Data Catalog 結構描述。這是 DVA-C02 最具考試價值的 Amazon Data Firehose 功能（僅次於目的地本身）：相較於原始 JSON，Apache Parquet 與 Apache ORC 可將 Amazon Athena 查詢成本及 Amazon Redshift Spectrum 掃描成本降低 5 到 10 倍。

Amazon Managed Service for Apache Flink——在 Amazon Kinesis Data Streams 上執行串流 SQL

Amazon Managed Service for Apache Flink（前身為 Amazon Kinesis Data Analytics）在 Amazon Kinesis Data Streams 或 Amazon MSK 上執行全受管的 Apache Flink 應用程式。DVA-C02 的範疇是認識層級，無需深入了解 Apache Flink 內部原理。

• Apache Flink SQL：以 SQL 對即時串流執行視窗聚合、join 與模式比對。
• 適用於 Java / Scala / Python 的 Apache Flink：完整 Flink DataStream API，用於自訂串流邏輯。
• Studio notebooks：互動式 Apache Zeppelin notebooks，用於探索式串流 SQL。
• 輸出：Amazon Kinesis Data Streams、Amazon Data Firehose、AWS Lambda、Amazon S3。

何時使用 AWS 上的 Apache Flink：

• 即時聚合（每分鐘計數、百分位數）。
• 異常偵測。
• 串流對串流 join。
• 以參考資料豐富記錄。

若情境純粹是「交付至 Amazon S3」，不要使用 Apache Flink——使用 Amazon Data Firehose。若情境是「計算即時 IoT 資料的五分鐘滾動平均值」，答案是 Apache Flink。

Amazon Kinesis Data Streams vs Amazon SQS vs Amazon EventBridge——決策矩陣

這是 DVA-C02 在 Amazon Kinesis Data Streams 主題中最高價值的比較。

DVA-C02 關鍵考試觸發詞：

• 「同一串流的多個獨立消費者」→ Amazon Kinesis Data Streams。
• 「重播 7 天歷史」→ Amazon Kinesis Data Streams。
• 「來自 1000 萬使用者的有序點擊流」→ Amazon Kinesis Data Streams，以使用者 ID 作為 partition key。
• 「解耦訂單生產者與訂單處理器，每筆訂單一則訊息，不需重播」→ Amazon SQS。
• 「將 AWS 服務事件路由至多個目標」→ Amazon EventBridge。

DVA-C02 常見 Amazon Kinesis Data Streams 考試陷阱

七個在每份 DVA-C02 考卷中都會扣分的陷阱。

1. 每個 shard 的 1 MB/s 是寫入，不是讀取。 讀取是每個 shard 2 MB/s（傳統）。搞混就會誤判容量。
2. Amazon Kinesis Data Streams 不存在全域有序。 只有每個 shard 有序。全域有序是 Amazon SQS FIFO 搭配單一訊息群組的情境。
3. 熱 partition key 無法靠增加 shard 解決。 先修正 key，再 reshard。
4. ProvisionedThroughputExceededException 可能來自生產者端寫入限制，也可能來自消費者端讀取限制。 相同的例外名稱，不同的根本原因。
5. Amazon Data Firehose 有緩衝。 若情境堅持次秒級，無論 Amazon Data Firehose 看起來多方便，都是錯誤答案。
6. KPL 生產的記錄需要 KCL 解聚合。 原始 SDK 消費者讀取一筆 KPL 記錄時，會看到一筆記錄，而不是其中包含的 N 筆使用者記錄。
7. 擴增扇出按消費者、per shard、per 小時收費——費用是真實的。 不要預設使用它；在有三個或以上即時消費者時才使用。

使用 CloudWatch 監控 Amazon Kinesis Data Streams

每位 Amazon Kinesis Data Streams 開發者在 DVA-C02 中應設定警報的 CloudWatch 指標精簡清單：

• IncomingBytes、IncomingRecords——寫入量，與 shard 限制比較。
• WriteProvisionedThroughputExceeded——生產者節流計數。
• ReadProvisionedThroughputExceeded——消費者節流計數。
• GetRecords.IteratorAgeMilliseconds——消費者落後多遠（Lambda 消費者健康狀態的金絲雀指標）。
• PutRecord.Latency、GetRecords.Latency——控制平面延遲。

對持續上升的 GetRecords.IteratorAgeMilliseconds 設定警報——若無上限地增長，代表消費者跟不上，需要增加 shard、平行化因子或 Lambda 記憶體。

端對端參考架構

使用 Amazon Kinesis Data Streams 的典型 DVA-C02 生產架構：

1. 擷取：數百萬台 IoT 裝置每秒發布遙測資料。一組行動客戶端透過 SDK 使用 KPL，以 deviceId 作為 partition key。
2. 串流：Amazon Kinesis Data Streams 採 On-Demand 模式，預設保留期 24 小時。
3. 即時消費者（擴增扇出）：
   • AWS Lambda 更新 Amazon DynamoDB 表格中的裝置狀態。
   • Amazon Managed Service for Apache Flink 計算每分鐘滾動平均值。
4. 封存消費者：Amazon Data Firehose 讀取同一條 Amazon Kinesis Data Streams，緩衝 5 分鐘，透過 AWS Glue 結構描述轉換為 Apache Parquet，以 deviceType 與 date 動態分區寫入 Amazon S3。
5. 分析：Amazon Athena 查詢 Apache Parquet 檔案。Amazon Redshift Spectrum 與資料倉儲進行 join。
6. 可觀測性：CloudWatch 對 GetRecords.IteratorAgeMilliseconds 與 WriteProvisionedThroughputExceeded 設定警報。

這個模式是 70% Amazon Kinesis Data Streams DVA-C02 情境題的背後架構。

FAQ：Amazon Kinesis Data Streams 常見問題

1. DVA-C02 中何時應選擇 Amazon Kinesis Data Streams 而非 Amazon SQS？

當情境提到以下任何一點時，選擇 Amazon Kinesis Data Streams：即時串流、多個獨立消費者讀取相同資料、數小時或數天的重播、按 key 有序（partition key），或持續性資料如點擊流、IoT 或 CDC。當情境說解耦、每筆訊息一個工作者、以可見性逾時重試，或跨整個佇列的嚴格 FIFO 有序（Amazon SQS FIFO 搭配單一訊息群組）時，選擇 Amazon SQS。Amazon Kinesis Data Streams 是日誌；Amazon SQS 是佇列。

2. 如何正確處理來自生產者的 ProvisionedThroughputExceededException？

實作指數退避加抖動，從約 100 ms 開始。然後診斷：若錯誤來自部分 partition key，修正 partition key 分布（增加熵或使用更好的 key）。若所有 key 均勻分布且串流已滿載，可呼叫 UpdateShardCount 擴增、以 SplitShard 拆分最熱的 shard，或將串流切換至 On-Demand 模式。最後，在生產者中使用 KPL——KPL 已實作聚合、批次與重試，實務上能消除大部分節流。

3. 一個 shard 上能有超過兩個 Amazon Kinesis Data Streams 消費者而不影響效能嗎？

傳統消費者無法做到。傳統消費者共用每個 shard 2 MB/s 的讀取額度，每個 shard 每秒最多 5 次 GetRecords 呼叫的總計上限。超過兩個傳統消費者，你會觀察到 ReadProvisionedThroughputExceeded 與上升的 GetRecords.IteratorAgeMilliseconds。使用擴增扇出，讓每個已註冊的消費者在每個 shard 上獲得專屬的 2 MB/s 管道與低於 200 毫秒的延遲。擴增扇出每條串流最多支援 20 個消費者（預設配額，可申請提高）。

4. DVA-C02 中 Amazon Data Firehose 與 Amazon Kinesis Data Streams 有何差異？

Amazon Kinesis Data Streams 是即時的，需要你撰寫消費者（AWS Lambda、KCL 應用程式或擴增扇出訂閱者）。它儲存記錄最長 365 天，按 shard 小時數（Provisioned）或每 GB（On-Demand）計費。Amazon Data Firehose 是近即時（60 到 900 秒緩衝）、零程式碼，直接交付至 Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、HTTP 或 Snowflake。Amazon Data Firehose 可呼叫 Lambda 轉換並轉換為 Apache Parquet 或 Apache ORC。若情境要求次秒級延遲或重播，選 Amazon Kinesis Data Streams；若要求不寫程式碼、交付至 S3/Redshift，選 Amazon Data Firehose。兩者常見配對：Amazon Kinesis Data Streams 作為即時來源，Amazon Data Firehose 作為將 Apache Parquet 寫入 Amazon S3 的封存消費者。

5. Lambda 如何避免因單一毒丸記錄而重新處理整個批次？

啟用 BisectBatchOnFunctionError，讓 Lambda 在失敗時將批次對半並重試，以 O(log n) 次呼叫隔離壞記錄。同時從 Lambda 回應中回傳 batchItemFailures，標識失敗的特定記錄 sequence number；Lambda 會 checkpoint 略過成功記錄，只重試失敗的記錄。搭配 MaximumRetryAttempts 與 OnFailure 目的地（Amazon SQS 或 Amazon SNS），確保耗盡重試次數的記錄最終進入死信位置，而非永遠封鎖整個 shard。

6. KCL 在 Amazon DynamoDB 中寫入什麼內容？需要哪些權限？

Kinesis Client Library（KCL）建立一個以你的應用程式命名的 Amazon DynamoDB 表格。每個 shard 有一行，儲存當前租約持有者（哪個工作者擁有該 shard）、租約計數器（用於更新與隔離），以及最後一個 checkpoint sequence number。你的 KCL 應用程式需要 IAM 權限：dynamodb:CreateTable、dynamodb:DescribeTable、dynamodb:GetItem、dynamodb:PutItem、dynamodb:UpdateItem、dynamodb:DeleteItem 與 dynamodb:Scan，以及 kinesis:DescribeStream、kinesis:GetRecords、kinesis:GetShardIterator、kinesis:ListShards、kinesis:SubscribeToShard（用於擴增扇出），和 CloudWatch 的 cloudwatch:PutMetricData。

7. 何時應拆分 shard、合併 shard 或使用 UpdateShardCount？

當某個特定 shard 過熱（hash key 分布不均）且想將其拆成涵蓋各半 hash key 範圍的兩個子 shard 時，使用 SplitShard。當兩個相鄰 shard 使用率都很低且想降低 shard 成本時，使用 MergeShards。當想整條串流擴增或縮減而不需手動協調拆分與合併時，使用 UpdateShardCount——每次呼叫加倍或減半，受每日限制約束。對於無法預測的流量，偏好 On-Demand 模式，讓 AWS 完全管理容量。

8. Amazon Data Firehose 是否支援轉換為 Apache Parquet？為什麼重要？

是的。Amazon Data Firehose 可即時將 JSON 記錄轉換為 Apache Parquet 或 Apache ORC 欄位式格式，並使用 AWS Glue Data Catalog 表格作為結構描述。欄位式格式可將 Amazon Athena 查詢成本降低 5 到 10 倍，並加速 Amazon Redshift Spectrum 掃描。將 Apache Parquet 轉換與動態分區（依日期或客戶分區）組合，以解鎖謂詞下推。在 DVA-C02 中，任何說「降低 Amazon Athena 查詢成本」或「高效的長期分析儲存」的情境，都在暗示透過 Amazon Data Firehose 使用 Apache Parquet。

摘要——DVA-C02 的 Amazon Kinesis Data Streams

Amazon Kinesis Data Streams 是 AWS 有序、可重播、多消費者的串流骨幹。記住五件事，你就能回答 DVA-C02 上的每道 Amazon Kinesis Data Streams 題目。

1. Shard 合約：每秒 1 MB 或 1000 筆記錄寫入，每秒 2 MB 傳統讀取（共用，5 次 GetRecords/s），每消費者擴增扇出每秒 2 MB。
2. Partition key 決定落在哪個 shard；熱 partition key 造成的節流，光靠 resharding 無法解決。
3. KPL + KCL 是生產等級的生產者—消費者配對；KPL 聚合，KCL 解聚合並 checkpoint 至 Amazon DynamoDB。
4. Amazon Data Firehose 是零程式碼近即時交付至 Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、HTTP 與 Snowflake，支援 Lambda 轉換、動態分區及 Apache Parquet / Apache ORC 轉換。
5. Lambda 旋鈕——BatchSize、MaximumBatchingWindowInSeconds、ParallelizationFactor、BisectBatchOnFunctionError、ReportBatchItemFailures、OnFailure 目的地——解決所有 Amazon Kinesis Data Streams Lambda 消費者題目。

掌握 Amazon Kinesis Data Streams vs Amazon SQS vs Amazon EventBridge 決策矩陣，掌握 Amazon Kinesis Data Streams vs Amazon Data Firehose 的邊界（即時 vs 近即時，需要程式碼 vs 零程式碼），Amazon Kinesis Data Streams 就能在 DVA-C02 考試中成為穩定的得分來源。