我正在编写一个Spark Streaming应用程序，其中将输入数据小批量地放入S3存储桶中（使用数据库迁移服务-DMS）。 Spark应用程序是唯一的使用者。我正在考虑两种可能的体系结构：
第二种解决方案可以工作时，第一种解决方案更简单。但是有陷阱吗？在查看this guide时，我担心两点：
目录下的文件越多，扫描更改所需的时间就越长-即使未修改任何文件。
我们将无限期保留S3数据。因此，要监视的前缀下的对象数量将迅速增加。
“完整”文件系统（例如HDFS）倾向于在创建输出流后立即对其文件设置修改时间。当打开文件时，甚至在数据完全写入之前，它也可能包含在DStream中-之后，将忽略同一窗口中对该文件的更新。也就是说：更改可能会丢失，流中会省略数据。
我不确定这是否适用于S3，因为据我了解，对象是原子创建的，之后无法像普通文件那样进行更新。
答案 0 :(得分：0)
我将此邮件发布到了Spark邮件列表，并得到了史蒂夫·拉夫兰（Steve Loughran）的好评。
对于云流，有一个稍微优化的流源 这里
即使如此，扫描S3的成本是每5000个对象一个LIST请求； 我会把它留给你，算出你的数量 应用程序-以及要花费多少。当然，更多清单 通话时间越长，窗户所需的空间就越大 成为。
“完整”文件系统（例如HDFS）倾向于在创建输出流后立即对其文件设置修改时间。当文件是 打开，即使在数据完全写入之前，也可能是 包含在DStream中-之后更新到 同一窗口将被忽略。也就是说：更改可能会丢失，并且数据 从流中删除。
在上传完成后，写入S3的对象才可见。 原子操作。您可以就地书写而不必担心。
S3工件上的时间戳记来自PUT tim。在多部分 上传许多MB /许多GB的内容，也就是第一篇文章发表到 启动MPU。因此，如果上传在时间窗口内开始 t1并在窗口t2中完成，该对象直到t2才可见， 但时间戳记为t1。记住这一点。
lambda回调可能确实具有更好的可伸缩性，并且 弹性;我自己没有尝试过。
由于我的方案中的对象数量将远远大于5000，并且将继续快速增长，因此从S3到Spark似乎不是一个可行的选择。我确实考虑过在Spark Streaming中移动/重命名已处理的对象，但是Spark Streaming应用程序代码似乎只接收DStream，而没有有关数据来自哪个S3对象的信息。因此，我将使用Lambda和Kinesis选项。