在实践中（而不是理论上），小批量和实时流媒体有什么区别？理论上，我理解mini-batch是指在给定的时间范围内进行批处理，而实时流处理更像是在数据到达时执行某些操作，但我最大的问题是，为什么不使用epsilon时间范围（比如一毫秒）的mini-batch，或者我想理解为什么一种方法比另一种方法更有效？
我最近遇到了一个例子，mini-batch（apachespark）用于欺诈检测，而real-timestreaming（apacheflink）用于欺诈预防。有人还评论说，mini-batches不是防止欺诈的有效解决方案（因为目标是防止交易发生），现在我想知道为什么mini-batches（spark）没有这么有效？为什么以1毫秒的延迟运行迷你批处理是无效的？批处理是一种无处不在的技术，包括操作系统和内核tcp/ip堆栈，在这些堆栈中，磁盘或网络中的数据确实被缓冲了，那么这里有什么令人信服的因素可以说一个比另一个更有效呢？
3条答案
按热度按时间cig3rfwq1#
我知道有一个答案被接受了，但我认为必须再说一个才能完全回答这个问题。我认为像“flink的实时流媒体更快/更好”这样的回答是错误的，因为这在很大程度上取决于你想做什么。
spark小批量模型的缺点是，每个小批量都必须创建新的作业。
但是，spark structured streaming的默认处理时间触发器设置为0，这意味着读取新数据的速度将尽可能快。这意味着：
一个查询开始
数据已到达，但第一次查询未结束
第一次查询结束，因此将立即处理数据。
在这种情况下，延迟非常小。
与flink相比，spark的一大优势是，它有统一的批处理和流式处理api，这是因为它采用了迷你批处理模型。您可以轻松地将批处理作业转换为流处理作业，将流处理数据与批处理中的旧数据连接起来。和Flink一起做是不可能的。flink也不允许您对接收到的数据进行交互式查询。
如前所述，微批量和实时流的用例不同：
对于非常小的延迟，flink或一些计算网格（如apacheignite）会很好。它们适用于延迟非常低的处理，但不适用于非常复杂的计算。
对于中等或更大的延迟，spark将有更统一的api，允许以批处理作业相同的方式进行更复杂的计算，这正是因为这种统一
有关结构化流媒体的更多详细信息，请参阅本文
taor4pac2#
这是我经常思考的问题，因为回答技术和非技术人员的问题总是很难。
我将试着回答这一部分：
为什么以1毫秒的延迟运行迷你批处理是无效的？
我相信问题不在于模型本身，而在于spark如何实现它。实验证明，过多地减小小批量窗口会导致性能下降。事实上，有一个建议的时间至少0.5秒或以上，以防止这种退化。在很大的体量上，甚至这个窗口也太小了。我从来没有机会在生产中测试它，但我从来没有一个强大的实时性要求。
我对flink比spark更了解，所以我对它的内部结构不是很了解，但我相信，如果批处理至少需要几秒钟的时间来处理，那么在批处理过程的设计中引入的开销是无关紧要的，但是如果它们引入了固定的延迟，并且你不能低于这个延迟，那么开销就会变得很大。为了理解这些开销的本质，我认为您必须深入研究spark文档、代码和公开问题。
业界现在承认，需要一种不同的模式，这就是为什么现在许多“流媒体优先”引擎正在增长，flink是领跑者。我不认为这只是流行语和炒作，因为这种技术的用例，至少目前是非常有限的。基本上，如果您需要对大而复杂的数据进行实时自动化决策，那么您需要一个实时快速的数据引擎。在任何其他情况下，包括近实时，实时流是一个过度杀伤力和小批量是罚款。
lymnna713#
免责声明：我是ApacheFlink的提交者和pmc成员。我对spark streaming的总体设计很熟悉，但不知道它的内部细节。
spark streaming实现的小批量流处理模型的工作原理如下：
流的记录收集在缓冲区（小批量）中。
定期使用常规spark作业处理收集的记录。这意味着，对于每个小批量，一个完整的分布式批处理作业被调度和执行。
作业运行时，将收集下一批的记录。
那么，为什么每1ms运行一个小批量是无效的呢？因为这意味着每毫秒就要安排一个分布式批处理作业。尽管spark在调度作业方面非常快，但这会有点过分。这也会大大降低可能的吞吐量。如果oss或tcp中使用的批处理技术的批处理变得太小，那么它们也不能很好地工作。