流处理和批处理

Question

由于批处理的延迟是在累积特定数目的数据时产生的，我是否可以将“一的大小”的批处理视为流处理？或者当运算符进行计算时还有其他的区别吗？

例如，如果我将基于火花的程序的批处理大小设置为1，是否可以使其延迟降低到flink？

我的一种想法是:对于流处理，如果处理了前一个操作符，一个数据流就会从前一个操作符流到后一个操作符，但是对于批处理过程，只有在操作符处理完一个数据之后，它才能接受另一个数据。流处理中的流水线似乎是加速的关键。

我的解释正确吗？如果错了，对我的问题有什么适当的解释。

Answer 1

TLDR：您应该帮助您的程序并明确告诉它您需要有界(批)或无界(流)计算的原因很多。

您的想法在理论上是好的，但在实践中不是这样的:批处理和流设置是从程序员那里明确要求的。运行时不会根据您设置的批处理大小(或批处理延迟)推断它。至少这就是弗林克的工作方式。

此外，批处理与流的划分要深得多:批处理不应该太在意时间。

假设您将批处理大小增加为整个数据集大小。只有在这种情况下，Flink才能将性能优化应用于您的计划。例如:在流模式下，JOIN需要将双方都保存在内存中，以防另一侧出现匹配。在批处理模式下，Flink知道双方都是固定大小的，它可以先实现最小的一面，并将其保存在内存中，同时向另一方查询。因此，闪存需要更少的内存进行批处理，并且它更好地使用CPU缓存(这使得处理速度更快)。

流还必须维护水印(特殊的行元数据可以帮助将正确的行按时间顺序关联起来，保持一致的行集，等等)，而批处理并不关心它们。那是头顶。

如果您愿意，可以仔细阅读Flink源代码，并比较批处理与流的SQL优化规则。您将看到流必须处理水印(FlinkLogicalWatermarkAssigner)，而批处理不能处理，它必须完全展开时态表(LogicalCorrelateToJoinFromTemporalTableRule)。批处理还可以对行进行排序并执行排序-合并-连接(BatchPhysicalSortMergeJoinRule)。当批处理可以在数据源(PushLocalHashAggIntoScanRule)上本地执行时，流必须递增地处理聚合(PushLocalHashAggIntoScanRule)。这两个文件之间的每个差异要么是一方由于其(批处理与流)特性而必须特别做的事情，要么是其(批对流)特性允许的优化传递。

如果你想更多地了解这个话题，并且它有很多的微妙之处，你也可以阅读Flink博客文章，Flink文档，Flink改进建议