原文標題：Batch Processing vs. Stream Processing:What's the Difference?

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

我們了解到，時序庫的設計特性使其可以支持巨大的同時寫入，并能以高度壓縮的狀態(tài)存儲這些數據，和其他非關系型數據庫相比，其占據的硬盤空間是非常少的。但這也暴露出一個問題，這樣大量且被高度壓縮的數據在提取的時候可不是那么容易。
所以最好的方法，就是在數據被收集時，就對其進行進行轉化、降頻取樣，或者說對數據進行一定程度的提煉。對于influxdata 的TICK技術棧，其最后一部分：Kapacitor承擔的正是這樣的工作。
我們通過編寫influxdata公司自定義的DSL文件:TICK script可以告訴kapacitor怎樣處理寫入influxdb的數據，其中定義數據源的時候，就有batch和stream兩種選項，那么我們應該如何選擇呢？

Batch Tasks 批任務

你可以將batch任務理解為，已經用一個固定時間間隔（specific time interval）分組的數據點(influxdb中，每條數據被稱為a data point，對應一個時間點的狀態(tài)信息)集合。我們也可以稱為這是一個數據窗口（window of data）
那么當我們啟動一個批任務，kapacitor會按時間段切分來請求influxdb，這樣可以避免在內存中緩存太多數據。在如下情況下，你應該選擇批任務：
1，需要對一段時間的數據運行聚合函數運算，比如求這些數據點的平均值、最大值、最小值。
2，警告功能不需要運行每個數據點，或者說這些數據所代表的狀態(tài)，并不會頻繁地變化。（個人理解，比如某互聯網公司的智能車項目，收集到的數據所代表的狀態(tài)就是頻繁變化的，比如精確到度的車輛朝向變化）。
3，降低采集的頻度很大（downsample），龐大的數據中只需要最明顯的那部分數據就能說明整體狀態(tài)的變化。
4，一點額外的運行延遲不會對你的整體業(yè)務產生過大影響。
5，當集群運行時序數據庫時，kapacitor處理數據的速度慢于數據寫入的速度。（處理邏輯較為復雜，而數據寫入量很大）

Stream Tasks 流任務

流任務，就像是使用消息隊列時候對數據源再創(chuàng)建一個訂閱，任何寫入influxdb的數據點也會被寫入kapacitor。所以需要牢記，流任務要求大量的內存分配。在以下情況，會非常適合選擇流任務：
1，需要實時地轉化每個數據點。（嚴格地講，批任務可以這么做，但需要考慮延遲，或者說時效性。）
2，數據是報警數據，不能容忍太多的延遲。
3，涉及的數據會被頻繁地查詢，上文說到過，influxdb的讀取能力并不樂觀（個人曾遇到過直接query很長一段時間的數據，導致內存暴漲然后程序崩潰的情況），所以通過流任務，可以有效降低壓力。（比如說一個庫是統(tǒng)計用戶的掉線情況的，如果你直接從這個庫創(chuàng)建一個反映總掉線次數的dashboard，那么每次有人查看這個dashboard，數據庫都要進行一次統(tǒng)計，這樣就可以使用流任務將掉線次數實時計算并存入新的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的課程中看到，一般業(yè)務的metrics、events存儲于GCP的Pub/Sub服務（MQ服務），而Raw logs，files，assets， analytics data則存儲于GCP的 Cloud Storage中（對象存儲），前者以stream的形式，后者以batch的形式傳輸至 GCP Cloud Dataflow，再由BigQuery，BigTable工具進入機器學習環(huán)節(jié)