像十批货依次进仓，每批却要同时登记四本账：收货顺序清楚，不代表四本账都能同步更新。近日一位数据工程师在 Reddit 分享了类似难题：团队用 S3 Tables 搭建分层数据集市——面向特定业务整理的数据集合——白天持续接收增量文件，并希望按抵达顺序处理。
他们用 FIFO SQS（尽量保持消息先入先出的队列）每次交给 Lambda 处理 10 个文件，再通过 PyIceberg 写入约 4 张表。一个客户一次送来 2000 个文件时，系统要执行 200 次 Lambda、约 800 次表写入，共耗时 40 分钟；读取、转换和业务逻辑每个文件只需毫秒级，时间主要花在追加写入。继续增加 Lambda 又会让多个任务同时改同一张表并报错。
问题的关键是：S3 Tables 托管的 Apache Iceberg 表靠元数据快照确认当前数据；一次提交成功后才整体可见，并发修改同一状态时可能冲突和重试。因此，队列保证取件顺序，并不自动保证四张表按业务顺序完成提交。这则帖子尚未给出优化结果，但把数据集市能否扩展的真正瓶颈指了出来：不只是读得快，还要设计写入批次、并发提交和下游的显式排序。