分库分表数据同步方案与实践
内容提要
本文介绍了将Amazon Aurora MySQL的分库/分表数据同步到Amazon Redshift的方案和操作，包括使用AWS DMS直接同步和利用zero-ETL特性。还介绍了使用AWS DMS、Amazon MSK和AWS Glue进行数据同步的方案，并展示了数据同步的效果和性能。
延伸解读
zero-ETL 在分库分表场景的局限
文章指出，虽然 Aurora 与 Redshift 的 zero-ETL 特性可以无缝同步数据，但它目前不支持转换操作，Aurora 中的物理表会原样同步到 Redshift。在分库分表场景下，一张逻辑表分散在多个物理表中，zero-ETL 无法自动合并，仍需后续整合才能形成统一业务表。因此，对于需要将分库分表数据映射到单一目标表的场景，zero-ETL 并非完美方案，读者需评估是否接受额外的整合步骤。
DMS 直接同步的调优要点
使用 AWS DMS 直接同步到 Redshift 时，DMS 默认启用 Batch Apply，并可通过 Parallel Apply 多线程提升 CDC 性能。文章建议调整 MaxFileSize、BatchApplyTimeoutMin/Max、ParallelApplyThreads 等参数。例如，提高 BatchApplyTimeoutMax 可减少提交次数、提升吞吐，但会增加数据延迟。读者需在吞吐和延迟之间权衡，并根据复制实例内存调整 BatchApplyMemoryLimit，避免溢写磁盘。
DMS+MSK+Glue 方案的灵活性与代价
第二种方案通过 DMS 将 CDC 数据写入 Amazon MSK，再由 Glue 运行 Spark Streaming 程序解析并写入 Redshift。该方案利用 Kafka 高吞吐缓冲变更压力，且可在 Spark 程序中自由控制处理逻辑，如忽略删除操作或转换数据。但需自行编写和维护代码，并注意 Kafka 目标默认不支持 Batch Apply，需通过 Parallel Apply 等参数调优。适合需要灵活处理逻辑且能承担开发成本的场景。
实测性能与延迟参考
文章通过实践测试了两种方案：使用 dms.c5.2xlarge 复制实例和 8 RPU Serverless Redshift，在 100 个 Go 协程并发下 3 分钟执行 100 万次变更。DMS 直接同步方案中，目标延迟稳定在 150 秒内，CDC 目标吞吐最高 7000 行/秒，端到端延迟 60-120 秒。这些数据可作为读者评估自身场景的参考，但实际性能受数据特征、实例规格和配置影响，需结合自身环境测试。
Q&A
什么是分库分表数据同步方案？
分库分表数据同步方案是将分散存储在多个数据库和表中的数据高效整合到数据仓库中，如将Amazon Aurora MySQL的数据同步到Amazon Redshift。
如何使用AWS DMS进行数据同步？
可以通过AWS DMS直接将数据从业务数据库同步到Amazon Redshift，支持全量和增量数据同步，并可自定义选择和转换规则。
zero-ETL特性在数据同步中有什么限制？
zero-ETL特性虽然可以方便地将Aurora数据同步到Redshift，但不支持数据转换，需后续整合才能形成统一的业务表。
在高变更率场景下，如何优化数据同步性能？
可以使用AWS DMS的Batch Apply和Parallel Apply特性来提升数据同步性能，适当调整相关参数以优化吞吐率。
使用AWS DMS和Amazon MSK的组合方案有什么优势？
该组合方案可以利用Kafka的高吞吐特性，有效缓冲对Redshift的压力，并灵活控制数据处理逻辑。
如何在AWS Glue中创建和启动数据同步任务？
在AWS Glue中创建Glue Job后，可以通过AWS CLI命令启动任务，指定配置文件的S3路径和键。
