在实践中，小批处理和实时流有什么区别(不是理论)？

Question

在实践中，小批处理和实时流有什么区别(不是理论)？理论上，我理解迷你批处理是在给定的时间范围内批处理的，而实时流更像是在数据到达时做一些事情，但我最大的问题是为什么不使用带有epsilon时间框架的小批处理(例如1毫秒)，或者我想了解为什么一个小批处理比其他的解决方案更有效？

我最近遇到了一个例子，其中迷你批处理(Apache )用于欺诈检测，实时流(Apache )用于预防欺诈。还有人评论说，迷你批处理并不是防止欺诈的有效解决方案(因为目标是防止事务发生)，现在我想知道为什么对于小型批处理(Spark)来说，这不会那么有效？，为什么运行1毫秒延迟的小批处理无效？批处理是一种到处使用的技术，包括操作系统和内核TCP/IP协议栈，其中磁盘或网络的数据确实被缓冲了，那么有什么令人信服的因素可以说其中一个比另一个更有效呢？

Answer 1

免责声明:我是Apache的提交者和PMC成员。我很熟悉星火流的总体设计，但不知道它的内部细节。

由火花串流实施的小型批处理模式如下：

• 流的记录在缓冲区(小批处理)中收集.
• 定期使用定期星火作业处理收集的记录。这意味着，对于每一个小批，一个完整的分布式批处理作业被调度和执行.
• 当作业运行时，将收集下一批的记录。

那么，为什么每1ms运行一次小批量就没有效果呢？这仅仅是因为这意味着每毫秒安排一个分布式批处理作业。尽管Spark在调度作业方面非常快，但这可能有点过了。它还将大大减少可能的吞吐量。OSs或TCP中使用的批处理技术在批处理变得太小时也不能很好地工作。

Answer 2

我知道有一个答案是被接受的，但我认为必须再说一个，才能完全回答这个问题。我认为“Flink的实时速度更快/流更好”这样的回答是错误的，因为这在很大程度上取决于您想要做什么。

火花迷你批处理模型有-它写在以前的答案-缺点，每一个小批，必须有新的工作创造。

但是，Spark结构化流的默认处理时间触发器设置为0，这意味着读取新数据的速度将尽可能快。这意味着：

1. 一个查询开始
2. 数据到了，但是第一次查询没有结束
3. 第一次查询结束，因此数据将立即处理。

在这种情况下，延迟非常小。

与Flink相比，Spark拥有用于批处理和流处理的统一API，这是因为这种小型批处理模型。您可以轻松地将批处理作业转换为流作业，将流数据与批处理中的旧数据连接起来。用Flink做这个是不可能的。Flink也不允许您对收到的数据执行交互式查询。

如前所述，对于微批和实时流，用例是不同的：

1. 对于非常小的延迟，Flink或一些计算网格(如Apache )将是很好的。它们适用于低延迟的处理，但不适用于非常复杂的计算。
2. 对于中等和较大的延迟，Spark将有更统一的API，它将允许执行更复杂的计算，就像完成批处理任务一样，就因为这种统一

有关结构化流的详细信息，请参阅这篇博客文章

Answer 3

这是我想了很多的事情，因为对技术人员和非技术人员的回答总是很难确定。

我将试着回答这一部分：

为什么运行1毫秒延迟的小批处理无效？

我认为问题不在于模型本身，而在于星火如何实现它。这是一个经验性的证据，减少了小批量窗口太多，性能下降.事实上，为了防止这种退化，建议的时间至少为0.5秒或更长。在大容量上，就连这个窗口也太小了。我从来没有机会测试它的生产，但我从来没有一个很强的实时性要求。

我比Spark更了解Flink，所以我不太清楚它的内部结构，但是我相信在批处理过程的设计中引入的开销是无关的，如果您的批处理至少需要几秒钟的时间，但是如果它们引入了固定的延迟，那么就会变得很重，而您不能低于这一点。要了解这些间接费用的性质，我认为您必须深入了解火花文档、代码和未解决的问题。

该行业现在承认，需要一个不同的模式，这就是为什么许多“流媒体优先”引擎现在正在增长，Flink是领跑者。我不认为这只是一个时髦的词和炒作，因为这种技术的用例，至少目前来说，是非常有限的。基本上，如果您需要对大而复杂的数据进行实时的自动化决策，那么您需要一个实时的快速数据引擎。在任何其他情况下，包括几乎实时的，实时流媒体是一个过头和小批是好的。