把 RDS MySQL 数据入仓 Amazon Redshift 的三种方式 · 首推 Zero-ETL
内容提要
本文介绍将RDS MySQL数据同步至Amazon Redshift的三种方式：S3+COPY批量加载、AWS Glue ETL微批处理、Zero-ETL近实时集成。重点推荐Zero-ETL，因其零代码、全托管、延迟约1分钟且支持完整CDC（含删除操作）。文章对比三种方案的架构、成本、运维和延迟，并提供选型建议：持续同步选Zero-ETL，复杂转换用Glue，一次性导入用S3+COPY。
延伸解读
网络架构是方案选型的关键前提
三种方案都假设源库、跳板机和Redshift位于同一VPC私有子网且不对公网开放。这一前提直接影响方案可行性：S3+COPY需借助同VPC的EC2通过SSM导出数据；Glue连接必须放在私有子网并配置NAT，否则会因无法访问STS而失败；Zero-ETL则完全托管，无需考虑网络打通。理解这一前提有助于避免在实际部署中因网络配置不当导致同步失败。
增量同步能力差异显著
三种方案在增量同步上差异明显：S3+COPY无增量机制，只能全量重导；Glue依赖Job Bookmark实现分钟级增量，但无法捕获源库的物理删除操作；Zero-ETL基于binlog实现近实时同步，延迟约1分钟，且完整支持INSERT、UPDATE、DELETE。若业务对数据删除敏感或需要实时性，Zero-ETL是更合适的选择。
Zero-ETL的适用边界与注意事项
Zero-ETL虽零代码、全托管，但并非万能：它不支持复杂转换，需将转换后置到Redshift；源表必须有主键，否则会被静默跳过；创建集成有一次性编排耗时，与数据量无关。此外，建库需使用Admin用户，且目标端需开启大小写敏感标识符。了解这些限制有助于合理评估是否采用Zero-ETL。
Q&A
如何将RDS MySQL数据同步到Amazon Redshift？
有三种方式：S3+COPY批量加载、AWS Glue ETL微批处理、Zero-ETL近实时集成。其中Zero-ETL是推荐的首选方案。
Zero-ETL集成相比其他方式有什么优势？
Zero-ETL集成是完全托管的近实时复制，零代码、无需维护计算资源，延迟约1分钟，支持完整的CDC（包括删除操作），成本模型简单。
使用S3+COPY方式导入数据时需要注意哪些坑？
需要注意：必须显式写列清单并设置IGNOREHEADER 1，否则可能导致列错位；目标表id列不要用IDENTITY，否则COPY会跳过该列；如果VPC启用了Enhanced VPC Routing，需要配置S3 Gateway Endpoint避免NAT瓶颈。
AWS Glue ETL同步RDS MySQL到Redshift时，网络配置有什么要求？
Glue连接必须放在私有子网并配置NAT，否则会因无法访问STS而失败。另外，Redshift的安全组需要放行Glue安全组的5439端口。
Zero-ETL集成的前置条件有哪些？
源库需启用自动备份，binlog_format设为ROW且binlog_row_image设为full，被同步的表必须有主键，Redshift需开启大小写敏感，并配置命名空间资源策略授权。
三种同步方式的延迟和CDC能力有何区别？
S3+COPY是手工批量，延迟小时级，无增量；Glue ETL是分钟级微批，支持Bookmark增量但不捕获DELETE；Zero-ETL是近实时约1分钟，支持完整CDC包括DELETE。
如何选择适合的同步方案？
持续近实时同步选Zero-ETL；需要复杂转换或多源整合用Glue ETL；一次性或冷数据导入用S3+COPY。也可以组合使用，如Zero-ETL同步原始表，Redshift内做转换。
