本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
KCL 管理來自工作者的中繼資料，例如租用和 CPU 使用率指標。KCL 會使用 DynamoDB 資料表追蹤這些中繼資料。對於每個 Amazon Kinesis Data Streams 應用程式，KCL 會建立三個 DynamoDB 資料表來管理中繼資料：租用資料表、工作者指標資料表和協調器狀態資料表。
注意
KCL 3.x 推出兩個新的中繼資料資料表：工作者指標和協調器狀態資料表。
重要
您必須為 KCL 應用程式新增適當的許可，才能在 DynamoDB 中建立和管理中繼資料資料表。如需詳細資訊，請參閱 KCL 取用者應用程式所需的 IAM 許可。
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：碎片的最新檢查點序號。
-
checkpointSubSequenceNumber：使用 Kinesis Producer Library 的彙整功能時，此為 checkpoint 的延伸，將追蹤 Kinesis 記錄內的個別使用者記錄。
-
leaseCounter：用於檢查工作者目前是否正在主動處理租用。如果將租用所有權轉移給其他工作者，則 leaseCounter 會增加。
-
leaseOwner：目前持有此租用的工作者。
-
ownerSwitchesSinceCheckpoint：自上次檢查點以來，此租用變更工作者的次數。
-
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做為協調器狀態資料表的名稱。
KCL 所建立中繼資料資料表的 DynamoDB 容量模式
根據預設，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 使用率高於其他工作者，則會在工作者之間重新指派租用，以降低高度使用工作者的負載。目標是更平均地平衡整個消費者應用程式機群的工作負載，防止任何單一工作者超載。隨著 KCL 將 CPU 使用率分散到消費者應用程式機群，您可以選擇正確的工作者數量或使用自動擴展來有效管理運算容量，以實現更低的成本，從而調整消費者應用程式機群容量的大小。
重要
只有在符合特定先決條件時，KCL 才能從工作者收集 CPU 使用率指標。如需詳細資訊，請參閱 先決條件。如果 KCL 無法從工作者收集 CPU 使用率指標，KCL 將回復為使用每個工作者的輸送量來指派租用，並平衡機群中工作者之間的負載。KCL 將監控每個工作者在指定時間收到的輸送量，並重新指派租用，以確保每個工作者從其指派的租用中獲得類似的總輸送量層級。
