# 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 上的查询负载。
  • 流处理任务最适用于操作需要低延迟的情况。
上次更新: 5/12/2020, 2:19:47 AM