task資料分配不均
由於我這個日誌分析系統是使用direct模式從kafka拉取資料的, 在direct模式下, 通過kafkautils.createdirectstream(…)獲取的dstream中的rdd的分割槽數是與kafka相對應的topic的分割槽數是一樣的,且分割槽中的資料分布情況也是一樣的.
這就導致了spark streaming獲取的rdd的分割槽中只有乙個是有資料的, 而task與分割槽也是一一對應關係, 所以就造成了只有乙個task在處理資料.
問題逐漸清晰了, 其實就是線上從kafka獲取資料時, kafka中的分割槽資料分布不均, 導致部分task處理的資料量特別少, 集群cpu資源得不到充分利用.
而解決辦法就是, 利用dstream.reparation(partitionnum), 對dstream進行重新分割槽, 請注意, reparation()函式會對資料做shuffle, 這就相當於將資料分配到了其他機器上.這樣就能提高並行度, 提高集群cpu資源利用率.
1.(提高成本)direct(直連的方法)需要採用checkpoint或者第三方儲存來維護offsets(偏移量),
而rexeiver-based是通過zookeeper來維護offsets,所以用direct提高了使用者的開發成本
2.(監控視覺化)receiver-based方式制定topic制定consumer的消費情況均能通過zookeeper來監控,而direct則沒有這種便利，如果做到監控並視覺化，則需要投入人力開發。
spark Streaming中的容錯機制
spark操作通常是容錯檔案系統中的資料，比如hdfs.因此，所有通過容錯資料生成的rdd也是容錯的，然而，對於spark streaming來說，這卻是行不通的，因為在大多數情況下，資料都是通過網路接收的，要讓spark streaming程式中，所有生成的rdd,都達到與普通spark程式的rd...
Spark Streaming入門詳解
背景 使用spark主要是使用spark streaming，spark streaming的魔力之所在於 1.流式處理，如今是乙個流處理時代，一切與流不相關的都是無效的資料。3.spark streaming本身是乙個程式，spark streaming在處理資料的時候會不斷感知資料。所以對構建複...
Spark Streaming 程式監控
官網中指出，spark中專門為sparkstreaming程式的監控設定了額外的途徑，當使用streamingcontext時，在web ui中會出現乙個 streaming 的選項卡，在此選項卡內，統計的內容展示如下 這其中包括接受的記錄數量，每乙個batch內處理的記錄數，處理時間，以及總共消耗...