目錄
1.系統(tǒng)架構(gòu)
2.環(huán)境搭建
2.1本地環(huán)境下kafka批量導入數(shù)據(jù)
2.2 kafka-manager的安裝與配置
3.1 Spark Streaming 性能調(diào)優(yōu)(一): 解決并行度
3.2 Spark Streaming 性能調(diào)優(yōu)(二): 解決task傾斜
根據(jù)前面幾篇文章，運行該日志分析系統(tǒng)的環(huán)境與數(shù)據(jù)都已經(jīng)準備好了虾标，接下來就該進行調(diào)試與排查性能瓶頸了荞驴。
問題分析
首先, 根據(jù)前面的一篇文章:2.1 本地環(huán)境下kafka批量導入數(shù)據(jù), 我分別模擬了數(shù)據(jù)在kafka的各個分區(qū)中分布均勻與分布不均勻兩種情況.下面來看看運行結(jié)果對比:
測試環(huán)境: 本地, 開啟4個線程
數(shù)據(jù)分布不均下task的執(zhí)行情況
從上圖可以看出, 在數(shù)據(jù)分布不均勻的情況下, 出現(xiàn)了部分task有數(shù)據(jù),部分task卻沒有數(shù)據(jù)的情況, 導致機器的cpu資源沒有得到充分利用.
task數(shù)據(jù)不均的原因
由于我這個日志分析系統(tǒng)是使用direct模式從kafka拉取數(shù)據(jù)的, 在direct模式下, 通過KafkaUtils.createDirectStream(...)獲取的DStream中的rdd的分區(qū)數(shù)是與kafka相對應(yīng)的topic的分區(qū)數(shù)是一樣的,且分區(qū)中的數(shù)據(jù)分布情況也是一樣的.
這就導致了spark streaming獲取的rdd的分區(qū)中只有一個是有數(shù)據(jù)的, 而task與分區(qū)也是一一對應(yīng)關(guān)系, 所以就造成了只有一個task在處理數(shù)據(jù).
數(shù)據(jù)分布均勻下task執(zhí)行情況
從上圖可以看出, 數(shù)據(jù)均勻分布的話, 各個task處理的數(shù)據(jù)量都比較均勻, cpu資源的利用也提升了不少.
解決問題
問題逐漸清晰了, 其實就是線上從kafka獲取數(shù)據(jù)時, kafka中的分區(qū)數(shù)據(jù)分布不均, 導致部分task處理的數(shù)據(jù)量特別少, 集群cpu資源得不到充分利用.
而解決辦法就是, 利用DStream.reparation(partitionNum), 對DStream進行重新分區(qū), 請注意, reparation()函數(shù)會對數(shù)據(jù)做shuffle, 這就相當于將數(shù)據(jù)分配到了其他機器上.這樣就能提高并行度, 提高集群cpu資源利用率.
