在实践中，小批量与实时流之间有什么区别？（不是理论）？

Question

在实践中（非理论），小批量与实时流之间有什么区别？从理论上讲，我理解迷你批量是在给定的时间范围内批量生成的，而实时流式更像是在数据到达时做某事但是我最大的问题是为什么不使用epsilon时间框架（比如说一毫秒）或我我想理解为什么一个人会成为一个有效的解决方案呢？

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

Answer 1

免责声明：我是Apache Flink的提交者和PMC成员。我熟悉Spark Streaming的整体设计，但不详细了解它的内部结构。

Spark Streaming实现的小批量流处理模型的工作原理如下：

• 在缓冲区（小批量）中收集流的记录。
• 定期使用常规Spark作业处理收集的记录。这意味着，对于每个小批量，计划并执行完整的分布式批处理作业。
• 当作业运行时，将收集下一批的记录。

那么，为什么每1ms运行一次小批量生效无效？仅仅因为这意味着每毫秒安排一个分布式批处理作业。尽管Spark在调度工作中速度非常快，但这有点太多了。它还会显着降低可能的吞吐量。操作系统或TCP中使用的批处理技术如果批量变得太小也不能很好地工作。

Answer 2

我知道有一个答案被接受了，但我想还有一个答案要完全回答这个问题。我认为像“Flink的实时更快/更好的流媒体”这样的回答是错误的，因为它很大程度上取决于你想做什么。

Spark mini-batch模型 - 正如之前的答案所写 - 不利于每个小批量创建必须创建新作业。

但是，Spark Structured Streaming的默认处理时间触发器设置为0 ，这意味着尽可能快地读取新数据。 这意味着：

1. 一个查询开始
2. 数据已到达，但第一次查询未结束
3. 第一个查询已结束，因此将立即处理数据。

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

与Flink相比，一个很大的优势是Spark具有统一API 用于批处理和流处理，因为这种小批量模型。您可以轻松地将批处理作业转换为流作业，使用批处理的旧数据加入流数据。无法使用Flink。 Flink也不允许您对收到的数据进行交互式查询。

如前所述，微批次和实时流式传输的用例不同：

1. 对于非常小的延迟，Flink或一些计算网格，如Apache Ignite，会很好。它们适用于具有极低延迟的处理，但不适用于非常复杂的计算。
2. 对于中等和较大的延迟，Spark将拥有更多统一的API，允许以与完成批处理作业相同的方式执行更复杂的计算，仅仅因为这种统一

有关结构化流媒体的更多详情，请查看this blog post

Answer 3

这是我想的很多，因为技术和非技术人员的答案总是难以制定。

我将尝试回答这一部分：

  

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

我认为问题不在于模型本身，而在于Spark如何实现它。经验证据表明，减少小批量窗口太多，性能下降。事实上，建议的时间至少为0.5秒或更长，以防止这种降解。在大卷上，即使这个窗口尺寸太小。我从来没有机会在生产中测试它，但我从未有过强大的实时要求。

我知道Flink比Spark更好，所以我真的不太了解它的内部结构，但我相信如果您的批处理需要至少几秒钟才能处理，那么批处理过程中引入的开销是无关紧要的如果它们引入了固定的延迟并且你不能低于它那么重。为了理解这些开销的性质，我认为你将不得不深入研究Spark文档，代码和开放问题。

业界现在承认需要一个不同的型号，这就是为什么许多“流媒体优先”引擎正在发展，Flink作为领跑者。我不认为这只是流行语和炒作，因为这种技术的使用案例，至少在目前，是非常有限的。基本上，如果您需要在大型复杂数据上实时做出自动化决策，您需要一个实时快速数据引擎。在任何其他情况下，包括近实时，实时流是一种矫枉过正，小批量是好的。