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

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

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

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：分片的最新检查点序号。

  • checkpointSubSequence数字：使用 Kinesis Producer 库的聚合功能时，这是对检查点的扩展，用于跟踪 Kinesis 记录中的单个用户记录。

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

  • 租赁所有者：持有此租约的当前员工。

  • 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协调器状态表的名称。

KCL 创建的元数据表的 DynamoDB 容量模式

默认情况下，Kinesis 客户端库 (KCL) 使用按需容量模式创建 DynamoDB 元数据表，例如租赁表、工作人员指标表和协调器状态表。此模式可自动扩展读取和写入容量以适应流量，而无需进行容量规划。我们强烈建议您将容量模式保留为按需模式，以便更有效地操作这些元数据表。

如果您决定将租用表切换到预置容量模式，请遵循以下最佳实践：

  • 分析使用模式：

    • 使用 Amazon 指标监控应用程序的读写模式和使用情况（RCU、WCU）。 CloudWatch

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

  • 计算所需的容量：

    • 根据您的分析估算读取容量单位 (RCUsWCUs) 和写入容量单位 ()。

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

  • 实现自动缩放：

    • 使用 D ynamoDB auto Scaling 自动调整预配置容量并设置适当的最小和最大容量限制。

    • DynamoDB 自动缩放将有助于避免您的 KCL 元数据表达到容量限制并受到限制。

  • 定期监控和优化：

    • 持续监控的 CloudWatch 指标ThrottledRequests。

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

如果您在 KCL 使用者应用程序ProvisionedThroughputExceededException中遇到元数据 DynamoDB 表，则必须增加 DynamoDB 表的预配置吞吐容量。如果您在首次创建使用者应用程序时设置了一定级别的读取容量单位 (RCU) 和写入容量单位 (WCU)，则随着使用量的增长，这可能还不够。例如，如果您的 KCL 使用者应用程序经常执行检查点操作或在包含许多分片的流上运行，则可能需要更多的容量单位。有关 DynamoDB 中预置吞吐量的信息，请参阅《亚马逊 DynamoDB 开发者指南》中的 DynamoDB 吞吐量容量和更新表。

KCL 如何将租约分配给员工并平衡负荷

KCL 持续收集和监控运行工作程序的计算主机的 CPU 利用率指标，以确保工作负载分布均匀。这些 CPU 利用率指标存储在 DynamoDB 的工作器指标表中。如果 KCL 检测到某些工作人员的 CPU 利用率高于其他工作人员，它将在工作人员之间重新分配租约，以降低使用率较高的员工的负担。目标是在使用者应用程序群中更均匀地平衡工作负载，防止任何单个工作人员过载。由于 KCL 在消费类应用程序队列中分配 CPU 利用率，您可以通过选择适当数量的工作线程来调整消费类应用程序队列容量的规模，或者使用 auto scaling 来高效管理计算容量以降低成本。

重要

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