如何按列值拆分S3中的大CSV文件 评估Lambda方案适用性

针对你描述的1000万行、4字段列的大CSV按某列值分组拆分的场景，Lambda并不是该场景下的最优实现方案，核心原因和可选替代方案如下：

为什么不推荐直接用Lambda处理 #

• 受Lambda的原生硬限制约束：单函数最长运行时长15分钟，最大临时存储10GB，内存规格最高10GB。这类千万行级别的CSV如果要全量读入内存做分组聚合，一旦拆分后的临时文件占用过大、读写S3的吞吐打满函数限额，很容易出现超时、内存溢出、写限流的问题。
• 开发维护成本高：用Lambda实现拆分逻辑需要自己处理CSV流式解析、同组数据的缓冲攒写、大文件分片上传、失败重试、临时文件清理，整体代码量并不小，且没有弹性扩展能力，文件体量稍有增长就需要重新调整函数配置。
• 性价比偏低：为了避免内存溢出通常需要选用大内存规格的Lambda实例，按毫秒计费的模式算下来，处理该体量任务的成本远高于专用的无服务器ETL服务。

适配该场景的高性价比方案（按优先级排序） #

方案1：AWS Glue 无服务器ETL（最适配） #

• 实现逻辑极简单：基于PySpark只需要几行代码，直接读取S3上的源CSV，按目标分组列做groupBy聚合分区，即可将不同分组的行写出为独立CSV文件存储到S3指定路径。Spark引擎会自动处理内存分配、读写吞吐、分片上传、失败重试的全流程，完全不需要自己维护基础设施。
• 成本与时长适配：1000万行4列的数据集体量极小，选用基础规格的Glue worker几十秒就能跑完，单次任务成本仅几美分，完全不存在超时风险，还可配置S3事件触发，实现新文件自动拆分的流水线。

方案2：Amazon Athena 零代码实现 #

• 如果不想写任何ETL代码，直接基于Athena的建表语法定位到源CSV，再执行带分区的CTAS语句即可：指定目标分组列为分区字段，查询导出全量数据，执行完成后Athena会自动将不同分组的数据写入为独立CSV文件存到S3。
• 成本优势：该体量数据集的扫描量不到1GB，单次查询的费用不足1美元，整个流程不需要写任何代码。

方案3：Lambda的适用边界 #

• Lambda并非完全不可用，仅适合小体量场景：如果单源CSV小于100MB、分组取值不超过10个，Lambda的实现是轻量灵活的。
• 如果硬要针对1000万行的大文件用Lambda实现，必须重构逻辑：不要全量拉取文件到内存，要配合S3的分块读取能力，将大文件拆分为多个ByteRange分片，由多个Lambda并行处理各自的分片结果，再将同组的分片结果合并为最终文件，这种实现的开发复杂度极高，远不如直接用托管ETL服务划算。

注意：直接在Lambda内做全量文件读入再拆分的实现，一旦遇到分组列取值较多的场景，极高概率触发临时存储溢出、函数超时、S3写请求限流的故障。

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