如何可靠地批处理 Lambda 消耗的 S3 通知？

Question

我们需要一个 Lambda 来批处理在不一致的时间基础上进入 S3 的文件集。 Lambda 每小时运行一次，需要处理自上次执行以来进入 S3 的所有文件。将文件一起处理很重要，并且不要遗漏新文件也很重要。我们无法控制文件何时到达（外部方）。

选项一

将 S3 通知直接提供给 Lambda。这会导致高 Lambda 并发性，并且不适用于单个 Lambda 需要处理多个不同文件的应用程序。它不适合我们需要由同一个 Lambda 处理的全套最新文件的用例。

选项2

将 S3 通知馈送到 SQS 并让 Lambda 轮询 SQS 以获取批量文件。如果您需要有效地可靠地“清理”SQS，这就不太适用了。 SQS 倾向于仅在轮询时返回队列中的随机事件集，即使只有少数事件。例如，MaxNumberOfMessages=10（最大值）和 WaitTimeSeconds=20（最大值，保证任何大于 0 的数字将强制 SQS 检查所有节点）的 SQS 轮询不会可靠地返回所有事件，如果少于 10队列中的事件。

选项3

将 S3 通知馈送到第二个 Lambda，该 Lambda 将记录存储在 DynamoDB 中。然后，主要的 Lambda 函数对 Dynamo 执行计划查询，以查找 S3 中现在存在的所有最新文件。将所有这些服务捆绑在一起以获得如此基本的东西对我来说似乎太荒谬了。另外，如果你有很多文件，突然间 Dynamo 查询就很难优化了。

选项4

某种复杂的 S3 查询过滤文件创建时间（每个新文件应该是唯一的）来创建这个文件批次。我只是隐约听说过 S3 Select，我不确定这是否是正确的用法。

什么是好的设计？