批量处理与流处理：有何区别？
作者：Margo Schaedel / 产品，用例，开发者
2018年3月29日
导航到
如果您已经阅读了DevRel Katy Farmer 的出色文章，Kapacitor和连续查询：如何决定您需要哪个工具，那么您知道当我们的社区发言时，我们会倾听。因此，与这一观点相一致，并为了纪念我们自己的Kapacitor Koala，让我们解决另一个引起我们注意的常见社区问题：在Kapacitor任务中，何时应该使用批量处理而不是流处理？
<figcaption> 我们著名的Kapacitor Koala </figcaption>
现在，如果您对Kapacitor一无所知，我建议您先阅读一下关于它的简介，您可以在这里 和 这里 了解更多，以便让您更快地上手。 Kapacitor，我们的TICK Stack中的最后一个组件，提供了数据转换、下采样和警报等功能。Kapacitor使用自己的DSL，称为TICKscript，它允许您定义某些任务，然后可以在您的数据上执行这些任务——本质上，它是在为您处理数据。
不过，这里有些棘手：您如何选择将数据作为批量任务还是流任务进行处理？
批量任务
让我们首先讨论批量任务。批量是指在特定时间间隔内分组在一起的数据点的集合。另一个常用于此的术语是数据窗口。在运行批量任务时，Kapacitor定期查询InfluxDB，从而避免在RAM中缓冲大量数据。在以下几种情况下，批量处理是可行的
- 执行聚合函数，如寻找数据集中间值、最大值或最小值。
- 在不需要对每个数据点运行警报的情况下（因为状态变化可能不会那么频繁）。您不希望被大量警报淹没！
- 数据下采样从大量数据点中提取并仅保留最重要的数据（因此您仍然可以查看数据的整体趋势）。
- 一些情况下，少量的额外延迟不会严重影响您的操作。
- 具有超高吞吐量的InfluxDB实例，因为Kapacitor无法像写入InfluxDB那样快速处理数据（这种情况在InfluxDB企业集群中更为常见）。
流任务
另一方面，我们有流任务。流任务创建对InfluxDB的订阅，以便每个写入InfluxDB的数据点也写入Kapacitor。需要注意的是，流任务会使用大量可用内存，因此内存可用性是一个关键因素。以下是流处理最为理想的地方
- 如果您想在实时中转换每个单独的数据点（技术上，这也可以通过批量处理运行，但需要考虑延迟）。
- 在这种情况下，最低可能的延迟对操作至关重要。例如，如果需要立即触发警报，运行流任务将确保尽可能小的延迟。
- 在这种情况下，InfluxDB正在处理大量查询负载，您可能希望减轻一些来自InfluxDB的查询压力。
- 流任务通过数据的时间戳理解时间；不存在给定点何时进入窗口或不进入窗口的竞争条件。另一方面，在批量任务中，数据点可能迟到并被排除在其相关窗口之外。
有些人可能认为编写流任务的优势在于使用Kapacitor的TICKscript定义任务，而无需深入了解InfluxDB的查询编写。然而，如果您对两者都感到舒适，那么可能最好在大多数情况下使用批量处理，因为它使用的内存较少。另一个需要考虑的因素是，Kapacitor不仅限于与InfluxDB一起使用。例如，如果您想直接将Telegraf中的数据发送到Kapacitor，那么这将必须作为一个流任务来完成。
关键要点
- 批量任务定期查询InfluxDB，使用有限的内存，但可能对InfluxDB造成额外的查询负载。
- 批量任务最适合执行数据聚合函数、降采样和处理大量时间窗口数据。
- 流任务订阅来自InfluxDB的写入，对Kapacitor造成额外的写入负载，但可以减少InfluxDB的查询负载。
- 流任务最适合那些低延迟对操作至关重要的案例。
当我们的社区发言时，我们在倾听。
我们很想听听您的批量和流任务进展如何！请在我们社区网站上发送您的评论、问题、问题和博客想法，并在Twitter上联系我们
