# Kapacitor Batch Vs Stream
在 kapacitor 任务中什么时候应该使用批处理?什么时候应该使用流处理?
本博客内容翻译自官方社区博客。
# 批处理
一个 batch 指的是在一个指定的时间范围内对数据分组后的集合。对应 steam 里面的 windown 的概念。当在 kapacitor 里面运行一个 batch 任务时,kapacitor 会周期性的从 influxdb 中查数据,这样可以避免在 kapacitor 中消耗太多内存,因为将查询和聚合的压力转移到了 influxdb 中。下面有一些批处理适用的场景:
在设定的数据间隔中执行聚合函数,例如寻找中位数,最大值,最小值,此类场景如果使用 steam 就需要将所有数据都先存在 kapacitor 的内存里,但是仅仅计算一个聚合函数的话,性价比太低。
对于那些不需要在每个数据点上运行的报警,因为状态可能不会经常发生,您不想被报警淹没。典型的例子是对证书过期信息监控,只需要每天查一次过期信息就好,不需要那么实时,使用 batch 显然更合适。
对包含非常大集合的数据进行降采样,并且仅保留最重要的数据。
稍有额外的延迟不会影响到您的操作。
由于 kapacitor 无法像数据写入 influxdb 那样快速处理数据,如果是有超高吞吐量的 influxdb 的情况,推荐使用 batch。
# 流处理
另一个方面,流处理任务创建一个订阅到 influxdb以便每个数据点能够被写到 influxdb 的同时也写到 kapacitor。因此,流任务会占用大量的可用内存。下面是一些适合流处理任务的场景:
- 如果你想实时的转换每个独立的数据点。从技术上来说,它也可以被运行在一个批处理任务中,但是有延迟需要考虑。
- 那些需要延迟尽可能低的场景。比如需要立即触发的报警。
- influxdb 处理大量负载查询压力的情况,您可能希望减轻 influxdb 的查询压力。
- 流任务通过 data point 上的时间戳来理解时间,对于给定的 data point 何时准确的进入或者不进入窗口没有竞争条件。对于批处理任务来说,数据点可能延迟到达并被遗忘在其相关的窗口之外。
- 编写流任务 tick 脚本的时候可能会碰到一个优势,即不需要去研究 influxdb 的查询。另一个因素是 kapacitor 不仅仅可以与 influxdb 一起使用,也可以跳过 infludb 直接和 telegraf 使用,这种情况下只能使用流任务。
# 总结
- 批处理任务会定期查询 influxdb,使用有限的内存,但会给 influxdb 带来额外的负载。
- 批处理任务最适合用于对数据执行聚合功能,降采样以及处理数大时间窗口的数据。
- 流处理任务订阅来自 influxdb 的写操作,从而使得 kapacitor 承担额外的写复杂,但是可以减少 influxdb 上的查询负载。
- 流处理任务最适用于操作需要低延迟的情况。
← 基于 Tick 脚本的报警设计 数据降采样 →