KCL 中的 DynamoDB 元数据表和负载平衡 - Amazon Kinesis Data Streams
租约表工作程序指标表协调器状态表KCL 创建的元数据表的 DynamoDB 容量模式KCL 如何向工作程序分配租约并平衡负载

KCL 中的 DynamoDB 元数据表和负载平衡

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 的聚合功能时，这是对跟踪 Kinesis 记录中单个用户记录的检查点的扩展。

  • leaseCounter：用于检查工作程序当前是否正在积极处理租约。如果租约所有权转移给其他工作程序，leaseCounter 就会增加。

  • leaseOwner：持有此租约的当前工作程序。

  • ownerSwitchesSinceCheckpoint：自上次检查点以来，此租约更改了工作程序的次数。

  • parentsHardid：此分片的父级的 ID。在子分片上开始处理之前，务必确保父分片已完全处理，从而保持正确的记录处理顺序。

  • childShardId：因为此分片的拆分或合并产生的子分片 ID 列表。用于在重新分片操作期间跟踪分片世系并管理处理顺序。

  • 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）。

    • 了解峰值及平均吞吐量需求。

  • 计算所需的容量：

    • 根据分析估算读取容量单位 (RCU) 和写入容量单位 (WCU)。

    • 考虑诸如分片数量、检查点频率和工作程序计数之类的因素。

  • 实现自动扩缩：

    • 使用 DynamoDB 自动扩缩自动调整预置容量，并设置适当的最小和最大容量限制。

    • DynamoDB 自动扩缩有助于避免 KCL 元数据表达到容量限制和受到限制。

  • 定期监控和优化：

    • 持续监控 CloudWatch 的 ThrottledRequests 指标。

    • 随着时间推移，按照工作负载的变化调整容量。

如果在 KCL 消费端应用程序的元数据 DynamoDB 表中遇到 ProvisionedThroughputExceededException，必须增加 DynamoDB 表的预置吞吐能力。如在首次创建消费端应用程序时设置了某种级别的读取容量单位 (RCU) 和写入容量单位 (WCU)，随着使用量的增长，这种容量可能无法满足需求。例如，如果 KCL 消费端应用程序频繁执行检查点操作或在包含多个分片的流上运行，则可能需要更多的容量单位。有关 DynamoDB 中预置吞吐量的信息，请参阅《Amazon DynamoDB 开发人员指南》中的 DynamoDB 吞吐能力和更新表。

KCL 如何向工作程序分配租约并平衡负载

KCL 不断收集和监控运行工作程序的计算主机的 CPU 利用率指标，以确保工作负载均匀分配。这些 CPU 利用率指标存储于 DynamoDB 的工作程序指标表中。如果 KCL 检测到某些工作程序的 CPU 利用率高于其他工作程序，它会在工作程序之间重新分配租约，以降低高使用率工作程序的负载。目标是在消费端应用程序队列中更均匀地平衡工作负载，防止任何单一工作程序过载。由于 KCL 在消费端应用程序队列中分配 CPU 利用率，所以可以通过选择适当数量的工作程序来适当调整消费端应用程序队列容量的大小，或者使用自动扩缩功能来高效管理计算容量以降低成本。

重要

只有在满足某些先决条件的情况下，KCL 才能从工作程序收集 CPU 利用率指标。有关更多信息，请参阅 先决条件。如果 KCL 无法从工作程序收集 CPU 利用率指标，KCL 将回退到使用每个工作程序的吞吐量来分配租约，并在队列中的工作程序之间平衡负载。KCL 将监控每个工作程序在给定时间收到的吞吐量并重新分配租约，以确保每个工作程序从其被分配的租约中获得类似的总吞吐量水平。