比较：流处理 vs 批处理

在决定在 Foundry 中以流处理或批处理数据集的方式处理数据时，了解您特定应用案例的需求是非常重要的。我们建议考虑流处理和批处理管道的特性、性能和技术期望，以确保选择最适合您应用案例的工具。

通常，流处理用于需要低端到端延迟的工作流程。对于可以容忍超过十分钟延迟的应用案例，增量或标准批处理数据集也可能是合适的解决方案。

特性考虑

流处理和批处理管道共享许多共同特性。需要考虑的主要区别是延迟、计算成本和支持的变换语言。下表显示了流处理和批处理管道可用的特性。

前端工具

一些 Foundry 前端工具可以以“实时”方式消费流数据集，例如实时更新图表。可以原生消费流的工具有 Ontology、Pipeline Builder、Quiver、数据集预览和Foundry Rules。Foundry 中的其他应用程序，如 Contour，可以消费流的存档数据集。这是一个标准批处理数据集，每隔几分钟更新一次流的最新数据。实际上，您可以在任何您想要的应用程序中选择流数据集，Foundry 会自动识别使用哪种模式。

性能考虑

除了特性考虑外，还要考虑流处理和批处理管道之间的不同性能期望。这些因素包括延迟和吞吐量。查看流处理延迟和吞吐量考虑以获取更多详细信息。

技术考虑

除了定义流处理和批处理的特性和性能因素外，还要考虑技术因素，包括状态管理、停机影响和消费层延迟。

状态管理

与批处理变换不同，批处理变换的输入大小是有界且预先已知的，有状态流处理 ↗应用程序可能具有无界状态，这可能会随着时间的推移而增长，并在未来某个未知点导致内存不足错误。例如，执行一个或多个键的聚合通常是一个危险操作，如果键空间大小是无界的。与批处理计算不同，通常难以预见和提供足够的资源。因此，由于大多数流处理应用程序的时间特性，确保在设计流处理变换时状态增长不是无界的。

低延迟

低延迟通常是流处理管道的重要要求，但实现低延迟并不总是一个明确的过程。由于流处理管道通常有多个步骤，延迟受所有层中最高延迟的限制。因此，实现低延迟可能涉及对从源系统到流处理应用程序和下游消费者的多个应用程序和消费层进行微调。

停机影响

由于批处理管道通常不用于具有严格低延迟要求的操作性工作流程，因此它们对停机的容忍度通常高于流处理管道。批处理管道通常按固定时间表运行；个别运行失败通常不是主要问题，可以重试搭建。相比之下，流处理管道是连续运行的过程，没有定义的终点，故障往往影响更大。持有实时数据的数据存储的10分钟中断比每天更新的数据存储的10分钟中断影响要大得多。

消费层延迟

由于批处理管道通常因变换而不是读取或写入数据而被阻塞，几乎任何消费层都可以使用。对于流处理管道，需要本地支持快速、频繁写入的消费层以保持低延迟。这意味着端到端管道中的每个应用程序都必须能够以低延迟处理数据，以确保低端到端延迟。大多数 Foundry 产品本地支持这一点，包括 Pipeline Builder、时间序列、Foundry Rules 和 Ontology。数据连接器也存在以支持低延迟写入到外部系统。

成本考虑

由于高吞吐量、低延迟计算，流处理管道的平均成本通常高于批处理管道的平均成本。然而，对于需要低延迟数据处理的流处理形状管道，流处理可能是相较于持续运行的批处理管道更具成本效益的解决方案。

查看Foundry 流处理的计算使用以获取有关流处理成本计算的更多信息。