原文标题：Batch Processing vs. Stream Processing:What's the Difference?

原文连接：https://www.influxdata.com/blog/batch-processing-vs-stream-processing/

我们了解到，时序库的设计特性使其可以支持巨大的同时写入，并能以高度压缩的状态存储这些数据，和其他非关系型数据库相比，其占据的硬盘空间是非常少的。但这也暴露出一个问题，这样大量且被高度压缩的数据在提取的时候可不是那么容易。
所以最好的方法，就是在数据被收集时，就对其进行进行转化、降频取样，或者说对数据进行一定程度的提炼。对于influxdata 的TICK技术栈，其最后一部分：Kapacitor承担的正是这样的工作。
我们通过编写influxdata公司自定义的DSL文件:TICK script可以告诉kapacitor怎样处理写入influxdb的数据，其中定义数据源的时候，就有batch和stream两种选项，那么我们应该如何选择呢？

Batch Tasks 批任务

你可以将batch任务理解为，已经用一个固定时间间隔（specific time interval）分组的数据点(influxdb中，每条数据被称为a data point，对应一个时间点的状态信息)集合。我们也可以称为这是一个数据窗口（window of data）
那么当我们启动一个批任务，kapacitor会按时间段切分来请求influxdb，这样可以避免在内存中缓存太多数据。在如下情况下，你应该选择批任务：
1，需要对一段时间的数据运行聚合函数运算，比如求这些数据点的平均值、最大值、最小值。
2，警告功能不需要运行每个数据点，或者说这些数据所代表的状态，并不会频繁地变化。（个人理解，比如某互联网公司的智能车项目，收集到的数据所代表的状态就是频繁变化的，比如精确到度的车辆朝向变化）。
3，降低采集的频度很大（downsample），庞大的数据中只需要最明显的那部分数据就能说明整体状态的变化。
4，一点额外的运行延迟不会对你的整体业务产生过大影响。
5，当集群运行时序数据库时，kapacitor处理数据的速度慢于数据写入的速度。（处理逻辑较为复杂，而数据写入量很大）

Stream Tasks 流任务

流任务，就像是使用消息队列时候对数据源再创建一个订阅，任何写入influxdb的数据点也会被写入kapacitor。所以需要牢记，流任务要求大量的内存分配。在以下情况，会非常适合选择流任务：
1，需要实时地转化每个数据点。（严格地讲，批任务可以这么做，但需要考虑延迟，或者说时效性。）
2，数据是报警数据，不能容忍太多的延迟。
3，涉及的数据会被频繁地查询，上文说到过，influxdb的读取能力并不乐观（个人曾遇到过直接query很长一段时间的数据，导致内存暴涨然后程序崩溃的情况），所以通过流任务，可以有效降低压力。（比如说一个库是统计用户的掉线情况的，如果你直接从这个库创建一个反映总掉线次数的dashboard，那么每次有人查看这个dashboard，数据库都要进行一次统计，这样就可以使用流任务将掉线次数实时计算并存入新的measurement）
4，流任务通过数据点的时间戳来获取时间信息，所以不会与一个给定的数据点是否进入时间窗产生竞争关系。
另外还有一点的是，流数据任务并不局限于influxdb，你也可以直接从telegraf获取数据输入，然后不经influxdb直接传送给kapacitor。

简短的总结：
1，批任务定期查询influxdb，使用有限的内存，但会对influxdb额外的查询负载
2，如果你要对数据运行聚合函数，最好使用批任务
3，流任务是从向influxdb写入的数据流订阅数据给kapacitor，所以可以降低influxdb的查询负载
4，流任务适合于对延迟很敏感的操作

2019/10/29 补充
在GCP(Google Cloud Platform) ML with tensorflow的课程中看到，一般业务的metrics、events存储于GCP的Pub/Sub服务（MQ服务），而Raw logs，files，assets， analytics data则存储于GCP的 Cloud Storage中（对象存储），前者以stream的形式，后者以batch的形式传输至 GCP Cloud Dataflow，再由BigQuery，BigTable工具进入机器学习环节