AWS上大型Excel文件批处理超时的架构优化方案咨询

现有架构从流程设计上就不支持百万级Excel批处理，超时是必然结果：

• 单节点串行处理全量文件：100万行Excel从S3拉取、解析、逐行处理全流程单线程跑，常规配置下耗时可达小时级，会直接触发S3事件通知回调超时、EC2进程运行超时、数据库长连接超时等多重限制
• 数据库交互效率极低：逐行操作多张表属于典型的N+1反模式，100万条记录对应数百万次数据库网络IO、事务提交开销，不仅处理速度慢，还极易打满数据库连接、触发慢查询导致流程中断
• 全量文件解析存在内存风险：多数Excel解析库默认将全量文件加载到内存，百万行级文件很容易触发进程OOM崩溃，进程重启后又会从头开始处理，陷入“跑一半崩溃、崩溃后重跑”的死循环

文件预处理层改造 #

• 废弃EC2直接监听S3事件拉取全量Excel处理的逻辑。S3产生新文件事件后，首先触发轻量Lambda做流式分片：使用支持只读流式解析的Excel处理库（如openpyxl的read_only模式），全程不把全量文件加载到内存，按2000行/片的粒度把原文件拆分为多个CSV格式小分片，回写到S3临时分片目录。2000行的分片大小可以保证单分片后续处理时长稳定在30秒-2分钟，完全不会触发各类超时阈值。
• 分片完成后，将每个分片的S3路径作为独立消息推送到SQS队列做解耦，彻底取消“单任务绑定全量文件”的逻辑，从根源上避免单任务运行时间过长的问题。

计算处理层改造 #

• 将原单EC2节点替换为EC2 Auto Scaling计算集群，或直接用Lambda函数消费SQS中的分片消息，根据队列积压量自动扩缩容计算节点，每个节点仅负责处理单个分片的小批量数据。
• 重构数据库交互逻辑，彻底移除逐行操作SQL的写法：
  • 单分片内的同表操作先在内存中做聚合，使用数据库原生批量语法执行操作，比如MySQL用INSERT ... ON DUPLICATE KEY UPDATE、PostgreSQL用COPY批量导入，将原来单条记录多次DB交互压缩为单分片每张表1-2次交互，数据库操作开销可降低两个数量级。
  • 单分片处理使用独立短事务，禁止跨分片开长事务持有数据库连接，分片处理完成后立刻释放连接，避免连接耗尽。
  • 给消费逻辑加幂等校验：以“分片S3路径+记录唯一主键”作为幂等键，避免节点异常重试导致重复写入数据。

数据库侧配套优化 #

• 批处理运行期间，暂时关闭涉及表的非必要二级索引、触发器，等全量数据写入完成后再统一重建，可将写入速度提升5-10倍。
• 给批处理任务单独配置数据库连接池，和线上业务请求的连接池完全隔离，避免批处理占满连接影响正常业务。
• 如果处理逻辑涉及多表关联更新，不要在分片处理过程中做实时关联：先把分片数据批量写入对应临时表，等所有分片处理完成后，再通过存储过程一次性做全量关联、合并操作，大幅减少运行期锁冲突。

• 每个分片处理完成后，在S3上对应分片路径打已处理标记。单独部署定时巡检任务，扫描生成超过1小时仍未打已处理标记的分片，重新推送到SQS队列重试，不需要全量重跑整个文件。
• 所有分片处理完成后做总数校验：比对原始Excel的有效记录总行数、数据库最终入库的记录数，差值在预期脏数据过滤范围内时，标记整个文件处理完成，否则触发告警人工介入。

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