在火花流中，我们设置批次间隔以进行近乎实时的微量分批处理。在Flink（DataStream）或Storm中，流是实时的，所以我猜没有批处理间隔的概念。
在kafka中，消费者正在拉动，我想Spark使用批处理间隔参数从Kafka经纪人那里取出消息，那么Flink和Storm如何做呢？我想Flink和Storm在快速循环中拉出Kafka消息以形成实时流源，如果是这样的话，如果我将Spark批处理间隔设置为小，如100ms，50ms甚至更小，我们是否在Spark之间有显着差异流媒体和Flink或风暴？
同时，在Spark中，如果流数据量很大且批处理间隔太小，我们可能会遇到有很多数据需要处理的情况，因此我们会看到OutOfMemmory发生了变化。会不会发生在Flink或Storm？
我已经实现了一个应用程序来进行主题到主题的转换，转换很容易，但源数据可能很大（考虑到它是一个IoT应用程序）。我的原始实现由reactive-kafka支持，它在我的独立Scala / Akka应用程序中运行良好。我没有实现要集群的应用程序，因为如果我需要它，Flink / Storm / Spark已经存在。然后我找到了Kafka Stream，对我而言，它与客户端使用方面的反应式akka类似。因此，如果我在独立应用程序或微服务中使用Kafka Stream或reactive-kafka，我们是否必须关注客户端代码的可靠性/可用性？
答案 0 :(得分：12)
您对微批次与流处理的理解是正确的。你也是对的，所有三个系统都使用Kafka提供的标准Java使用者来提取数据，以便在无限循环中进行处理。
主要区别在于，Spark需要为其处理的每个微批量安排新作业。这种调度开销非常高，因此Spark无法有效地处理非常低的批处理间隔，如100ms或50ms，因此这些小批量的吞吐量会下降。
Flink和Storm都是真正的流媒体系统，因此在启动时仅部署作业一次（并且作业持续运行直到用户明确关闭），因此他们可以处理每个单独的输入记录而无需开销和极低的延迟
此外，对于Flink，JVM主内存不受限制，因为如果可用主内存太小，Flink可以使用头外内存以及写入磁盘。 （顺便说一句：自项目Tungsten以来的Spark，也可以使用堆外内存，但它们可以在某种程度上溢出到磁盘 - 但与Flink AFAIK不同）。 Storm，AFAIK既不会也不会限制JVM内存。
我不熟悉被动的卡夫卡。
对于Kafka Streams，它是一个完全容错，有状态的流处理库。它是微服务开发的设计（您不需要像Flink / Storm / Spark那样的专用处理集群），但可以在任何地方以任何方式部署您的应用程序实例。您只需启动更多实例即可扩展应用程序。查看文档以获取更多详细信息：http://docs.confluent.io/current/streams/index.html（在Confluent博客中还有关于Kafka Streams的有趣帖子：http://www.confluent.io/blog/）