从AWS Lambda Node.JS流式传输并压缩到S3

Question

我的目标是创建一个较大的压缩文本文件并将其放入S3。

文件内容由我从另一个源中循环读取的块组成。

由于该文件的大小，我无法在内存中保存所有数据，因此我需要以某种方式直接将其同时流式传输到S3和ZIP。

我了解如何使用fsNode.JS中的常规代码执行此技巧，但是我对于使用AWS Lambda的S3是否可以执行相同的技巧感到困惑？我知道s3.putObject 可以消耗 streamObject，但是在我看来，执行putObject操作时该流应该已经完成，这可能导致超出允许的内存。

Answer 1

您可以使用NodeJs aws-sdk中的分段上传功能将文件（> 5mb）分批流式传输到S3存储桶中。

这不仅有助于将大文件流式传输到存储桶，而且还使您能够重试失败的块（而不是整个文件）并并行化上传单个块（具有多个上载lambda），这对于以下情况的无服务器ETL设置很有用：例）。只要您跟踪它们并在全部上载后完成该过程，它们的到达顺序并不重要。

要使用分段上传，您应该：

1. 使用初始化过程createMultipartUpload并存储返回的UploadId（块上传需要使用它）
2. 实现转换流，该流将处理来自输入流的数据
3. 实现PassThrough流，该流将以足够大的块缓冲数据，然后再uploadPart用于将其推送到S3（在UploadId在步骤1中返回）
4. 跟踪返回的数据ETags和PartNumbers块上传的数据
5. 使用跟踪ETags并使用以下PartNumbers命令在S3上汇编/完成文件completeMultipartUpload

这是一个工作代码示例的要点，该示例从iso.org流式传输文件，将其通过gzip 传输到S3存储桶中。不要忘记更改存储桶名称，并确保在节点6.10上运行具有512mb内存的lambda。由于没有外部依赖性，因此可以直接在Web GUI中使用代码。

注意：这只是我为演示目的而汇总的概念证明。没有失败块重试的重试逻辑，错误处理几乎不存在，这可能会导致您付出代价（例如，abortMultipartUpload在取消整个过程以清理上载的块时，应调用它，因为它们在S3上仍保持存储且不可见，即使最终文件从未组装过）。输入流正在暂停，而不是排队上传作业并利用背压流机制等。