Spark Streaming 資料接收優化

這篇内容是個人的一些經驗，大家用的時候還是建議好好了解内部的原理，不可照搬

<b>我發現在資料量很大的情況下，最容易挂掉的就是receiver所在的executor了。 建議spark streaming團隊最好是能将資料寫入到多個blockmanager上。</b>

從現在的api來看，是沒有提供這種途徑的。但是spark streaming 提供了同時讀多個topic的功能，每個topic是一個inputstream。 我們可以複用這個功能，具體代碼如下：

kafkadstreamsnum 是你自己定義的，希望有多少個executor 啟動receiver 去接收kafka資料。我的經驗值是 1/4 個executors 數目。因為資料還要做replication 一般，是以這樣記憶體最大可以占到  1/2 的storage.

另外，務必給你系統設定 spark.streaming.receiver.maxrate。假設你啟動了 n個 receiver，那麼你系統實際會接受到的資料不會超過 n*maxrate，也就是說，maxrate參數是針對每個 receiver 設定的。

也就是我們盡量讓資料都占用spark 的storage 記憶體。方法是把spark.streaming.blockinterval 調小點。當然也會造成一個副作用，就是input-block 會多。每個receiver 産生的的input-block數為： batchinterval* 1000/blockinterval。 這裡假設你的batchinterval 是以秒為機關的。 blockinterval 其實我也不知道會有啥影響。其實說白了，就是為了防止gc的壓力。實時計算有一個很大問題是gc。

一般在spark streaming中不建議把 executor 的記憶體調的太大。對gc是個壓力，大記憶體一fullgc比較可怕，很可能會拖垮整個計算。 多executor的容錯性也會更好些。