在实践中(非理论),小批量与实时流之间有什么区别？

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

Spark迷你批量模型 - 正如之前的答案所写 - 缺点,对于每个小批量,必须创建新的工作.

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

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

在这种情况下,延迟非常小.

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

如前所述,微批和实时流的用例不同:

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

有关结构化流的更多详细信息,请查看此博客文章

Answer 3

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

我将尝试回答这部分：

为什么以 1 毫秒的延迟运行小批量没有效果？

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

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

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