在实践中（不是理论上）小批量与实时流有什么区别？从理论上讲，我理解小批量是在给定时间范围内进行批处理的东西，而实时流更像是在数据到达时做一些事情，但我最大的问题是为什么没有具有 epsilon 时间范围（比如一毫秒）的小批量，或者我想了解为什么一个比另一个更有效的解决方案？
我最近遇到了一个示例，其中小批量 (Apache Spark) 用于欺诈检测和实时流 (Apache Flink) 用于欺诈预防。也有人评论说小批量不是预防欺诈的有效解决方案（因为目标是防止交易发生）现在我想知道为什么小批量（Spark）不会那么有效？ 为什么以 1 毫秒的延迟运行 mini-batch 无效？ 批处理是一种无处不在的技术，包括操作系统和内核 TCP/IP 堆栈，其中确实缓冲了到磁盘或网络的数据，因此这里有什么令人信服的因素说一个比另一个更有效？
【问题讨论】：
标签： apache-spark batch-processing apache-flink data-processing stream-processing
这是我经常思考的问题，因为技术人员和非技术人员的答案总是很难制定。
我将尝试回答这部分：
为什么运行延迟为 1 毫秒的 mini-batch 无效？
我认为问题不在于模型本身，而在于 Spark 如何实现它。经验证据表明，过多地减少小批量窗口，性能会下降。事实上，建议至少 0.5 秒或更长的时间来防止这种退化。在大容量上，即使这个窗口大小也太小了。我从来没有机会在生产环境中对其进行测试，但我从来没有对实时性提出过严格的要求。
我比 Spark 更了解 Flink，所以我不太了解它的内部原理，但我相信如果批处理需要至少几秒钟的时间来处理，但我相信批处理设计中引入的开销是无关紧要的如果它们引入了固定的延迟并且您不能低于该延迟，则很重。要了解这些开销的性质，我认为您必须深入研究 Spark 文档、代码和未解决的问题。
业界现在承认需要一种不同的模型，这就是为什么现在许多“流优先”引擎正在增长，而 Flink 是领跑者。我不认为这只是流行语和炒作，因为这种技术的用例，至少目前是极其有限的。基本上，如果您需要对大而复杂的数据实时做出自动化决策，您需要一个实时快速的数据引擎。在任何其他情况下，包括近实时，实时流式传输都是多余的，小批量就可以了。
【讨论】：
免责声明：我是 Apache Flink 的提交者和 PMC 成员。我熟悉 Spark Streaming 的整体设计，但不了解其内部细节。
Spark Streaming 实现的小批量流处理模型的工作原理如下：
那么，为什么每 1ms 运行一次 mini-batch 没有效果呢？仅仅因为这意味着每毫秒安排一次分布式批处理作业。尽管 Spark 在调度作业方面非常快，但这有点过分了。它还将显着降低可能的吞吐量。如果批处理太小，操作系统或 TCP 中使用的批处理技术也不能很好地工作。
【讨论】：
我知道一个答案已被接受，但我认为必须说另一个答案才能完全回答这个问题。我认为像“Flink 的实时流更快/更好”这样的答案是错误的，因为它在很大程度上取决于你想要做什么。
Spark mini-batch 模型具有 - 正如在之前的答案中所写的 - 缺点，即对于每个 mini-batch 都必须创建新的作业。
但是，Spark Structured Streaming 默认处理时间触发器设置为 0，这意味着读取新数据会尽可能快地完成。 这意味着：
在这种情况下延迟非常小。
与 Flink 相比的一大优势是，由于这种小批量模型，Spark 具有统一的 API 用于批处理和流处理。您可以轻松地将批处理作业转换为流式作业，将流式数据与批处理中的旧数据连接起来。用 Flink 做这件事是不可能的。 Flink 也不允许您对收到的数据进行交互式查询。
如前所述，微批处理和实时流的用例不同：
有关结构化流的更多详细信息，请查看this blog post
【讨论】：