本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
DynamoDB 中繼資料資料表和 中的負載平衡 KCL
KCL 管理中繼資料，例如工作者的租用和CPU使用率指標。KCL 會使用 DynamoDB 資料表追蹤這些中繼資料。對於每個 Amazon Kinesis Data Streams 應用程式， 會KCL建立三個 DynamoDB 資料表來管理中繼資料：租用資料表、工作者指標資料表和協調器狀態資料表。
注意
KCL 3.x 推出兩個新的中繼資料資料表：工作者指標和協調器狀態資料表。
重要
您必須為KCL應用程式新增適當的許可，才能在 DynamoDB 中建立和管理中繼資料資料表。如需詳細資訊，請參閱 IAM KCL取用者應用程式所需的許可。
KCL 取用者應用程式不會自動移除這三個 DynamoDB 中繼資料資料表。當您停用KCL取用者應用程式時，請務必移除取用者應用程式建立的這些 DynamoDB 中繼資料資料表，以避免不必要的成本。
租用資料表
租用資料表是唯一的 Amazon DynamoDB 資料表，用於追蹤KCL消費者應用程式的排程器正在租用和處理的碎片。每個KCL取用者應用程式都會建立自己的租用資料表。KCL 根據預設， 會使用取用者應用程式的名稱作為租用資料表的名稱。您可以使用組態設定自訂資料表名稱。KCL 也會使用 的分割區索引鍵在租用資料表上建立全域次要索引， leaseOwner 以有效探索租用。全域次要索引會鏡像基本租用資料表中的 leaseKey 屬性。如果應用程式啟動時KCL，消費者應用程式的租用資料表不存在，則其中一個工作者會為您的應用程式建立租用資料表。
您可以在取用者應用程式執行時使用 Amazon DynamoDB 主控台檢視其租用資料表。
重要
-
每個KCL取用者應用程式名稱必須是唯一的，以防止重複的租用資料表名稱。
-
您的帳戶除須支付 Kinesis Data Streams 本身的相關費用外，另將收取與 DynamoDB 資料表關聯的費用。
租用資料表中的每一列都代表一個碎片，正由消費者應用程式的排程器處理。金鑰欄位包括下列項目：
-
leaseKey：對於單一串流處理，這是碎片 ID。對於使用 進行多串流處理KCL，其結構為
account-id:StreamName:streamCreationTimestamp:ShardId。 leaseKey 是租用資料表的分割區索引鍵。如需多串流處理的詳細資訊，請參閱 使用 進行多串流處理 KCL 。 -
checkpoint：碎片的最新檢查點序號。
-
checkpointSubSequence號碼：使用 Kinesis Producer Library 的彙總功能時，這是檢查點的延伸，可追蹤 Kinesis 記錄中的個別使用者記錄。
-
leaseCounter：用於檢查工作者目前是否正在主動處理租用。如果租用擁有權轉移給其他工作者，則會 leaseCounter 增加 。
-
leaseOwner：目前擁有此租用的工作者。
-
ownerSwitchesSince檢查點：自上次檢查點以來，此租用變更工作者的次數。
-
parentShardId：此碎片父項的 ID。在子碎片上開始處理之前，請確定父碎片已完全處理，並維持正確的記錄處理順序。
-
childShardId：此碎片分割或合併IDs所產生的子碎片清單。用於在重新分割操作期間追蹤碎片譜系和管理處理順序。
-
startingHashKey：此碎片的雜湊金鑰範圍下限。
-
endingHashKey：此碎片的雜湊金鑰範圍上限。
如果您搭配 使用多串流處理KCL，您會在租用資料表中看到下列兩個額外欄位。如需詳細資訊，請參閱使用 進行多串流處理 KCL 。
-
shardID：碎片的 ID。
-
streamName：資料串流的識別碼，格式如下：
account-id:StreamName:streamCreationTimestamp。
工作者指標資料表
工作者指標表是每個KCL應用程式的唯一 Amazon DynamoDB 資料表，用於記錄每個工作者的CPU使用率指標。這些指標將由 用來KCL執行有效的租用指派，以平衡工作者的資源使用率。KCL 預設會將 KCLApplicationName-WorkerMetricStats用於工作者指標表的名稱。
協調員狀態資料表
協調器狀態資料表是每個KCL應用程式的唯一 Amazon DynamoDB 資料表，用於存放工作者的內部狀態資訊。例如，協調器狀態資料表會儲存有關領導者選擇的資料，或與就地遷移相關聯的中繼資料，從 KCL 2.x 遷移至 KCL 3.x。KCL 預設會將 KCLApplicationName-CoordinatorState用於協調器狀態資料表的名稱。
由 建立之中繼資料資料表的 DynamoDB 容量模式 KCL
根據預設，Kinesis Client Library （KCL） 會使用隨需容量模式 建立 DynamoDB 中繼資料資料表，例如租用資料表、工作者指標資料表和協調器狀態資料表。此模式會自動擴展讀取和寫入容量，以適應流量，而不需要容量規劃。我們強烈建議您將容量模式保留為隨需模式，以便更有效率地操作這些中繼資料資料表。
如果您決定將租用資料表切換為佈建容量模式 ，請遵循下列最佳實務：
-
分析用量模式：
-
使用 Amazon CloudWatch 指標監控應用程式的讀取和寫入模式和用量 （RCU、WCU）。
-
了解尖峰和平均輸送量需求。
-
-
計算所需的容量：
-
根據您的分析估計讀取容量單位 （RCUs） 和寫入容量單位 （WCUs）。
-
考慮碎片數量、檢查點頻率和工作者計數等因素。
-
-
實作自動擴展：
-
使用 DynamoDB 自動擴展來自動調整佈建的容量，並設定適當的最小和最大容量限制。
-
DynamoDB 自動擴展有助於避免KCL中繼資料資料表達到容量限制並受限。
-
-
定期監控和最佳化：
-
持續監控 的 CloudWatch 指標
ThrottledRequests。 -
隨著工作負載隨時間變化調整容量。
-
如果您在KCL取用者應用程式的中繼資料 DynamoDB 資料表ProvisionedThroughputExceededException中體驗 ，則必須增加 DynamoDB 資料表的佈建輸送量。如果您在第一次建立取用者應用程式時設定特定程度的讀取容量單位 （RCU） 和寫入容量單位 （WCU），則隨著用量的增加，可能還不夠。例如，如果您的KCL取用者應用程式經常檢查點，或在具有許多碎片的串流上操作，您可能需要更多容量單位。如需有關 DynamoDB 中佈建輸送量的資訊，請參閱 Amazon DynamoDB 開發人員指南中的 DynamoDB 輸送量和更新資料表。 DynamoDB
如何將租用KCL指派給工作者並平衡負載
KCL 持續收集和監控來自執行工作者之運算主機的CPU使用率指標，以確保工作負載分佈均勻。這些CPU使用率指標會儲存在 DynamoDB 中的工作者指標表中。如果 KCL偵測到有些工作者顯示比其他工作者更高的CPU使用率，則會在工作者之間重新指派租用，以降低高度使用工作者的負載。目標是更平均地平衡整個消費者應用程式機群的工作負載，防止任何單一工作者超載。由於 會將CPU使用率KCL分散到消費者應用程式機群，因此您可以選擇正確的工作者人數，或使用自動擴展來有效管理運算容量，以實現較低的成本，從而調整消費者應用程式機群容量的大小。
重要
KCL 只有在符合特定先決條件時，才能從工作者收集CPU使用率指標。如需詳細資訊，請參閱 必要條件。如果 KCL無法從工作者收集CPU使用率指標， KCL將回復為 ，以使用每個工作者的輸送量來指派租用並平衡機群中工作者的負載。KCL 將監控每個工作者在指定時間收到的輸送量，並重新指派租用，以確保每個工作者從其指派的租用中獲得類似的總輸送量層級。
