Kinesis Data Streams、Firehose 與 Amazon MSK

Amazon Kinesis Data Streams、Amazon Data Firehose 以及 Amazon Managed Streaming for Apache Kafka (MSK) 構成了現代 AWS 資料工程架構的串流擷取核心。在 DEA-C01 考試中，它們是領域 1（資料擷取與轉換，權重 34%）中密度最高的主題。來自 Tutorials Dojo、Digital Cloud Training、ExamCert.App 以及流行的 Medium 部落格等社群學習指南都指出了相同的痛點 — 考生容易混淆 Kinesis Data Streams（真正的即時）與 Kinesis Data Firehose（近乎即時），並混淆 MSK（具有完整開源生態系統的託管 Apache Kafka）與 Kinesis（AWS 原生簡單性但無 Kafka API）。在考試中選錯這些服務，就如同在實際生產中做出錯誤選擇：為亞秒級欺詐評分選擇 Firehose，您的模型將無法達到 SLA；當取用者團隊期望 Kafka Connect 連接器時選擇 Kinesis Data Streams，您將不得不從零開始構建連接器生態系統。

本學習筆記從資料工程師的角度出發，涵蓋了 Kinesis 四項服務概述、Kinesis Data Streams 分片與分割區索引鍵、取用者類型與按需模式、KDS 吞吐量計算、Kinesis Data Firehose 傳遞目的地與緩衝及格式轉換、KDS vs Firehose 區別、MSK 佈建 vs 無伺服器模式、用於來源/接收器連接器的 MSK Connect、排序保證、加密與安全，以及最常讓考生失分的典型考試陷阱。讀完本筆記後，您將能以結構化的方式為串流服務選擇做出專業辯護。

什麼是 Amazon Kinesis — 四項服務家族

Amazon Kinesis 是 AWS 串流資料服務的統稱。該家族包含四項不同的服務，DEA-C01 考試將它們作為獨立決策進行測試。

Kinesis Data Streams (KDS)

具備分片 (shards)、自定義取用者、保留期長達 365 天的即時資料流。它是端到端延遲最低（亞秒級）的選項。適用於欺詐評分、即時競價、IoT 警報，以及任何需要執行比單純寫入 S3 更多邏輯的取用者程式碼情境。

Kinesis Data Firehose (現更名為 Amazon Data Firehose)

託管傳遞流，可將資料寫入 S3、Redshift、OpenSearch、HTTP 端點、Splunk 和 Snowflake。在傳遞前按大小或時間緩衝記錄。僅限近乎即時 (near-real-time)（60-900 秒緩衝）。適用於日誌封存、分析目的地載入，以及任何託管傳遞優於自定義取用者程式碼的情境。

Amazon Managed Service for Apache Flink (前稱 Kinesis Data Analytics)

用於具狀態串流處理的託管 Flink — 涵蓋視窗化、彙總、聯接、模式檢測。讀取自 KDS 和 MSK；寫入 S3、Redshift、OpenSearch。詳情請參閱 kinesis-managed-flink-stream-processing 主題。

Kinesis Video Streams

專用於攝影機、IoT 影片和機器學習影片分析的影片流。DEA-C01 考試不會深入測試此項 — 只需認得名稱即可。

Kinesis Data Streams — 分片與分割區索引鍵

Kinesis Data Streams 是基礎的即時服務。透徹理解分片是考試的必備條件。

什麼是分片 (Shard)

分片是 Kinesis Data Stream 的容量單位。每個分片支持 1 MB/s 或每秒 1000 條記錄的寫入，以及 2 MB/s 的讀取（由該分片的所有標準取用者共享）。一個資料流由一個或多個分片組成；吞吐量隨分片數量線性擴展。

分割區索引鍵 (Partition Key) — 將記錄路由到分片

當生產者調用 PutRecord 時，它會提供一個分割區索引鍵。Kinesis 對分割區索引鍵執行雜湊運算 (MD5)，並將記錄路由到雜湊範圍包含該結果的分片中。具有相同分割區索引鍵的記錄始終會落在同一個分片上，這保證了索引鍵內的順序。請選擇高基數 (high cardinality) 的分割區索引鍵 — 使用「國家/地區」等只有 200 個值但對應數百萬使用者的低基數鍵會建立熱分片 (hot shards)，導致所有美國流量都擁擠在一個分片上。

保留期 (Retention Period)

預設保留期為 24 小時。您可以免費延長至 7 天，或付費延長至長達 365 天（長期保留）。長保留期對於重播情境、遲到的取用者以及串流資料的合規性封存非常有用。

序號 (Sequence Numbers) 與反覆運算子類型 (Iterator Types)

分片中的每條記錄都有一個單調遞增的序號。取用者使用序號追蹤其位置，並通過分片反覆運算子請求記錄。反覆運算子類型包括：TRIM_HORIZON（保留期內最舊的記錄）、LATEST（僅新記錄）、AT_SEQUENCE_NUMBER、AFTER_SEQUENCE_NUMBER、AT_TIMESTAMP。DEA-C01 考試會測試「取用者離線一小時，如何恢復」 — 答案是記錄上次處理的序號檢查點，並使用 AFTER_SEQUENCE_NUMBER 恢復。

KDS 吞吐量 — 每分片限制與擴展

吞吐量計算對考試至關重要。

寫入限制

每個分片：每秒 1 MB 或每秒 1000 條記錄（以先達到者為準）。超過任一限制都會觸發 ProvisionedThroughputExceededException，生產者應執行退避重試。就吞吐量而言，PutRecords（批次）比 PutRecord（單筆）更有效率。

讀取限制

每個分片，標準取用者：每秒 2 MB 或每秒 5 次 GetRecords 調用，由讀取該分片的所有標準取用者共享。每個分片，增強型展開 (EFO) 取用者：每位取用者每秒 2 MB，傳播延遲低於 200 毫秒。當有超過兩位取用者讀取同一資料流時，EFO 是正確答案。

分片分割 (Splitting) 與合併 (Merging)

要增加吞吐量，請將一個分片分割為兩個子分片（各獲得原始雜湊範圍的一半）。要減少吞吐量並節省成本，請將兩個相鄰分片合併為一個。兩者都是在線操作 — 原始分片在保留期內仍可讀取（以便取用者完成處理在途資料），但在分割/合併後不接受新寫入。

按需容量模式 (On-Demand Capacity Mode)

按需模式根據觀察到的吞吐量自動擴展分片數量，預設最高可達 200 MB/s 寫入或每秒 200,000 條記錄（可延長）。您按擷取的 GB 數和檢索的 GB 數付費，而不是按分片小時付費。適用於不可預測的工作負載、原型開發以及避免容量規劃。對於持續可預測的吞吐量，佈建模式更便宜。

Kinesis Data Firehose — 託管傳遞至 S3 及更多目的地

Firehose 是無需編碼的託管傳遞選項。

支援的目的地

S3（最常見）、Amazon Redshift（通過 S3 暫存加 COPY 命令）、Amazon OpenSearch Service、HTTP 端點（可選配合 API Gateway）、Splunk、Datadog、MongoDB Atlas、New Relic 以及 Snowflake。每個目的地都有其特定的配置（Redshift 叢集憑證、OpenSearch 索引名稱、HTTP 端點 URL）。

緩衝提示 (Buffering Hints)

記錄在傳遞前會先緩衝。緩衝大小：1-128 MB（預設 5 MB）。緩衝間隔：60-900 秒（預設 300 秒）。以先達到者為準觸發傳遞。最小 60 秒的緩衝是端到端延遲的底線，這就是為什麼 Firehose 僅限近乎即時。

格式轉換 (Format Conversion)

Firehose 可以在傳遞過程中，使用 Glue 資料目錄表作為結構描述，將記錄從 JSON 轉換為 Parquet 或 ORC 格式。Parquet 和 ORC 是欄式格式，下游的 Athena 和 Redshift Spectrum 查詢掃描效率更高。格式轉換會增加每 GB 的費用，但能顯著節省下游查詢成本。

動態分割 (Dynamic Partitioning)

Firehose 可以根據每條記錄中的欄位值，動態地將傳遞的記錄分割到不同的 S3 前綴中。例如：將記錄傳遞到 s3://bucket/year=2026/month=05/day=02/customer_segment=A/。動態分割改善了 Athena 的分割區剪枝 (partition pruning) 並降低了查詢掃描成本。按處理的 GB 數計費。

緩衝錯誤與備份

Firehose 可以配置為在轉換前將來源記錄備份到單獨的 S3 儲存桶，這在下游傳遞失敗時對於重播非常有用。失敗的記錄（重試後）會落在錯誤的 S3 前綴中。

KDS vs Firehose — 決策速查表

考試會反覆測試此對比。請記住這些區別。

延遲 (Latency)

KDS：亞秒級端到端，使用自定義取用者。Firehose：至少 60 秒以上。

自定義程式碼

KDS：需要取用者程式碼（Lambda、KCL、Flink、Spark Streaming 等）。Firehose：無需取用者程式碼，只需配置目的地。

目的地

KDS：任何您可以編寫取用者程式碼的地方。Firehose：S3、Redshift（通過 S3）、OpenSearch、HTTP、第三方 SaaS。

定價模型

KDS：按分片小時加每百萬次 PUT 記錄計費（佈建模式），或按擷取 GB 數加檢索 GB 數計費（按需模式）。Firehose：按擷取 GB 數計費，格式轉換、動態分割和 VPC 傳遞需額外收費。

保留期 (Retention)

KDS：預設 24 小時，最高 365 天。Firehose：無保留期（記錄流經 Firehose，不存儲在其中）。

重播 (Replay)

KDS：支持，通過將反覆運算子設定為 TRIM_HORIZON 或 AT_TIMESTAMP。Firehose：不支持重播；記錄取用一次即傳遞。

使用案例

KDS：即時欺詐檢測、IoT、推薦系統，任何具有自定義取用者邏輯的地方。Firehose：日誌封存、分析倉庫載入、OpenSearch 索引編製、第三方 SaaS 整合。

KDS 擴展 — 分割、合併與按需模式

操作 Kinesis Data Stream 意味著手動管理分片或讓 AWS 自動管理。

手動重新分片 (Manual Resharding)（佈建模式）

操作員運行 SplitShard 來加倍分片的容量（建立兩個子分片，每個涵蓋父分片一半的雜湊範圍），或運行 MergeShards 來減半成本（合併兩個相鄰分片）。手動重新分片需要監控 CloudWatch 指標（IncomingBytes、IncomingRecords、WriteProvisionedThroughputExceeded），並在生產者開始限流前做出反應。

按需模式 (On-Demand Mode) — 免動手擴展

按需模式在持續流量超過容量時自動加倍分片數量，預設最高可達帳戶上限 200 MB/s。無需手動管理分片。您按量計費（以 us-east-1 基準定價：擷取每 GB $0.04，檢索每 GB $0.04）。當流量不可預測、團隊沒有精力監控和重新分片，或原型工作負載不值得進行容量規劃時，按需模式是正確答案。

佈建模式 vs 按需模式的成本權衡

佈建模式：按分片小時計費（us-east-1 為 $0.015/時）加每百萬次 PUT（$0.014）。對於持續可預測的吞吐量更便宜。按需模式：按 GB 計費。對於突發性或未知的負載更便宜；在持續高吞吐量下，比佈建模式貴約 5-10 倍。DEA-C01 考試會問「數年內可預測的 50 MB/s」（佈建模式）vs 「不可預測的突發性負載」（按需模式）。

Amazon MSK — 託管 Apache Kafka

MSK 是託管的 Apache Kafka 服務。DEA-C01 考試測試何時 MSK 勝過 Kinesis，反之亦然。

何時 MSK 勝過 KDS

團隊已有本地 Kafka 並希望遷移到 AWS 且保持 API 相容。團隊使用 Kafka Connect、Kafka Streams、Schema Registry 或其他 Kafka 生態系統工具。團隊需要 Kafka 特有功能，如壓縮主題 (compacted topics)、正好一次事務 (exactly-once transactions) 或更大的訊息大小（Kafka 預設支持最高 1 MB 訊息，與 Kinesis 1 MB 限制語義不同）。通過 Kafka ACL 進行每主題存取控制的多租戶環境。

MSK 叢集架構

代理程式 (Brokers) 運行在多個可用區域 (AZ) 私有子網中的 EC2 執行個體上。AWS 管理代理程式修補、故障替換和儲存擴展。您配置代理程式執行個體類型（從 kafka.m5.large 到 kafka.m5.24xlarge 或用於開發的 kafka.t3.small）、每個 AZ 的代理程式數量、EBS 磁碟大小以及 Kafka 版本。

主題分割區與複寫

Kafka 主題被劃分為多個分割區 (partitions)；生產者寫入分割區，取用者從分割區讀取。每個分割區在多個代理程式之間進行複寫（預設複寫因子為 3）以確保持久性。排序保證在分割區內有效，跨分割區則無效 — 這與 Kinesis 分片相同。

MSK 佈建模式定價

按代理程式小時付費（us-east-1 的 kafka.m5.large 為 $0.21/時）加 EBS 存儲的每 GB 月費用。叢集不論流量大小 24x7 運行。成本隨叢集規模擴展，而非隨吞吐量擴展。

MSK Connect — 託管 Kafka Connect

MSK Connect 是用於來源/接收器連接器工作負載的託管 Kafka Connect。

Kafka Connect 的作用

Kafka Connect 是用於在 Kafka 與外部系統之間移動資料的開源框架。來源連接器 (Source connectors) 將資料從資料庫（使用 Debezium 進行 CDC）、檔案或 API 拉取到 Kafka 主題中。接收器連接器 (Sink connectors) 將資料從 Kafka 主題推送到 S3、Redshift、OpenSearch、JDBC 資料庫或其他目標。

MSK Connect vs 自管模式

MSK Connect 將 Kafka Connect 工作節點 (workers) 作為託管服務運行。您上傳連接器外掛程式，配置來源/目標端點，MSK Connect 處理工作節點的佈建、擴展和恢復。定價按工作節點小時計算。在大規模情況下，EC2 上的自管 Kafka Connect 更便宜，但需要承擔操作維護責任。

常見 MSK Connect 模式

Debezium CDC：PostgreSQL 或 MySQL 即時寫入 Kafka 主題，下游取用者（Flink、Lambda）處理變更流。S3 接收器：將 Kafka 主題持續傳遞到按日期分割的 S3。JDBC 接收器：將 Kafka 主題寫入 Aurora 或 RDS 供運作使用。

MSK 無伺服器 (Serverless) — 無需管理代理程式

MSK 無伺服器是 Kafka 的按需對等版本。

MSK 無伺服器提供什麼

完全託管的 Kafka，無需代理程式佈建、無需容量規劃、無需代理程式調優。自動擴展分割區和吞吐量。按分割區小時和擷取/輸出 GB 數付費。主題可以擴展到比佈建模式 MSK 更高的分割區計數。

佈建模式 vs 無伺服器模式的成本權衡

MSK 無伺服器對於變動或低流量的負載更便宜。MSK 佈建模式對於持續高吞吐量的工作負載更便宜，因為代理程式機群成本可以在恆定流量中得到很好地攤提。DEA-C01 考試會問「低運作開銷且 Kafka 流量不可預測」（無伺服器）vs 「1 GB/s 持續 Kafka 流量且需優化成本」（佈建模式）。

MSK vs Kinesis — 該選哪一個

兩者都是串流服務。決策標準各異。

選擇 MSK 的場景

已有 Kafka 生態系統（Kafka Connect、Kafka Streams、Schema Registry、kSQL）。從本地 Kafka 遷移且需 API 相容。具有每主題 ACL 的多租戶 Kafka 叢集。針對索引鍵事件流需要壓縮主題（每個鍵保留最新值）。當分割區數量很高時，每個分割區的吞吐量高於 Kinesis 分片限制。

選擇 Kinesis 的場景

AWS 原生簡單性（無需 Kafka 知識）。與 Lambda、Firehose、Flink 以及 AWS 原生取用者的直接整合。適用於不可預測工作負載的按需容量模式。運作開銷比 MSK 無伺服器更低。長保留期（高達 365 天）且無需手動管理日誌保留。

常見混合模式

某些架構兩者兼用：MSK 作為跨服務的中央事件匯流排，Kinesis 用於 AWS 原生擷取（CloudWatch Logs 訂閱、AWS 服務事件擷取），通過 MSK Connect 或自定義 Lambda 執行跨流複寫。

排序保證 (Ordering Guarantees)

Kinesis 和 MSK 都保證排序，但僅限於一個單元內。

Kinesis 分片內的排序

具有相同分割區索引鍵的所有記錄都會路由到同一個分片，在分片內記錄嚴格按序號排序。跨分片則無排序保證。如果以 customer_id 作為分割區索引鍵，讀取 customer-123 交易流的取用者會按順序看到它們。

MSK 分割區內的排序

發送到同一個分割區（由分割區索引鍵雜湊或生產者指定）的所有記錄都是嚴格排序的。跨分割區則無排序保證。邏輯模型與 Kinesis 分片相同。

跨分片或跨分割區排序

如果需要對所有記錄進行全局排序，唯一的安全選項是：使用單個分片或分割區（限制了吞吐量至單分片上限），或使用全局序號實現應用程式層級的排序（複雜，且違背了分割資料的目的）。DEA-C01 考試會設定如「在整個流中保持交易順序」的情境 — 答案是「使用單個分片」或「按全局排序鍵分割」，具體取決於約束條件。

加密與安全

兩項服務均支援靜態加密和傳輸中加密。

Kinesis Data Streams 加密

使用 AWS KMS（AWS 託管金鑰或客戶管理金鑰 CMK）進行伺服器端加密。按流啟用。加密套用於串流存儲中的靜態資料；傳輸中加密由 HTTPS API 端點強制執行。

Kinesis Data Firehose 加密

傳遞目的地的伺服器端加密（針對 S3 目的地的 SSE-S3 或 SSE-KMS）。強制執行到目的地的傳輸中加密。如果生產者使用 Kinesis stream 作為來源，來源記錄可以由 KMS 加密（Firehose 通過資料流的 KMS 金鑰進行解密）。

MSK 加密

傳輸中：用戶端到代理程式、代理程式到代理程式、代理程式到 ZooKeeper 的 TLS 加密。可配置為僅限 TLS、TLS 加純文字或僅限純文字。靜態：對代理程式存儲磁碟使用 KMS 進行伺服器端加密。

身分驗證

KDS：IAM（簽名的 API 調用）。Firehose：IAM。MSK：SASL/SCRAM（使用者名稱-密碼）、IAM 身分驗證（Kafka API 上的 AWS 原生驗證）、TLS 相互驗證（用戶端憑證）或不驗證（僅限私有子網）。

白話文解釋 — Kinesis Streams、Firehose 與 MSK

串流服務三劍客是那種僅看名稱會錯過架構實相的決策。三個具體的類比可以讓結構清晰。

類比 1 — 特快列車、郵政貨車與貨運鐵路

想像在兩個城市之間移動貨物的三種方式。特快列車 (Kinesis Data Streams) 每分鐘發車，高速運載乘客和貨物，並抵達精確的月台 — 但您必須在目的地月台協調人員接收貨物，且必須自己構建那個接收站。郵政貨車 (Kinesis Data Firehose) 在裝貨碼頭等待，直到裝滿或滿 5 分鐘（以先到者為準），然後駛向一組固定的郵政倉庫 — 您不管理貨車或倉庫，但您不能發送到沒有郵政倉庫的目的地，且等待時間意味著緊急包裹無法在幾秒鐘內送達。貨運鐵路 (Amazon MSK) 是火車的工業級版本 — 每列火車有許多車廂、專用軌道，全國每家運輸公司都構建了與鐵路標準相容的工具，但運營貨運鐵路需要人員、排程和基礎設施投入。

對於到自定義目的地的即時遞送：特快列車（KDS 加自定義取用者）。對於到標準目的地的批次遞送：郵政貨車 (Firehose)。對於具有完整鐵路生態系統的工業級運輸：貨運鐵路 (MSK)。DEA-C01 考試會問需求縮窄至這三者之一的情境題；識別這些平行關係可加快選擇速度。

類比 2 — 電話線、語音信箱服務與辦公室交換機 (PBX)

想像處理業務通訊的三種方式。直接電話線 (Kinesis Data Streams) 將您即時連接到接收者 — 對方拿起電話，你們就可以交談；如果對方不在，您掛斷稍後再撥，但線路本身始終是通的。語音信箱服務 (Kinesis Data Firehose) 錄製至少一分鐘的訊息，然後在方便時播放給接收者 — 您不能在中途打斷接收者，但您也不需要他們此時正坐在辦公桌前。辦公室 PBX (Amazon MSK) 是具有分機、呼叫路由、會議橋、錄音功能以及與行業內每個 CRM 整合的完整企業電話系統 — 安裝它是一個項目，但一旦安裝，每個部門都可以使用。

即時對話：電話線。錄音遞送給已知接收者：語音信箱。完整的企業通訊基礎設施：PBX。這與考試中的 KDS vs Firehose vs MSK 決策完全一致。

類比 3 — 餐廳櫃檯、得來速與外燴服務

想像餐廳接單的三種方式。櫃檯 (Kinesis Data Streams) 即時接受每位顧客的訂單，廚房立即處理，顧客等待 60 秒後拿著食物離開。得來速 (Kinesis Data Firehose) 在點餐機處批次處理訂單，廚房成波次處理，顧客開車向前等待 3 分鐘 — 所需人員較少但單個顧客速度較慢。外燴服務 (Amazon MSK) 為數百位賓客處理多道菜餚的活動，涉及菜單規劃、設備租賃、專門的外燴廚師，以及在場外部署的完整餐廳生態系統 — 對於單個三明治來說大材小用，對於企業活動則是唯一選擇。

櫃檯提供個人即時服務。得來速提供批次託管傳遞。外燴提供具有完整生態系統的工業級運作。DEA-C01 考試會用技術名稱問同樣的架構問題。

Kinesis 與 MSK 的常見考試陷阱

DEA-C01 考試設定了一組一致的陷阱。請務必記住這五個。

陷阱 1 — 使用 Firehose 實現即時

情境描述「1 秒內的即時需求」並提供 Firehose 作為託管答案。錯誤。Firehose 至少有 60 秒的緩衝。正確答案是 KDS 加上 Lambda 或 Flink。

陷阱 2 — 沒有取用者的 KDS

情境描述資料被放入 KDS 但未提到取用者，並詢問資料去向。KDS 不會自動傳遞 — 它是一個等待取用者的緩衝區。如果需求是「無需程式碼即可遞送到 S3」，答案是 Firehose，而不是 KDS。

陷阱 3 — 低基數分割區索引鍵導致的熱分片

情境描述資料流寫入流量很高，但在分片之間分佈不均（一個分片 100% 負載，其他閒置）。原因是分割區索引鍵基數太低。修復方法是選擇更高基數的鍵 — 而不是單純增加分片。在不修復索引鍵的情況下增加分片只會建立更多未充分利用的分片，而熱分片依然很熱。

陷阱 4 — 混淆增強型展開與增加分片

情境描述四位取用者在競爭每個分片共享的 2 MB/s 讀取吞吐量。修復方法是使用增強型展開（每位取用者獲得每個分片專用的 2 MB/s），而不是增加分片。增加分片雖能提高寫入容量，但無法改變共享讀取模式下的單個取用者讀取瓶頸。

陷阱 5 — 該選無伺服器時選了 MSK 佈建模式

情境描述「Kafka 流量不可預測且運作開銷低」。錯誤答案：具有手動代理程式調優的 MSK 佈建模式。正確答案：MSK 無伺服器。僅當持續吞吐量可預測且成本優化證明值得投入代理程式管理開銷時，佈建模式才是正確選擇。

關鍵數據與必背事實

Kinesis Data Streams

• 每個分片 1 MB/s 或 1000 條記錄/s 寫入
• 每個分片 2 MB/s 讀取（共享）或每取用者每個分片 2 MB/s（增強型展開）
• 預設保留 24 小時，最高 365 天
• 按需模式預設上限：200 MB/s 寫入，200,000 條記錄/s
• EFO 傳播低於 200 毫秒；端到端中位數延遲約 70 毫秒

Kinesis Data Firehose

• 緩衝大小 1-128 MB（預設 5 MB）
• 緩衝間隔 60-900 秒（預設 300 秒，最低 60 秒）
• 原生目的地：S3、Redshift（通過 S3）、OpenSearch、HTTP、Splunk、Datadog、Snowflake、MongoDB Atlas、New Relic
• 通過 Glue 表轉換格式為 Parquet/ORC
• 支援動態分割

Amazon MSK

• 佈建模式：按代理程式小時計費（us-east-1 的 kafka.m5.large 為 $0.21/時）
• 無伺服器模式：按分割區小時加擷取/輸出 GB 數計費
• 預設在 AZ 之間進行 3 份複寫
• 身分驗證：SASL/SCRAM、IAM、TLS 相互驗證、純文字（僅限私有）
• MSK Connect：按工作節點小時計算的託管 Kafka Connect

排序 (Ordering)

• KDS：在分片內有序
• MSK：在分割區內有序
• 若不使用單個分片/分割區，則無跨分片或跨分割區的排序保證

常見問題 (FAQ) — Kinesis 與 MSK 熱門問題

Q1 — 我應該在什麼時候選擇 Kinesis Data Streams 而不是 Kinesis Data Firehose？

當延遲必須低於一秒、當您需要自定義取用者邏輯（過濾、多目標路由、具狀態處理）、當您需要長保留期以便重播（最高 365 天），或者當取用者是由您的團隊編寫時，請選擇 KDS。當可以接受 60 秒以上的延遲、目的地是 S3/Redshift/OpenSearch 且您不想編寫取用者程式碼，或者需要格式轉換（JSON 轉 Parquet）和動態分割時，請選擇 Firehose。許多架構兩者兼用：KDS 用於即時取用路徑，外加從同一個 KDS 流分出的 Firehose 用於 S3 封存。

Q2 — 我該如何診斷熱分片 (hot shard) 問題？

觀察每個分片的 CloudWatch 指標 IncomingBytes 和 IncomingRecords。如果一個分片達到了 1 MB/s 或 1000 條記錄/s 的上限，而其同儕分片卻處於閒置狀態，則說明分割區索引鍵的基數太低。解決方法是將分割區索引鍵更改為更高基數的欄位（例如使用 user_id 而非國家/地區，使用 transaction_id 而非客戶群組）。單純分割熱分片沒有幫助 — 新建立的子分片會繼承同樣的雜湊範圍分割，如果分割區索引鍵仍壓倒性地映射到其中一半，問題依然存在。DEA-C01 考試中，正確修復方案是重新設計分割區索引鍵，而非容量擴展。

Q3 — 什麼是增強型展開 (Enhanced Fan-Out)，我何時需要它？

增強型展開 (EFO) 為每位註冊的取用者提供每個分片專用的 2 MB/s 讀取通道，且傳播延遲低於 200 毫秒。如果不使用 EFO，所有標準取用者會共享每個分片 2 MB/s 的讀取預算，這意味著三位取用者每位僅能分到約 666 KB/s，且會互相拖累。當有超過兩個獨立的取用者應用程式讀取同一個流、當亞秒級傳播至關重要，或者取用者不應互相干擾吞吐量時，請使用 EFO。EFO 在每位取用者的每分片小時以及每 GB 檢索資料上會有額外費用，但它是多取用者流的正確答案。考試常以「四位取用者讀取同一個流，其中一位落後」來設定此考點。

Q4 — 相比 Kinesis，MSK 在什麼時候更具意義？

當團隊已有 Kafka 技能、當從本地 Kafka 遷移需要 API 相容性、當需要 Kafka 生態系統工具（Kafka Connect、Kafka Streams、Schema Registry、kSQL）、當需要用於索引鍵狀態事件流的壓縮主題，或需要具有每主題 ACL 的多租戶 Kafka 叢集時，MSK 是正確選擇。當 AWS 原生簡單性優於 Kafka 生態系統、當按需容量模式優於代理程式管理，或者取用者是使用 Lambda/Firehose/Flink 從零開始編寫時，Kinesis 是正確選擇。DEA-C01 考試情境題包括「以最小程式碼更改遷移本地 Kafka」(MSK) 以及「無 Kafka 背景的 AWS 原生串流」(Kinesis)。

Q5 — MSK Connect 與在 EC2 上運行 Kafka Connect 相比如何？

MSK Connect 是 Kafka Connect 工作節點的託管執行環境。您上傳連接器外掛程式，配置連接器屬性，MSK Connect 處理工作節點的佈建、自動擴展、故障恢復和修補。定價按工作節點小時計算。在大規模情況下，EC2 上的自管 Kafka Connect 更便宜（您可以控制執行個體類型和預留執行個體價格），但需要承擔工作節點機群的操作維修責任。對於託管的簡單性和標準連接器，請選擇 MSK Connect。當您擁有 Kafka Connect 操作專業知識且大規模下的成本優化很重要時，請選擇自管模式。常見連接器：用於 CDC 的 Debezium、S3 接收器、Snowflake 接收器、JDBC 來源/接收器。

Q6 — Kinesis 和 MSK 的排序保證是什麼？

Kinesis 保證在分片內有序 — 具有相同分割區索引鍵的所有記錄都會路由到同一個分片，並在分片內嚴格按序號排序。跨分片則無排序保證。MSK 保證在分割區內有序 — 發送到同一個分割區（由分割區索引鍵或生產者指定）的所有記錄都是嚴格排序的。跨分割區則無排序保證。對於所有記錄的全局排序，唯一選項是單分片/分割區（會限制吞吐量）或應用程式層級的重新排序。DEA-C01 考試測試需要客戶端排序的情境 — 按 customer_id 分割，每個客戶的順序會被保留；跨客戶順序則不會。

Q7 — 針對 Kinesis Data Streams，我該如何選擇按需模式或佈建模式？

當流量不可預測、容量規劃不切實際、您不想監控和重新分片，或是用於原型和開發環境時，請選擇按需模式。按擷取 GB 數和檢索 GB 數計費。當流量可預測且持續、大規模高吞吐量下的成本優化很重要，或者按需模式的上限（預設 200 MB/s）不夠用時，請選擇佈建模式。按分片小時加每百萬次 PUT 計費。平衡點：在持續約 5 MB/s 及以上且具有可預測模式的情況下，佈建模式通常在成本上勝出。DEA-C01 考試會問「流量突發且無暇進行容量規劃」（按需模式）vs 「穩定 50 MB/s 運行數年，優化成本」（佈建模式）。

延伸閱讀 — AWS 官方文件

Kinesis 和 MSK 的權威 AWS 來源包括：《Kinesis Data Streams 開發人員指南》（概念、分片、分割區索引鍵、取用者、按需模式）、《Amazon Data Firehose 開發人員指南》（傳遞流、緩衝、格式轉換、動態分割、目的地）、《Amazon MSK 開發人員指南》（叢集設定、代理程式、主題、MSK 無伺服器、MSK Connect、安全），以及 《在 AWS 上構建現代資料串流架構》 白皮書（涵蓋展開、聚合、即時 vs 近乎即時、端到端流水線模式）。

AWS 大數據部落格有多篇關於 Kinesis 增強型展開、MSK 無伺服器採用模式、MSK Connect Debezium CDC 流水線以及 Firehose 動態分割案例研究。AWS Skill Builder 課程 《Exam Prep Standard Course: AWS Certified Data Engineer – Associate (DEA-C01)》 涵蓋了領域 1 串流服務的實戰情境。AWS 解決方案庫中包含即時欺詐檢測、IoT 資料流水線和點擊流分析的參考架構，這些都直接對應到 DEA-C01 考試情境。最後，Amazon Kinesis 和 Amazon MSK 的 AWS 串流資料解決方案快速啟動部署提供了 CloudFormation 範本，可構建生產級串流流水線供實踐使用。