Amazon Kinesis Data Streams 常見問答集

碎片在串流中具有一系列資料記錄。它用作 Kinesis 資料串流的基本輸送量單位。一個碎片支援每秒 1 MB/秒 1,000 條記錄的寫入和 2 MB/秒的讀取。碎片限制可確保可預測的效能，從而輕鬆地設計和操作高度可靠的資料串流工作流程。生產者將資料記錄放入碎片中，取用者從碎片中獲取資料記錄。取用者使用碎片進行平行資料處理，並按照資料存放的確切順序取用資料。如果寫入和讀取超過碎片限制，生產者和取用者應用程式將收到節流，可透過重試進行處理。

記錄是儲存在 Amazon Kinesis 資料串流中的資料單位。記錄由序號、分區索引鍵和資料 Blob 組成。資料 Blob 是您的資料生產者新增到資料串流的重要資料。資料 Blob 的大小上限 (Base64 編碼前的資料承載) 是 1 百萬位元組 (MB)。

分區索引鍵是用於隔離和路由記錄到不同的資料串流碎片。分區索引鍵是由您的資料生產者在新增資料到 Kinesis 資料串流時指定。例如，假設您的資料串流有兩個碎片 (碎片 1 和碎片 2)。您可以將資料生產者設定為使用兩個分區索引鍵 (索引鍵 A 和索引鍵 B)，讓所有含索引鍵 A 的記錄新增到碎片 1，而所有含索引鍵 B 的記錄新增到碎片 2。

序號是每個記錄的唯一識別符。序號是資料生產者呼叫 PutRecord 或 PutRecords 操作以將資料新增至 Amazon Kinesis 資料串流 時，由 Amazon Kinesis 所指派。相同分區索引鍵的序號通常會隨時間增加；PutRecord 或 PutRecords 請求之間的時段越長，序號就會變得越大。

Kinesis Data Streams 的容量模式確定容量的管理方式和資料串流的用量收費。您可以在佈建模式和隨需模式之間進行選擇。在佈建模式中，您可指定資料串流的碎片數量。資料串流的總容量是其碎片容量的總和。您可以視需增加或減少資料串流中的碎片數量，並按小時費率支付碎片數量費用。在隨需模式中，AWS 會管理碎片以提供必要的輸送量。您只需為實際使用的輸送量付費，Kinesis Data Streams 會在您的工作負載輸送量增加或減少時自動滿足其需求。兩種容量模式都支援所有 Kinesis Data Streams 寫入和讀取 API 以及選用功能，例如擴展保留和增強型散發。

隨需模式最適合具有不可預測且高度可變流量模式的工作負載。如果您更願意 AWS 代您管理容量或按輸送量付費定價，則應使用此模式。佈建模式最適合可預測的流量，其中容量需求很容易預測。如果您希望對資料在碎片之間的分佈方式進行精密控制，則應考慮使用佈建模式。如果您想佈建額外的碎片，讓取用應用程式可以有更多的讀取輸送量，以加快整體處理速度，那麼佈建模式也適用。

是。您可以每天兩次在隨需模式和佈建模式之間切換。從佈建模式切換至隨需模式時，資料串流的碎片計數保持不變，反之亦然。透過從佈建容量模式切換至隨需容量模式，您的資料串流將保留其在轉換前的任何碎片數量。但從那時起，Kinesis Data Streams 會監控您的資料流量，並根據流量的增加或減少來增加或減少此隨需資料串流的碎片數量。

您可以透過 PutRecord 和 PutRecords 操作 KPL 或 Amazon Kinesis 代理器，將資料新增到 Amazon Kinesis 資料串流。

PutRecord 操作允許 API 呼叫內的單一資料記錄，而 PutRecords 操作允許 API 呼叫內的多個資料記錄。如需詳細資訊，請參閱 PutRecord 和 PutRecords。

KPL 是一個易於使用且高度可設定的程式庫，可協助您將資料放入 Amazon Kinesis 資料串流中。KPL 提供一個簡單、非同步且可靠的介面，可協助您以最少的用戶端資源快速實現高生產者輸送量。

Amazon Kinesis 代理器是預先建置的 Java 應用程式，可讓您輕鬆收集資料並將資料傳送至 Amazon Kinesis 資料串流。您可以在以 Linux 為基礎的伺服器環境 (例如 Web 伺服器、日誌伺服器及資料庫伺服器) 安裝代理器。代理器會監控特定檔案並持續將資料傳送至您的資料串流。如需詳細資訊，請參閱使用代理程式撰寫。

您的資料 Blob、分區索引鍵和資料串流名稱是 PutRecord 或 PutRecords 呼叫的必要參數。您的資料 Blob (Base64 編碼之前) 和分區索引鍵大小將計入 Amazon Kinesis 資料串流的資料輸送量，這是由資料串流內的碎片數量決定。

取用者是處理來自 Kinesis 資料串流所有資料的應用程式。您可以在共享散發和增強型散發使用者類型之間進行選擇，以從 Kinesis 資料串流中讀取資料。共享散發取用者均共享一個碎片 2 MB/秒的讀取輸送量和每秒 5 項交易的限制，並且需要使用 GetRecords API。增強型散發取用者獲得自身 2 MB/秒的讀取輸送量分配，允許多個取用者平行讀取同一串流中的資料，而無需與其他取用者競爭讀取輸送量。您需要將 SubscribeToShard API 與增強型散發取用者配合使用。如果您想向資料串流中新增多個取用者，建議使用增強型散發取用者。

您可以使用 AWS Lambda、Amazon Managed Service for Apache Flink 和 AWS Glue 等受管服務，來處理存放在 Kinesis Data Streams 中的資料。這些受管服務負責佈建和管理底層基礎設施，因此，您可以專注於編寫商業邏輯。您還可以使用 Kinesis Data Streams 與 Kinesis Data Firehose 的預建置整合，將存放在 Kinesis Data Streams 中的資料傳送至 Amazon S3、Amazon OpenSearch Service、Amazon Redshift 和自訂 HTTP 端點。您還可以使用 Amazon Kinesis 用戶端庫、預建置庫或 Amazon Kinesis Data Streams API，來建置自訂應用程式。

適用於 Java、Python、Ruby、Node.js 和 .NET 的 KCL 是一個預先建置的程式庫，可協助您輕鬆建置 Amazon Kinesis 應用程式，以用於讀取和處理來自 Amazon Kinesis 資料串流的資料。

KCL 可處理複雜的問題，例如適應資料串流量的變化、負載平衡串流資料、協調分散式服務和利用容錯能力處理資料。KCL 讓您能夠在建置應用程式時將焦點擺在商業邏輯。 如需有關 KCL 的更多詳細資訊，請參閱這裡的 Kinesis Data Streams 文件。

SubscribeToShard API 是一種高效能串流 API，可透過持續性連線將資料從碎片推送給取用者，而無需用戶端的要求週期。SubscribeToShard API 使用 HTTP/2 通訊協定，在有新資料到達碎片時即傳送資料給註冊的取用者，通常在 70 毫秒內，相較於 GetRecords API，傳送速度提高約 65%。即使在多個註冊的取用者從同一碎片讀取，取用者也能享受快速傳送。

增強型散發是適用於 Kinesis Data Streams 取用者的選擇性功能，可在取用者和碎片之間提供 2 MB/秒輸送量邏輯管道。這可讓您從資料串流並行讀取的取用者數目，同時維持高效能。

如果您具有、或應具有從某個串流並行擷取資料的多個取用者，或如果您有至少一個取用者需要使用 SubscribeToShard API 來在生產者和取用者之間提供亞 200 毫秒的資料交付速度。

取用者透過使用 SubscribeToShard API 擷取資料來利用增強型散發。SubscribeToShard API 內會使用已註冊取用者的名稱，因而會利用提供給已註冊取用者的增強型散發優勢。

是。您可以讓多個取用者使用增強型散發，讓其他取用者不同時使用增強型散發。使用增強型散發不會影響傳統 GetRecords 使用的碎片限制。

是。若要使用 SubscribeToShard，您需要註冊您的取用者，而這會啟用增強型散發。依預設，您的取用者將在透過 SubscribeToShard 擷取資料時自動利用增強型散發。

在隨需模式中建立的新資料串流具有 4 MB/秒的配額和每秒 4,000 條寫入記錄。依預設，這些串流會自動擴充規模至 200 MB/秒和每秒 200,000 條寫入記錄。

隨需模式中的資料串流最多可容納過去 30 天內觀察到兩倍峰值寫入輸送量。在資料串流的寫入輸送量達到新的峰值時，Kinesis Data Streams 會自動擴展串流的容量。例如，如果資料串流的寫入輸送量在 10 MB/秒至 40 MB/秒之間變化，Kinesis Data Streams 將確保您可以輕鬆高載至 80 MB/秒的兩倍峰值輸送量。隨後，如果同一資料串流維持 50 MB/秒的新峰值輸送量，Data Streams 會確保有足夠的容量來擷取 100 MB/秒的寫入輸送量。但是，如果您的流量在 15 分鐘持續時間內增長超過前一個峰值的兩倍，您會看到 “ProvisionedThroughputExceeded” 例外狀況。您需要重試這些調節的請求。

隨需模式的彙總讀取容量與寫入輸送量成正比增加，以確保取用應用程式始終具有足夠的讀取輸送量來即時處理傳入資料。使用 GetRecords API 讀取資料時，您至少可以獲得兩倍的寫入輸送量。建議將一個取用者與 GetRecord API 配合使用，以便在應用程式需要從停機中復原時有足夠的空間來跟上。若要新增多個取用應用程式，您需要使用增強型散發，其支援使用 SubscribeToShard API 將最多 20 個取用者新增至資料串流中，每個取用者都有專用的輸送量。

在佈建模式中，Kinesis 資料串流的輸送量旨在透過增加資料串流中的碎片數量而無限制地擴展。

您可以透過使用 SplitShard API 拆分現有碎片，來在佈建模式下縱向擴展 Kinesis 資料串流容量。您可以透過使用 MergeShard API 合併兩個碎片來縮減容量。或者，您可以使用 UpdateShardCount API 將流容量擴充規模 (或縮減規模) 至特定的碎片計數。

Kinesis 資料串流的輸送量是由資料串流內的碎片數量決定。在佈建模式中，請依照以下步驟估計資料串流需要的初始碎片數量。請注意，您可以透過重新碎片，來動態調整資料串流中的碎片數量。

以千位元組 (KB) 為單位，預估寫入資料串流的記錄平均大小，然後四捨五入到最接近的 1 KB (average_data_size_in_KB)

預估每秒寫入資料串流的記錄數量。(number_of_records_per_second)

決定並行且獨立從資料串流使用資料的 Amazon Kinesis 應用程式數量。(number_of_records_per_second)

以 KB 為單位，計算傳入的寫入頻寬 (incoming_write_bandwidth_in_KB)，這相當於 average_data_size_in_KB 乘以 number_of_records_per_second。

以 KB 為單位，計算傳出的讀取頻寬 (outgoing_read_bandwidth_in_KB)，這相當於 incoming_write_bandwidth_in_KB 乘以 number_of_consumers。

然後您可以使用以下公式計算資料串流需要的初始碎片數量 (number_of_shards)：number_of_shards = max (incoming_write_bandwidth_in_KB/1000, outgoing_read_bandwidth_in_KB/2000)

Kinesis 資料串流的輸送量可無限擴展。以下 AWS 區域的預設碎片配額為每個串流 500 個碎片：美國東部 (維吉尼亞北部)、美國西部 (奧勒岡) 和歐洲 (愛爾蘭)。對於所有其他區域，預設碎片配額為每個串流 200 個碎片。您可以使用 AWS Service Quotas 主控台請求增加碎片配額。

在佈建模式中，Kinesis 資料串流的容量限制由資料串流內的碎片數量定義。資料輸送量或 PUT 記錄的數量可能會超過限制。在超過容量限制時，輸入資料呼叫將以 ProvisionedThroughputExceeded 例外狀況被拒絕。如果這是因為臨時的資料串流輸入資料速率增加所導致，則資料生產者會重試到最終完成請求。如果這是因為持續的資料串流輸入資料速率增加所導致，則應增加資料串流內的碎片數量，以提供足夠容量來持續地成功執行輸入資料呼叫。在這兩種情況下，Amazon CloudWatch 指標都能讓您了解資料串流輸入資料速率的變化，以及 ProvisionedThroughputExceeded 例外狀況的出現。

在佈建模式中，Kinesis 資料串流的容量限制由資料串流內的碎片數量定義。資料輸送量或讀取資料呼叫的數量可以超過限制。當超過容量限制時，讀取資料呼叫將以 ProvisionedThroughputExceeded 例外狀況被拒絕。如果這是因為臨時的資料串流輸出資料速率增加所導致，則 Amazon Kinesis 應用程式會重試到最終完成請求。如果這是因為持續的資料串流輸出資料速率增加所導致，則應增加資料串流內的碎片數量，以提供足夠容量來持續地成功執行讀取資料呼叫。在這兩種情況下，Amazon CloudWatch 指標都可讓您了解資料串流輸出資料速率的變化，以及 ProvisionedThroughputExceeded 例外狀況的出現。

預設的保留時間為 24 小時，能夠應對未能即時處理資料，處理過程中出現間歇性滯後的狀況。7 天的保留時間讓您可以重新處理最多 7 天之前的資料，以解決潛在的下游資料遺失問題。長期資料保留超過 7 天，最多 365 天，讓您可以在演算法回溯測試、資料存放區回填和稽核等使用案例中重新處理舊資料。

是。您可以使用相同的 getShardIterator、GetRecords 和 SubscribeToShard API 讀取保留 7 天以上的資料。取用者可以將反覆運算器移動到串流中的所需位置、擷取碎片對應 (包括開啟和關閉的碎片)，並讀取記錄。

是。存在對 ListShards、GetRecords 和 SubscribeToShard API 的 API 增強功能。您可以將新的篩選選項與 ListShards API 中可用的 TimeStamp 參數一起使用，以有效地擷取碎片對應並提高讀取舊資料的效能。TimeStamp 篩選條件使應用程式可以從您希望重新處理資料的時間點發現並列舉碎片，從而無需從 Trim Horizon 開始。GetRecords 和 SubscribeToShards’s 都有一個新欄位 ChildShards，當應用程式完成從關閉的碎片讀取資料時，您可以快速發現子碎片，而不必再次周遊碎片對應。對於任何大小的串流，碎片的快速發現可有效利用耗用應用程式的運算資源，而不受資料保留期的影響。

如果您計劃保留資料更長的時間並定期擴展串流的容量，則應考慮使用該 API 增強功能。串流擴展操作將關閉現有碎片並開啟新的子碎片。所有開啟和關閉碎片中的資料將一直保留到保留期結束。因此，隨著保留期拉長和多次擴展操作，碎片的總數會線性增加。碎片對應的增加要求您使用帶有 TimeStamp 篩選條件的 ListShards 和 GetRecords 中的 ChildShards 欄位，以及 SubscribeToShard API 來高效發現碎片以進行資料擷取。要使用這些功能，您需要將 KCL 升級到最新版本 1.x (對於標準取用者) 和 2.x (對於增強型散發取用者)。

是。Kinesis Data Streams 的用戶端可以透過 KPL 和 KCL 或透過 AWS Java 開發套件中的 AWS Glue Schema Registry API 使用 AWS Glue 的無伺服器功能 AWS Glue 結構描述登錄檔。結構描述登錄檔功能免費提供。 

請參閱結構描述登錄檔使用者文件，以開始使用和進一步了解。

變更資料串流輸送量有兩種方法。您可以使用 UpdateShardCount API 或 AWS 管理主控台擴展資料串流中的碎片數，或者可以調整資料串流中的碎片數量 (重新碎片) 以變更 Amazon Kinesis 資料串流的輸送量。

通常擴展請求需要花幾分鐘的時間完成。較大的擴展請求會比較小的擴展請求花費更多時間。

是。使用 UpdateShardCount 或重新碎片變更資料串流的輸送量，或 Kinesis Data Streams 在隨需模式中自動執行時，您可以繼續將資料新增至 Kinesis 資料串流，以及從 Amazon Kinesis 資料串流讀取資料。

Amazon Kinesis Data Streams 管理主控台會顯示重要的操作和效能指標，如 Kinesis 資料串流的資料輸入和輸出輸送量。Kinesis Data Streams 也與 Amazon CloudWatch 整合，因此您可針對資料串流及資料串流中的碎片來收集、查看和分析 CloudWatch 指標。如需 Kinesis Data Streams 指標的詳細資訊，請參閱 使用 Amazon CloudWatch 監控 Amazon Kinesis Data Streams。

請注意，所有串流層級指標都是免費的。所有啟用的碎片層級指標會按照 Amazon CloudWatch 定價收費。

Kinesis Data Streams 已與 AWS Identity and Access Management (IAM) 整合，這項服務可協助您安全地控制對 AWS 服務和使用者資源的存取權限。例如，您可以建立僅允許特定使用者或群組將資料新增至資料串流的政策。您也可以將以資源為基礎的政策附加到資料串流或註冊的消費者，以控制資源層級的存取。如需資料串流存取管理和控制的詳細資訊，請參閱使用 IAM 控制對 Amazon Kinesis Data Streams 資源的存取。

您可以使用 IAM 承擔角色或以資源為基礎的政策來與其他帳戶共用存取權。若要與跨帳戶 AWS Lambda 函數共用存取權，請將以資源為基礎的政策附加到您的資料串流或消費者，以授與 Lambda 函數執行角色的存取權。 如需詳細資訊，請參閱搭配使用 AWS Lambda 與 Amazon Kinesis。

Kinesis Data Streams 已與 Amazon CloudTrail 整合，這是一個為您的帳戶記錄 AWS API 呼叫並提供日誌檔的服務。如需 API 呼叫日誌的詳細資訊和支援的 Amazon Kinesis API 操作的清單，請參閱使用 Amazon CloudTrail 記錄 Amazon Kinesis API 呼叫。

Kinesis Data Streams 可讓您為 Kinesis 資料串流加上標籤，以更輕鬆地管理資源和成本。標籤可由使用者定義，並以鍵值組表示，如此有助於組織 AWS 資源。例如，您可以按照成本中心在資料串流加上標籤，以便根據成本中心來分類和追蹤 Kinesis Data Streams 成本。如需 Amazon Kinesis Data Streams 標記的詳細資訊，請參閱 標記 Amazon Kinesis Data Streams。

Amazon Kinesis 預設就非常安全。只有帳戶和資料串流擁有者有權存取他們所建立的 Kinesis 資源。Kinesis 支援使用者身份驗證，以控制對資料的存取。您可以使用 IAM 政策，選擇性地向使用者和使用者群組授與許可。您可以使用 HTTPS 通訊協定，透過 SSL 端點安全地從 Kinesis 放置和取得資料。如果您需要額外的安全性，可以使用伺服器端加密搭配 AWS Key Management Service (AWS KMS) 金鑰，加密存放在資料串流中的資料。AWS KMS 允許使用 AWS 產生的 KMS 金鑰進行加密，但您也可以選擇將自己的 KMS 金鑰帶入 AWS KMS。最後，您可以使用自己的加密庫先在用戶端加密資料，再將資料放進 Kinesis。

是。您可以透過建立 VPC 端點，從 Amazon VPC 以私有方式存取 Kinesis Data Streams API。使用 VPC 端點，AWS 網路會處理 VPC 和 Kinesis Data Streams 之間的路由，無須使用網際網路閘道、NAT 閘道或 VPN 連接。Kinesis Data Streams 使用的最新一代 VPC 端點採用 AWS PrivateLink 技術，這項技術可使用彈性網路介面 (ENI) 搭配 VPC 的私有 IP 啟用 AWS 服務間的私有連線。若要進一步了解 PrivateLink，請瀏覽 PrivateLink 文件。

是，執行此操作有兩種選擇。您可以使用伺服器端加密，這是一項全受管的功能，可在您將資料放入資料串流和取出時自動加密和解密資料。您還可以透過在用戶端加密和解密，將加密的資料寫入資料串流。

您可以選擇伺服器端加密而不選擇用戶端加密，原因如下：

• 用戶端加密不易執行。
• 希望在用戶端加密之上有第二層安全性。
• 用戶端金鑰管理方案不易實作。

Kinesis Data Streams 的伺服器端加密會利用使用者指定的 AWS KMS 金鑰自動加密資料，再寫入資料串流儲存層，然後從儲存擷取資料之後解密資料。加密之後無法寫入，也無法讀取承載和分區索引鍵，除非從資料串流寫入或讀取的使用者擁有許可，能夠在資料串流使用為加密選取的金鑰。因此，伺服器端加密可輕鬆符合控管資料的內部安全性及合規要求。

使用伺服器端加密時，您的用戶端應用程式 (生產者和取用者) 不需要知道加密，他們不需要管理 KMS 金鑰或加密操作，而且您的靜態和動態資料在 Kinesis Data Streams 服務中都會加密。伺服器端加密功能使用的所有 KMS 金鑰都是由 AWS KMS 提供。AWS KMS 可讓您輕鬆使用適用於 Kinesis 的 AWS 受管 KMS 金鑰 (「一鍵式」加密方法)、您自己的 AWS KMS 客戶管理金鑰，或匯入用於加密的 KMS 金鑰。

是，使用者文件中有入門指南。

有可能。需視您用於加密的金鑰及控管存取金鑰的許可而定。

• 如果您使用適用於 Kinesis 的 AWS 受管 KMS 金鑰 (金鑰別名 = aws/kinesis)，您的應用程式將不會受到使用此金鑰啟用或停用加密的影響。
• 如果您使用不同的 KMS 金鑰，像是自訂 AWS KMS 金鑰或匯入 AWS KMS 服務的主金鑰，而且如果資料串流的生產者和取用者沒有使用用於加密的 KMS 金鑰的許可，則您的 PUT 和 GET 請求將會失敗。您必須先設定 AWS KMS 金鑰政策允許加密和解密訊息，才能使用伺服器端加密。如需 AWS KMS 許可的範例和詳細資訊，請參閱 AWS Key Management Service Developer Guide 中的 AWS KMS API Permissions: Actions and Resources Reference，或是 Kinesis Data Streams 伺服器端加密使用者文件中的許可指導方針。

是，但如果您使用適用於 Kinesis 的 AWS 受管 KMS 金鑰，且沒有超過 AWS 免費方案 KMS API 使用費用，則使用伺服器端加密免費。以下依資源說明費用：

金鑰：

適用於 Kinesis 的 AWS 受管 KMS 金鑰 (別名 = "aws/kinesis") 免費。
客戶管理的 KMS 金鑰需支付 KMS 金鑰費用。 進一步了解。

KMS API 用量：

API 用量費用適用於所有 KMS 金鑰，包含自訂項目。Kinesis Data Streams 在輪換資料金鑰時，大約每 5 分鐘呼叫一次 KMS。以一個月 30 天來說，由 Kinesis 資料串流啟動的 KMS API 呼叫總成本應該只有幾美元。請注意，此成本會隨著您在資料生產者和取用者使用的使用者登入資料數量而增加，因為每個使用者憑證都需要唯一的 AWS KMS API 呼叫。當您使用 IAM 角色進行身分驗證時，每一個 assume-role-call 都會產生唯一的使用者登入資料，建議您快取 assume-role-call 傳回的使用者登入資料以節省 KMS 成本。

AWS GovCloud 區域和所有公有區域都提供 Kinesis Data Streams 伺服器端加密，但中國 (北京) 區域除外。

這些操作都可以使用 AWS 管理主控台或使用 AWS 開發套件完成。若要進一步了解，請參閱 Kinesis Data Streams 伺服器端加密入門指南。

Kinesis Data Streams 使用 AES-GCM 256 演算法加密。

否。新的加密只會加密新寫入資料串流的資料 (或保留解密)。

伺服器端加密會加密訊息承載以及由資料串流生產者應用程式指定的分區索引鍵。

伺服器端加密是串流特定功能。

是，使用 AWS 管理主控台或 AWS 開發套件就可以選擇新的 KMS 金鑰套用到特定資料串流。

否。AWS 免費方案目前不包括 Kinesis Data Streams。AWS 免費方案是提供一組 AWS 服務免費試用的計劃。有關 AWS 免費方案的更多詳細資訊，請參閱 AWS 免費方案。

Kinesis Data Streams SLA 保證 Kinesis Data Streams 每個月正常執行時間百分比至少為 99.9%。

如果您在一個以上的可用區域內執行某項任務，而且在每個月結算週期內，同一個區域每個月的正常執行時間百分比低於 99.9%，則根據 Kinesis Data Streams SLA，您有資格獲得 Kinesis Data Streams 的 SLA 積分。

如需 SLA 所有條款與條件的完整詳細資訊，以及如何提交索賠的詳細資訊，請參閱 Amazon Kinesis Data Streams SLA。

Kinesis Data Streams 使用簡單的依用量計費定價。無需預付費用或最低費用，只需按使用的資源付費。Kinesis Data Streams 有兩種容量模式，即隨需和佈建，並且都帶包含特定的計費選項。

使用隨需容量模式，您無需指定希望應用程式執行的讀取和寫入輸送量。在此模式中，定價基於導入和檢索的資料量，以及您帳戶中每個資料串流的每小時費用。選用功能需要額外付費：延長資料保留 (超過前 24 小時和前 7 天內)、長期資料保留 (超過 7 天和長達一年) 和增強型散發。如需 Kinesis Data Streams 費用的詳細資訊，請參閱 Amazon Kinesis Data Streams 定價。

使用佈建容量模式，您可以根據應用程式的寫入和讀取請求速率，指定應用程式所需的碎片數量。碎片是一種容量單位，可提供 1 MB/秒的寫入速度和 2 MB/秒的讀取速度。您需要按小時費率支付每個碎片的費用。您還需要為寫入 Kinesis 資料串流的記錄付費。使用選用功能時，例如延長保留和增強型散發，會產生額外費用。

以下是 Kinesis Data Streams 佈建模式中的兩個核心維度和三個選用維度：

• 由 Amazon Kinesis 資料串流內的碎片數量決定的每小時碎片成本。
• 以及由資料產生者新增到資料串流的 25 KB 承載單位數量決定的 PUT 承載單位成本。

選擇性：

• 選擇性延長資料保留時間的費用是根據資料串流產生的碎片小時數來決定。啟用延長資料保留時間時，您需針對串流中的每個碎片支付延長保留時間費率。
• 長期資料保留是一項選擇性付費服務，具有兩個成本維度：長期資料儲存和長期資料擷取。長期資料儲存反映保留 7 天以上且最多 365 天的資料月 GB 數。長期資料擷取反映擷取存放 7 天以上資料的 GB 數。
• 增強型散發是一項選擇性付費服務，具有兩個費用維度：取用者碎片時數和資料擷取。取用者碎片時數反應串流中的碎片數目乘以使用增強型散發的取用者數目。資料擷取由傳送至使用增強型散發之取用者的 GB 數決定。

如需 Kinesis Data Streams 費用的詳細資訊，請參閱 Amazon Kinesis Data Streams 定價。

取用者碎片時數可透過將註冊的串流取用者數目乘以串流中的碎片數目來計算。您還需支付取用者註冊使用增強型散發的依比例分配計算的小時部分。例如，如果取用者碎片時數費用為 0.015 USD，對於 10 個碎片資料串流，使用增強型散發的此取用者將能夠從 10 個碎片讀取，因此每小時產生取用者碎片時數費用 0.15 USD (1 個取用者 * 10 個碎片 * 每取用者碎片小時 0.015 USD)。如果有兩個註冊同時使用增強型散發的取用者，取用者碎片時數總費用將為每小時 0.30 USD (2 個取用者 * 10 個碎片 * 0.015)。

Kinesis Data Streams 和 Amazon MSK 都是熱門的資料串流平台，可協助您建置自己的串流工作負載，以處理符合特殊需求的資料。這兩種服務都具有可擴展性、安全性和高可用性。它們都可部署為執行串流使用案例，例如即時 Web 和日誌分析、個人化客戶體驗、事件驅動型架構、IoT 分析和即時詐騙偵測。在兩者之間進行選擇時，請務必考慮您的具體使用案例和需求。以下是一些需要考量的因素：

熟悉度

•  如果您是串流技術新手，請使用 Kinesis Data Streams。
• 如果您有執行於 Apache Kafka 的現有應用程式，請使用 MSK。MSK 具有現有的 Kafka 遷移計畫 (KMP) 和遷移指南，可讓遷移體驗更加簡便。

喜好開放原始碼

• 如果您更喜歡使用開放原始碼技術，建議您使用 MSK。MSK 和 MSK Connect 分別與開放原始碼 Apache Kafka 和 Kafka Connect 完全兼容。

Kinesis Data Streams 可即時處理大數據的串流。它提供記錄排序，也提供對多個 Amazon Kinesis 應用程式以相同順序讀取和/或重新顯示記錄的能力。Amazon Kinesis Client Library (KCL) 能夠將指定分區索引鍵的所有記錄交付給相同記錄處理器，讓它更輕鬆地建置從相同 Kinesis 資料串流讀取資料的多個應用程式 (例如，執行計數、彙總和篩選)。Amazon Simple Queue Service (Amazon SQS) 提供一個可靠、可高度擴展且完全託管的佇列，以存放在電腦之間傳輸的訊息。Amazon SQS 讓您能夠在分散式應用程式元件之間輕鬆移動資料，並協助您建置可以單獨處理訊息的應用程式 (使用訊息層級確認/失敗語義)，如自動工作流程。

我們建議將 Kinesis Data Streams 用於有類似以下要求的使用案例：

• 將相關記錄路由到相同記錄處理器 (如串流處理 MapReduce)。 例如，當指定索引鍵的所有記錄都路由到相同記錄處理器時，計數和彙總較為簡單。
• 記錄的排序。 例如，您希望將日誌資料從應用程式主機傳輸到處理/存檔主機，同時保持日誌報表的順序。
• 多個應用程式並行使用相同串流的能力。 例如，您有一個更新即時儀表板的應用程式，還有另一個將資料存檔到 Amazon Redshift 的應用程式。您希望這兩個應用程式並行且獨立地使用相同串流的資料。
• 在數小時之後以相同順序使用記錄的能力。 例如，您有一個帳單應用程式，以及一個在帳單應用程式執行之後數小時才執行的稽核應用程式。因為 Kinesis Data Streams 存放資料的時間最長為 365 天，所以您可在帳單應用程式之後的 365 天內執行稽核應用程式。

我們建議將 Amazon SQS 用於具有類似以下要求的使用案例：

• 簡訊語義 (如訊息層級確認/失敗) 和可見性逾時。 例如，您有一個工作項目佇列，而希望單獨追蹤每個項目的成功完成情況。Amazon SQS 可追蹤確認/失敗，因此應用程式無須維護持久性檢查點/游標。在設定的可見性逾時後，Amazon SQS 會刪除已確認的訊息，並重新交付失敗的訊息。
• 個別的訊息延遲。 例如，您有一個任務佇列，且需要排定含延遲的個別任務。您可以透過 Amazon SQS 將個別訊息設定為最多 15 分鐘的延遲。
• 動態增加讀取時間的並行/輸送量。 例如，您有一個工作佇列，且希望新增更多閱讀器，直到待處理項目清除為止。透過 Kinesis Data Streams，您可以擴充規模至足夠的碎片數量 (但請注意，您將需要提前佈建足夠的碎片)。
• 利用 Amazon SQS 通透擴展的能力。 例如，由於業務的偶爾負載尖峰或自然增長，您有緩衝請求和負載變更。因為每個緩衝的請求可以單獨處理，因此 Amazon SQS 可以通透地擴展以處理負載，無須您提供任何佈建指示。