Spark Streaming 与 S3 对比 Kinesis

Question

我正在编写一个 Spark Streaming 应用程序，其中输入数据以小批量方式放入 S3 存储桶中（使用数据库迁移服务 - DMS）。 Spark 应用程序是唯一的消费者。我正在考虑两种可能的架构：

1. 让 Spark Streaming 监视 S3 前缀并在新对象出现时拾取它们 进来
2. 将数据从 S3 流式传输到 Kinesis 流（通过 DMS 创建新 S3 对象时触发的 Lambda 函数）并将流用作 Spark 应用程序的输入。

虽然第二种解决方案可行，但第一种解决方案更简单。但是有什么陷阱吗？看this guide，具体关注两点：

目录下的文件越多，扫描更改所需的时间就越长——即使没有文件被修改。

我们将无限期保留 S3 数据。所以被监控的前缀下的对象数量会很快增加。

“完整”文件系统（如 HDFS）倾向于在创建输出流后立即对其文件设置修改时间。打开文件时，即使在数据完全写入之前，它也可能包含在 DStream 中 - 之后在同一窗口中对文件的更新将被忽略。也就是说：可能会错过更改，并且可能会从流中省略数据。

我不确定这是否适用于 S3，因为据我了解，对象是原子创建的，并且不能像普通文件那样在事后更新。

Answer 1

我将其发布到 Spark 邮件列表，并从 Steve Loughran 那里得到了很好的答复。

有一个稍微优化的云流媒体源 这里

https://github.com/hortonworks-spark/cloud-integration/blob/master/spark-cloud-integration/src/main/scala/org/apache/spark/streaming/hortonworks/CloudInputDStream.scala

即便如此，扫描 S3 的成本是每 5000 个对象一个 LIST 请求； 我会留给你算出你里面有多少 应用程序——以及它将花费多少。当然，LIST 越多 调用 tehre，时间越长，您的窗口需要越大 成为。

“完整”文件系统（如 HDFS）倾向于在创建输出流后立即对其文件设置修改时间。当一个文件是 打开，甚至在数据完全写入之前，它可能是 包含在 DStream 中 - 之后更新到 DStream 中的文件 相同的窗口将被忽略。即：更改可能会丢失，而数据 从流中省略。

在上传完成之前，写入 S3 的对象不可见，在 原子操作。可以原地写，不用担心。

S3 工件上的时间戳来自 PUT 时间。在多部分 上传许多 MB/许多 GB 的上传，那是第一次发布到 启动 MPU 被启动。所以如果上传在时间窗口开始 t1 并在窗口 t2 中完成，该对象直到 t2 才可见， 但时间戳将是 t1。请记住这一点。

lambda 回调可能确实具有更好的可扩展性和 弹力;自己没试过。

由于我的场景中的对象数量将远大于 5000 并且将继续快速增长，S3 到 Spark 似乎不是一个可行的选择。我确实考虑过在 Spark Streaming 中移动/重命名已处理的对象，但 Spark Streaming 应用程序代码似乎只接收 DStreams 而没有关于数据来自哪个 S3 对象的信息。所以我将选择 Lambda 和 Kinesis 选项。