在实践中（不是理论）小批量与实时流有什么区别？从理论上讲，我理解小批量是在给定的时间范围内进行批处理的东西，而实时流更像是在数据到达时做一些事情，但我最大的问题是为什么没有具有 epsilon 时间范围（比如一毫秒）的小批量，或者我想了解为什么一个比另一个更有效的解决方案？
我最近遇到了一个例子，其中小批量（Apache Spark）用于欺诈检测和实时流（Apache Flink）用于欺诈预防。有人还评论说小批量不是预防欺诈的有效解决方案（因为目标是防止交易发生）现在我想知道为什么小批量（Spark）不会那么有效？为什么以 1 毫秒的延迟运行 mini-batch 无效？批处理是一种无处不在的技术，包括操作系统和内核 TCP/IP 堆栈，其中磁盘或网络的数据确实被缓冲了，那么这里有什么令人信服的因素说一个比另一个更有效？
免责声明：我是 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 也不允许您对收到的数据进行交互式查询。
如前所述，微批处理和实时流的用例不同：
有关结构化流的更多详细信息，请查看此博客文章
这是我经常思考的问题，因为对技术人员和非技术人员的回答总是很难制定。
我将尝试回答这部分：
为什么以 1 毫秒的延迟运行 mini-batch 无效？
我相信问题不在于模型本身，而在于 Spark 如何实现它。经验证据表明，过多地减少小批量窗口，性能会下降。事实上，建议至少 0.5 秒或更长的时间来防止这种退化。在大容量上，即使这个窗口大小也太小了。我从来没有机会在生产中测试它，但我从来没有强烈的实时要求。
我比 Spark 更了解 Flink，所以我不太了解它的内部结构，但我相信如果你的批处理需要至少几秒钟的时间来处理，那么在批处理设计中引入的开销是无关紧要的，但如果它们会变得很重引入一个固定的延迟，你不能低于它。要了解这些开销的性质，我认为您必须深入研究 Spark 文档、代码和未解决的问题。
业界现在承认需要一种不同的模型，这就是为什么现在许多“流优先”引擎正在增长，而 Flink 是领跑者。我不认为这只是流行语和炒作，因为这种技术的用例，至少目前是极其有限的。基本上，如果您需要对大而复杂的数据实时做出自动化决策，您需要一个实时快速的数据引擎。在任何其他情况下，包括近实时，实时流式传输都是多余的，小批量就可以了。