本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
DynamoDB 元数据表和中的负载平衡 KCL
KCL管理来自员工的租约和CPU利用率指标等元数据。KCL使用 DynamoDB 表跟踪这些元数据。为每个 Amazon Kinesis Data Streams 应用程序KCL创建三个 DynamoDB 表来管理元数据：租赁表、工作人员指标表和协调器状态表。
注意
KCL3.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:ShardIdleaseKey 是租用表的分区键。有关多流处理的更多信息，请参阅多流处理 KCL 。 -
checkpoint：分片的最新检查点序号。
-
checkpointSubSequence数字：使用 Kinesis Producer 库的聚合功能时，这是对检查点的扩展，用于跟踪 Kinesis 记录中的单个用户记录。
-
leaseCounter：用于检查工作人员当前是否正在积极处理租约。 leaseCounter 如果租赁所有权转让给另一名员工，则会增加。
-
leaseOwner: 持有此租约的当前员工。
-
ownerSwitchesSince检查点：自上次检查点以来，这份租约更换了多少次员工。
-
parentShardId: 此分片的父级 ID。确保父分片在子分片上开始处理之前已完全处理，同时保持正确的记录处理顺序。
-
childShardId: 此分片的拆分或合并IDs产生的子分片列表。用于在重新分片操作期间跟踪分片沿袭和管理处理顺序。
-
startingHashKey: 此分片的哈希键范围的下限。
-
endingHashKey: 此分片的哈希键范围的上限。
如果您将多流处理与一起使用KCL，则会在租赁表中看到以下两个额外字段。有关更多信息，请参阅 多流处理 KCL 。
-
shardID：分片的 ID。
-
streamName: 数据流的标识符，格式如下：
account-id:StreamName:streamCreationTimestamp。
工作人员指标表
工作人员指标表是KCL每个应用程序的唯一的 Amazon DynamoDB 表，用于CPU记录每个工作人员的利用率指标。这些指标将用于执行有效的租赁分配，从而实现员工之间的资源利用率平衡。KCLKCL默认情况下KCLApplicationName-WorkerMetricStats，使用作为工作人员指标表的名称。
协调器状态表
协调器状态表是KCL每个应用程序的唯一的 Amazon DynamoDB 表，用于存储工作人员的内部状态信息。例如，协调器状态表存储有关领导者选举的数据或与从 KCL 2.x 到 KCL 3.x 的就地迁移相关的元数据。KCL默认情况下使用KCLApplicationName-CoordinatorState协调器状态表的名称。
由创建的元数据表的 DynamoDB 容量模式 KCL
默认情况下，Kinesis 客户端库 (KCL) 使用按需容量模式创建 DynamoDB 元数据表，例如租赁表、工作器指标表和协调器状态表。此模式可自动扩展读取和写入容量以适应流量，而无需进行容量规划。我们强烈建议您将容量模式保留为按需模式，以便更有效地操作这些元数据表。
如果您决定将租用表切换到预置容量模式，请遵循以下最佳实践：
-
分析使用模式：
-
使用 Amazon CloudWatch 指标监控应用程序的读写模式和使用情况 (RCU,WCU)。
-
了解峰值和平均吞吐量需求。
-
-
计算所需的容量：
-
根据您的分析估算读取容量单位 (RCUsWCUs) 和写入容量单位 ()。
-
考虑诸如分片数量、检查点频率和工作人员数量之类的因素。
-
-
实现自动缩放：
-
使用 D ynamoDB auto Scaling 自动调整预配置容量并设置适当的最小和最大容量限制。
-
DynamoDB 自动缩放将有助于KCL避免您的元数据表达到容量限制并受到限制。
-
-
定期监控和优化：
-
持续监控的 CloudWatch 指标
ThrottledRequests。 -
随着工作负载随时间的推移而变化，调整容量。
-
如果您遇到使用者应用程序ProvisionedThroughputExceededException的元数据 DynamoDB 表的情况，则必须增加 DynamoDB 表的预配置吞吐容量。KCL如果您在首次创建使用者应用程序时设置了一定级别的读取容量单位 (RCUWCU) 和写入容量单位 ()，则随着使用量的增长，这可能不足以满足需求。例如，如果您的使用KCL者应用程序经常执行检查点操作或在包含许多分片的流上运行，则可能需要更多的容量单位。有关 DynamoDB 中预置吞吐量的信息，请参阅《亚马逊 DynamoDB 开发者指南》中的 DynamoDB 吞吐量容量和更新表。
如何将租约KCL分配给员工并平衡负担
KCL持续收集和监控运行工作线程的计算主机的CPU利用率指标，以确保工作负载分布均匀。这些CPU利用率指标存储在 DynamoDB 的工作人员指标表中。如果KCL检测到某些员工的CPU利用率高于其他员工，它将在员工之间重新分配租约，以减轻使用率高的员工的负担。目标是在使用者应用程序群中更均匀地平衡工作负载，防止任何单个工作人员过载。在跨消费类应用程序群中KCL分配CPU利用率时，您可以通过选择合适的工作人员数量来调整消费类应用程序群容量的规模，或者使用 auto scaling 来高效管理计算容量以降低成本。
重要
KCL只有在满足某些先决条件的情况下，才能从工作人员那里收集CPU利用率指标。有关详细信息，请参阅先决条件。如果KCL无法从工作人员那里收集CPU利用率指标，则KCL将回退到使用每个工作人员的吞吐量来分配租约并平衡车队中工作人员的负载。KCL将监控每个工作人员在给定时间收到的吞吐量并重新分配租约，以确保每个工作人员从其分配的租约中获得相似的总吞吐量水平。
