本期內容 :
- BatchDuration與 Process Time
- 動態Batch Size
Spark Streaming中有很多算子，是否每一個算子都是預期中的類似線性規律的時間消耗呢？
例如：join操作和普通Map操作的處理數據的時間消耗是否會呈現出一致的線性規律呢，也就是說，並非數據量規模越大就是簡單加大BatchDuration
就可以解決問題的，數據量是一個方面，計算的算子也是一個考量的因素。
使用BatchSize來適配我們的流處理程序 ：
線上的處理程序越來越重要，流入的數據規模越來越大的時候，傳統的一台機器不能夠容納此刻流入的數據並處理此刻流入的數據，所以需要分
布式。分布式的流處理程序其根源在於此1秒中流入的數據我們一台機器無法容納且無法完成及時的處理，也就是大數據，更談不上實時性處理和在
線處理 。數據處理的過程中最重要問題是在不同的算子和工作負載對我們處理時間的影響以及這種影響是否是我們預期中的結果。
目前有很多的計算框架，這些所有的計算框架有一個共同特征，就是在連續不斷的流進來的一系列數據中使用MapReduce的思想去處理接收到的
數據， MapReduce是一種思想，無論是Hadoop還是Spark都是MapReduce的思想實現，MapReduce的實現有一個很好的方面就是容錯性，他有自
己的一套完整的容錯機制。流處理程序在具體處理線上數據的時候，借助MapReduce容錯機制能夠快速從錯誤中恢復的能力。
構建一套穩定的處理程序，有很多維度需要去考慮，如實時性、波峰，如每秒處理1G的數據，突然一個波峰需要處理100T的數據，此時將如何處
理，整個流處理應該怎樣去應對這種情況？
以往的流處理系統中，一種是流處理框架可以動態調整資源，如內存、CPU等資源。另外一種是在來不及處理時使用丟棄部分數據。那如何在保證
數據的完整性的情況下，且數據一定會處理。如何應對現實突發的情況，如果直接調整內存、CPU等資源其代價非常大而且也不太好調整。
Spark Streaming的處理模型是以Batch為模型然后不斷的在Queue中把每個BatchDuration的數據進行排隊：
Spark Streaming的數據一批批的放在隊列中，然后一個個的在集群中處理的，無論是數據本身還是元數據，Job都是以隊列的方式獲取信息來控制整
個作業的運行。隨着數據規模變的越來越大的時候，並不是簡簡單單的增加內存、CPU等硬件資源就可以的，因為很多時候並不是線性規律的變化。
什么因素導致了Batch處理數據的延時：
01、 接收數據並且把接收到的數據放到Batch待處理的隊列中(也就是BatchSize會極大的影響其延時性)
02、 等待時間
03、 處理時間
靜態處理模型 ：
圖中的虛線就是安全區域，安全區域就是數據流進來的速度能夠及時在這個BatchDuration中被消化。對Reduce與Join的操作進行對比，不同的算子存在不同的
線性規律，不是隨着數據量的增加呈現線性的處理速度，流處理有很多因素影響 .
一般使用幾個BatchDuration進行流處理，直接配置一些參數，每隔10S中就有一個BatchDuration然后處理，這樣的處理方式是不可取的。從上圖可以看出，實
際不是這樣的，隨着數據量的改變，原來的數據量運行很好，預期也有評估，如每秒處理100M的數據(單節點)，使用線性方式評估在500M的時候是怎樣的，然后就設
置相對應的靜態模型，是基於你現有的硬件資源(內存、CPU、網絡)，這樣評估是不准確的，而且很難預測，因為當消費數據的容量的不同很難去預測其運行行為。
在改變其數據rate時，狀態有不穩定性，如果能夠改變BatchSize的話其相對穩定，所以需要設計一種算法或者實現，不是去調整內存、CPU等硬件資源，而是調
整其Batch的大小，當Batch足夠小或者小得適當的時候，應該是個更好的思路，低延時、靈活性、通用性、簡單性。
要完成BatchSize的變化的不斷的調整肯定需要對Job信息進行統計，動態的調整這個模式，這個模式就是配置相應的參數。隨着處理的不斷運行，在下一次運行
之前看一下上次統計的信息，是否需要調整我們的模型，但是這樣做會比較困難。因為會出現一些非線性的行為，把你認為的線性的資源改變一下就是可以的，處理
規模不一樣，處理算子不一樣，有很多不可預測的因素，需要實現對BatchSize的動態調整。
