在本篇文章中，我们将探讨如何通过 AWS 数据库迁移服务AWS DMS有效地优化 Amazon Kinesis Data Streams 的数据复制性能。我们将重点关注多线程的全量加载和变更数据捕获CDC设置，以提高这里所提及的相关参数的性能。
AWS DMS 使从关系数据库、数据仓库、NoSQL 数据库等多种数据存储转移至 Amazon Kinesis Data Streams 成为可能。通过 Kinesis 数据流，可以实时收集和处理大量数据记录。复制数据更改至 Kinesis 数据流通常会持续很长时间且需要高性能。AWS DMS 提供了多线程的全量加载和变更数据捕获CDC任务设置，以增加数据传输速度和CDC性能。
用户在优化 Kinesis Data Streams 目标端性能时，常会问以下问题：
在调整 ParallelLoad 和 ParallelApply 设置时需要考虑哪些因素？如何根据特定源数据库工作负载调整 AWS DMS 任务的 ParallelLoad 和 ParallelApply 参数？是否需要增加 Kinesis 数据流的分片数量以提高复制性能？本系列共有三部分。在第一部分中，我们将讨论多线程的全量加载和 CDC 设置，以及调优相关参数的考虑因素以便提高复制至 Kinesis Data Streams 目标的性能。在第二部分中，我们将提供 AWS DMS 在 Kinesis Data Streams 目标上的性能调优示范。在第三部分中，我们将分享使用 Kinesis Data Streams 作为目标的一些其他考虑和最佳实践。
AWS DMS 支持从任何支持的源全量加载和 CDC 到 Kinesis Data Streams 目标，过程通过 JSON 格式的属性值对进行。您可以使用AWS DMS 对象映射将数据从支持的数据源迁移到目标 Kinesis 数据流。每个 Kinesis 数据流由多个分片组成。您可以为 DMS 任务中的每个表定义一个分区键，Kinesis Data Streams 将利用此分区键将数据分组到其分片中。
在全量加载阶段，如下图所示，AWS DMS 将表并行加载到 Kinesis Data Streams 目标。并行加载的最大表数由 AWS DMS 任务设置 MaxFullLoadSubTasks 决定。AWS DMS 使用专用的子任务将每个表加载到相应的目标分片中。默认情况下，AWS DMS 并行加载八个表，最大可达49个表。在全量加载阶段，DMS 任务使用的默认分区键是 primarykey。您可以选择将 AWS DMS 对象映射参数 partitionkeytype 设置为 schematable，这意味着来自相同架构的相同表将加载到 Kinesis Data Streams 的同一分片中。
当在全量加载阶段使用并行加载设置或在 CDC 阶段使用并行应用设置时，AWS DMS 将以多线程方式加载数据并应用更改。您可以使用 AWS DMS 对象映射参数 partitionkeytype 来设置目标分区键。默认情况下，指定 ParallelLoad 或 ParallelApply 任务设置后，在全量加载或 CDC 阶段分别使用表的主键作为分区键。当全量加载阶段中的批量数据或 CDC 阶段中的连贯变更记录到达时，AWS DMS 会提取分区键并应用哈希函数以将消息分配到相应的并行加载或应用队列中。根据使用的分区键，特别是当键的统计分布不均衡时，某些队列可能会非常繁忙，而有些队列则相对空闲。如下一图所示，Qm(n1)1 达到饱和，而 Qm2 和 Qmm 是空的。每个缓冲队列中可以存储的最大记录数由全量加载阶段的 ParallelLoadBufferSize 和 CDC 阶段的 ParallelApplyBufferSize 指定。AWS DMS 使用多线程从并行加载或应用队列中轮询。线程的数量由全量加载阶段的 ParallelLoadThreads 和 CDC 阶段的 ParallelApplyThreads 确定。一个线程仅能专门从特定队列或队列组中进行轮询。为每个线程轮询的队列数量由 AWS DMS 任务设置 ParallelLoadQueuesPerThread 和 ParallelApplyQueuesPerThread 的数量确定。并行处理的总队列数为全量加载阶段的 ParallelLoadQueuesPerThread ParallelLoadThreads 和 CDC 阶段的 ParallelApplyQueuesPerThread ParallelApplyThreads。ParallelQueuesPerThread 决定每批的记录总数，以进行 PutRecords 到 Kinesis Data Streams 目标。
西部世界vqn有关并行加载和应用任务设置的更多信息，请参阅将 Amazon Kinesis Data Streams 用作 AWS 数据库迁移服务目标。
在本节中，我们将讨论并行加载和应用设置的关键考虑因素。
当数据通过 Kinesis Data Streams 从不同分片接收时，可能并不会保留严格的顺序。为了实现高性能，AWS DMS 使用 Kinesis 批量 PutRecords API 以及多线程。如果必须保留下列消息的顺序，可以考虑以下选项：
如果所有与相同主键相关的操作的顺序都很重要，请在 AWS DMS 对象映射中使用 schematable 的 primarykey，并指定 Kinesis 目标的一个分片，不使用并行加载或应用设置。通过这种方式，AWS DMS 以单线程的方式复制数据记录，保持与源数据库中相同主键相关事务的序列顺序，因此可以准确地复制到同一 Kinesis 分片。Kinesis Data Streams 对于 PutRecord API 限制为每秒 1000 TPS，每个分片每秒支持最高 1000 条写入，以及每秒最大数据写入总量为 1MB。详细信息请参见配额和限制。如果各个表的所有操作的顺序都很重要，请在 AWS DMS 对象映射中使用 schematable 的 partitionkeytype，并指定 Kinesis 目标的一个分片，而不使用并行加载或应用设置。这样，AWS DMS 将在单个线程中按相同的可序列化顺序复制数据记录到同一 Kinesis 分片，与源数据库中的相同表的事务保持一致。同时注意前面提到的 Kinesis 目标的容量，尤其是在源数据库负载很重的情况下。使用目标的端点设置 IncludeTransactionDetails，提供来自源数据库的详细事务信息。您可以利用日志位置和事务 ID 等信息来识别下游应用中消息的顺序。当源数据库高度事务化且使用并行加载和应用设置以提高性能时，此方法尤为合适。数据大小和事务速率决定了实现所需复制性能的并行度。在全量加载阶段，通常需要了解表的大小和记录的行数。在 CDC 阶段，您需要了解每秒的记录数，而不是每秒的事务数，因为一个事务可以包含许多记录。这些信息可用来指定 AWS DMS 的并行加载和应用设置，从而提升复制性能。
对于 Kinesis Data Streams 目标，每个分片提供固定的容量单元。您可以选择按需模式或预配置模式来处理数据流。如果您的数据速率发生变化，在预配置模式下，您可以增加或减少分配给数据流的分片数量。而在按需模式下，Kinesis Data Streams 将自动管理分片，以提供所需的吞吐量。Kinesis 目标的容量可能是复制性能的瓶颈，因此一定要确保配置足够数量的分片来承载更多并行处理。
分区键是决定目标的容量利用率的重要因素。根据源数据库中分区键的统计分布，某些分片可能会比其他分片较热。正如前面提到的，DMS 还利用该键将数据记录分配到并行加载和应用队列中。
与分区键相关的两种典型场景：
数据分布依据分区键异常，这使得少数分片可能极度拥堵。在这种情况下，您需要考虑其他的分区键，以便均匀地在分片之间分布数据。当使用分区键时，数据在分片中均匀分布。然而，源数据库的最大工作负载可能会超出 Kinesis 分片的吞吐能力。在这种情况下，您需要增加分片的数量，例如将当前分片数量的两倍，或者考虑使用按需模式来扩展 Kinesis 数据流的整体容量。通常情况下，您在 AWS DMS 的并行加载和应用设置中使用越多并行性，复制实例所需的资源就越多。在增加 MaxFullLoadSubTasks、ParallelLoad 和 ParallelApply 时，应提升复制实例的配置。一般规则是将 vCPU 数量与 MaxFullLoadSubTasks ParallelLoadThreads 和全量加载阶段并行运行的任务数量相匹配，以及 ParallelApplyThreads CDC 阶段并行运行的任务数量。或者，可以考虑使用AWS DMS 无服务器模式，该模式提供自动配置和扩展。同时，请密切注意AWS DMS 无服务器模式的当前限制。在调优 MaxFullLoadSubTasks、ParallelLoad 和 ParallelApply 时，仔细监控复制实例的资源利用率，例如 Amazon CloudWatch 指标 CPUUtilization、FreeableMemory 和 SwapUsage。
让我们探讨一个示例用例：
我们从 Amazon Aurora PostgreSQL 兼容版本 进行复制至 Kinesis Data Streams，使用 pglogical 进行 WAL 解码。工作负载模拟每秒 1600 条记录，记录大小为 1 KB。源数据库和复制实例之间没有资源争用。让我们看看如何为此用例指定并行应用设置。
首先，需要确定 AWS DMS 任务的 Kinesis Data Streams 目标所需的分片数量。您需要识别数据的分布情况以及根据分区键向每个分片投入的记录数量和大小。默认情况下，AWS DMS 使用源表的主键。
确定目标需要的分片数量后，您可以进而确定 AWS DMS 任务的 ParallelApply 设置。例如，假设第一步中我们为 Kinesis Data Streams 目标使用了八个分片，并且根据源数据库的主键数据在分片中均匀分布。通常情况下，您可以将 ParallelApplyThreads 设置为与分片数相乘的值。可以先从分片的初始数量开始，再根据需要进行调优。
如果假设复制实例与 Kinesis Data Streams 目标之间的平均往返时间为 20 毫秒，这就是每秒 50 次往返1000 毫秒/20 毫秒=50。您可以使用AWS DMS 诊断支持 AMI 或网络诊断命令如hping3 来测量复制实例与目标端点之间的往返时间。
此配置的公式如下：
ParallelApplyThreads ParallelApplyQueuesPerThread 复制实例与 Kinesis 数据流之间的每秒往返次数 gt= 来源数据库中更改的每秒记录数。
让我们比较两种设置假设每秒 50 次往返。
我们的初始设置如下：
ParallelApplyThreads = 分片数 = 8ParallelApplyQueuesPerThread = 4
在上述初始设置下，AWS DMS 将能够共同推送大约8 x 4 x 50 = 1600 条记录/秒，通过多个PutRecords API 调用。每次 PutRecords API 调用的限制为 5MB，这也对我们的复制吞吐量产生影响。5MB 的限制在我们的情况中是适用的。在我们的案例中，ParallelApplyQueuesPerThread 每条记录的大小 = 4 x 1 KB = 4 KB 在此限制内。
让我们看看不同设置如何影响我们的复制吞吐量：
ParallelApplyThreads = 16ParallelApplyQueuesPerThread = 1
使用此设置，AWS DMS 只能推送大约 16 x 1 x 50 = 800 条记录/秒。
第一种设置能满足从源工作负载复制 1600 条记录/秒的需求，而第二种设置即使线程数 (ParallelApplyThreads) 高于第一种设置，仍不足以满足，因为 ParallelApplyQueuesPerThread默认值为 1没有调优或设置太小。
基本假设是数据根据分区键均匀分布在分片中默认为源表的主键。如果由于数据暂时倾斜造成任何突发负载，需要调整 ParallelApplyThreads 和 ParallelApplyQueuesPerThread 以处理更大的负载。如果某个分片总是倾斜，请考虑更改分区键。同时，请注意源工作负载的有效载荷大小，其中多个指定队列会影响到 PutRecords API 调用的大小，限制为每次 PutRecords API 调用最多 5MB。
请牢记以下最佳实践：
在需要保留记录顺序时，考虑并行加载和应用设置是否适合您的特定用例。根据对源数据键的统计分布的理解，明智地选择 Kinesis Data Streams 的分区键。目标是将数据均匀分配到分片中。请勿使用源表中的任何唯一键，该键允许 AWS DMS 对象映射参数 partitionkeytype 或目标端点的分区键为 null。为目标选择合适的数据流容量模式，确保有足够的容量。通常情况下，CloudWatch 指标 WriteProvisionedThroughputExceeded 将在 Kinesis Data Streams 中激增，而 CDCIncomingChanges 和 CDCLatencyTarget 则在 AWS DMS 中会激增，表示目标容量可能成为瓶颈。根据更多的并行性，为复制实例进行调整，并考虑使用 AWS DMS 无服务器模式注意其 限制。在调优 MaxFullLoadSubTasks、ParallelLoad 和 ParallelApply 时，请密切监控 AWS DMS 的 CloudWatch 指标 CPUUtilization、FreeableMemory 和 SwapUsage。ParallelThreads 和 ParallelQueuesPerThread 必须根据源数据库中改变的记录数量一同调优。平衡批处理大小和线程数量效果更佳，而不应该是小批量但大量线程。当每个队列需要处理更多消息时，应增加 ParallelApplyBufferSize，或者某些并行加载和应用队列可能
