看這篇文章前，請先移步spark streaming 資料產生與匯入相關的記憶體分析, 文章重點講的是從kafka消費到資料進入blockmanager的這條線路的分析。
這篇內容是個人的一些經驗，大家用的時候還是建議好好理解內部的原理，不可照搬
在spark streaming 資料產生與匯入相關的記憶體分析中我說了這麼一句話：
我發現在資料量很大的情況下，最容易掛掉的就是receiver所在的executor了。 建議spark streaming團隊最好是能將資料寫入到多個blockmanager上。從現在的api來看，是沒有提供這種途徑的。但是spark streaming 提供了同時讀多個topic的功能，每個topic是乙個inputstream。 我們可以復用這個功能，具體**如下：
val kafkadstreams = (1 to kafkadstreamsnum).map
val uniondstream = ssc.union(kafkadstreams)
uniondstream
另外，務必給你系統設定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的容錯性也會更好些。
sparkstreaming執行緒數小於2時出錯！
stage 0 0 1 1 stage 10 0 1 1 20 02 11 11 32 55 warn randomblockreplicationpolicy expecting 1 replicas with only 0 peer s.20 02 11 11 32 55 warn blockm...
Spark Streaming入門詳解
背景 使用spark主要是使用spark streaming，spark streaming的魔力之所在於 1.流式處理，如今是乙個流處理時代，一切與流不相關的都是無效的資料。3.spark streaming本身是乙個程式，spark streaming在處理資料的時候會不斷感知資料。所以對構建複...
Spark Streaming 程式監控
官網中指出，spark中專門為sparkstreaming程式的監控設定了額外的途徑，當使用streamingcontext時，在web ui中會出現乙個 streaming 的選項卡，在此選項卡內，統計的內容展示如下 這其中包括接受的記錄數量，每乙個batch內處理的記錄數，處理時間，以及總共消耗...