# 将 DynamoDB Streams 中的分片和指标与 Kinesis Data Streams 配合使用
<a name="kds_using-shards-and-metrics"></a>

## Kinesis Data Streams 的分片管理注意事项
<a name="kds_using-shards-and-metrics.shardmanagment"></a>

Kinesis 数据流以[分片](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html)形式计算其吞吐量。在 Amazon Kinesis Data Streams 中，您可以为数据流选择**按需**模式和**预置**模式。

如果您的 DynamoDB 写入工作负载变化很大且不可预测，我们建议您对 Kinesis Data Streams 使用按需模式。若采用按需模式，则无需容量规划，因为 Kinesis Data Streams 会自动管理分片来提供必要的吞吐量。

对于可预测的工作负载，您可以为 Kinesis Data Streams 使用预置模式。若采用预置模式，您必须为数据流指定分片数，以容纳 DynamoDB 的更改数据捕获记录。要确定 Kinesis 数据流支持 DynamoDB 表所需的分片数量，您需要以下输入值：
+ DynamoDB 表记录的平均大小，以字节为单位 (`average_record_size_in_bytes`)。
+ 每秒对 DynamoDB 表执行的最大写入操作数。这包括由您的应用程序执行的创建、删除和更新操作以及自动生成的操作，例如“生存时间”生成的删除操作（`write_throughput`）。
+ 您对表执行的更新和覆盖操作与创建或删除操作相比的百分比 (`percentage_of_updates`)。请注意，更新和覆盖操作会将已修改项目的旧镜像和新镜像复制到流中。这会生成两倍 DynamoDB 项目大小。

可使用以下公式中的输入值来计算 Kinesis 数据流所需的分片数量（`number_of_shards`）。

```
number_of_shards = ceiling( max( ((write_throughput * (4+percentage_of_updates) * average_record_size_in_bytes) / 1024 / 1024), (write_throughput/1000)), 1)
```

例如，您的最大吞吐量为 1040 个写入操作/秒（`write_throughput`），平均记录大小为 800 字节（`average_record_size_in_bytes)`）。如果这些写入操作中有 25% 是更新操作（`percentage_of_updates`），则将需要两个分片（`number_of_shards`）来容纳您的 DynamoDB 流式传输吞吐量：

```
ceiling( max( ((1040 * (4+25/100) * 800)/ 1024 / 1024), (1040/1000)), 1).
```

在使用公式计算 Kinesis 数据流在预置模式下所需的分片数之前，请考虑以下几点：
+ 此公式有助于估算容纳 DynamoDB 更改数据记录所需的分片数量。它不代表 Kinesis 数据流中所需的分片总数，例如支持额外 Kinesis 数据流使用者所需的分片数量。
+ 如果您未将数据流配置为处理峰值吞吐量，则在预置模式下仍可能遇到读写吞吐量异常的问题。在这种情况下，您必须手动扩展数据流以适应数据流量。
+ 此公式考虑了 DynamoDB 在将更改日志数据记录流式传输到 Kinesis 数据流之前产生的额外膨胀。

要了解有关 Kinesis 数据流容量模式的更多信息，请参阅[选择数据流容量模式](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-size-a-stream.html)。要详细了解不同容量模式之间的定价差异，请参阅 [Amazon Kinesis Data Streams 定价](https://aws.amazon.com/kinesis/data-streams/pricing/)。

## 使用 Kinesis Data Streams 监控更改数据捕获
<a name="kds_using-shards-and-metrics.monitoring"></a>

DynamoDB 提供多个 Amazon CloudWatch 指标，帮助您监控将更改数据捕获到 Kinesis 的复制。有关 CloudWatch 指标的完整列表，请参阅[DynamoDB 指标与维度](metrics-dimensions.md)。

我们建议您在流启用期间和生产中监视以下项目，以确定流是否有足够的容量：
+ `ThrottledPutRecordCount`：由于 Kinesis Data Streams 容量不足而受到 Kinesis 数据流限制的记录数量。异常使用高峰期间可能会遇到一些限制，但 `ThrottledPutRecordCount` 应保持尽可能低。DynamoDB 重试将受限制的记录发送到 Kinesis 数据流，这可能会导致更高的复制延迟。

  如果遇到过多和定期的限制，则可能需要按照观察到的表写入吞吐量成比例增加 Kinesis 流分片数量。要了解有关如何确定 Kinesis 数据流的大小的详细信息，请参阅[确定 Kinesis Data Streams 的初始大小](https://docs.aws.amazon.com/streams/latest/dev/amazon-kinesis-streams.html#how-do-i-size-a-stream)。
+ `AgeOfOldestUnreplicatedRecord`：从等待复制的最早的项目级别更改，到 Kinesis 数据流出现在 DynamoDB 表中经过的时间。在正常运行情况下，`AgeOfOldestUnreplicatedRecord` 应该以毫秒为单位。如果失败的尝试由客户控制的配置选项造成，失败的复制尝试次数会增加。

   如果 `AgeOfOldestUnreplicatedRecord` 指标超过 168 小时，则将自动禁用从 DynamoDB 表到 Kinesis 数据流的项目级别更改的复制。

  例如，可能导致复制尝试失败的客户控制配置包括：预置不足的 Kinesis 数据流容量导致过度限制，或者手动更新 Kinesis 数据流的访问策略阻止 DynamoDB 向数据流添加数据。您可能需要确保预置合适的 Kinesis 数据流容量，并确保未更改 DynamoDB 的权限，才能将该指标保持在尽可能低的水平。
+ `FailedToReplicateRecordCount`：DynamoDB 无法复制到 Kinesis 数据流的记录数。某些大于 34KB 的项目可能会扩增，以更改大于 Kinesis Data Streams 1MB 项目大小限制的数据记录。当大于 34KB 的项目包含大量布尔值或空属性值时，就会出现此扩增现象。布尔值和空属性值在 DynamoDB 中存储为 1 个字节，但在使用标准 JSON 进行 Kinesis Data Streams 复制时，最多可扩展到 5 个字节。DynamoDB 无法将此类更改记录复制到 Kinesis 数据流中。DynamoDB 跳过这些更改数据记录，并自动继续复制后续记录。

   

您可以创建 Amazon CloudWatch 警报，以便在上述任何指标超过特定阈值时发送 Amazon Simple Notification Service (Amazon SNS) 消息，以便发送通知。