如何将AWS DMS的数据变更路由到AWS Kinesis指定分片

首先明确：Kinesis 不支持直接指定分片写入，路由完全由partition_key的SHA-256哈希值（取前128位十进制）与分片的哈希范围匹配决定。但可以通过精准控制partition_key的哈希分布实现你要的"前20表进分片1，后20表进分片2"的效果，或者用更稳妥的分流方案。

方案1：通过DMS自定义Partition Key实现哈希路由（推荐，无额外组件） #

步骤1：锁定Kinesis流分片并获取哈希范围 #

1. 确保你的Kinesis流固定为2个分片（后续绝对不能增减分片，否则哈希范围会重新分配，路由规则失效）
2. 执行AWS CLI命令获取分片的哈希范围：

   aws kinesis describe-stream --stream-name your-stream-name
   

   返回结果的Shards数组中，每个分片会有HashKeyRange字段，示例：
   • 分片1：{ "StartingHashKey": "0", "EndingHashKey": "170141183460469231731687303715884105727" }
   • 分片2：{ "StartingHashKey": "170141183460469231731687303715884105728", "EndingHashKey": "340282366920938463463374607431768211455" }

步骤2：为DMS配置自定义Partition Key #

DMS的Kinesis目标端点支持自定义partition_key，配置方式如下：

1. 在DMS目标端点的ExtraConnectionAttributes中添加：

   partition-key-type=custom;partition-key=${TABLE_NAME}_<固定前缀>
   

2. 提前计算两个固定前缀的哈希值，确保：
   • 前20张表用的前缀（比如shard1），拼接表名后的哈希值落在分片1的哈希范围内
   • 后20张表用的前缀（比如shard2），拼接表名后的哈希值落在分片2的哈希范围内
   • 测试验证：用aws kinesis put-record指定测试partition_key，查看写入的分片：

     aws kinesis put-record --stream-name your-stream-name --data "test" --partition-key "table1_shard1"
     

     再通过aws kinesis get-shard-iterator和aws kinesis get-records确认分片归属

方案2：拆分DMS任务与Kinesis流（更稳妥，无哈希依赖） #

如果不想依赖Kinesis的哈希规则，直接拆分资源：

• 创建2个独立的Kinesis流，每个流仅配置1个分片
• 创建2个DMS任务：
  • 任务1：仅捕获前20张表的变更，推送到第一个Kinesis流
  • 任务2：仅捕获后20张表的变更，推送到第二个Kinesis流
• 两个消费应用分别读取对应Kinesis流的数据

这个方案完全规避了哈希路由的不确定性，后续维护更简单，适合表分组固定的场景。

关键注意事项 #

• 方案1中，一旦修改Kinesis流的分片数，之前的路由规则会完全失效，必须重新计算哈希范围和partition key
• DMS的${TABLE_NAME}变量会自动替换为当前变更的表名，确保同一张表的所有变更进入同一个分片（符合Kinesis的顺序性要求）

内容的提问来源于stack exchange，提问作者Agilan Selvam