Spark UI監控指標查看

1. Spark監控頁

進入對應的application

進入Tracking URL

選擇Streaming

2. 監控指標

Input Size 每個批次處理輸入數據大小（如多少條日誌）

Processing Time 每個批次處理時間

Scheduling Delay 每個批次延遲時間

Status 每個批次的狀態 queued排隊等待，processing正在執行

Active Batches 執行中/等待中的批次

Completed Batches 已完成的批次信息

3. 調整Spark的batch time

觀察Spark監控頁中的“Completed Batches”和“Active Batches”（注意觀察Input Size不爲0的批次），如果每個批次的處理時間在可接受的範圍內，而“Active Batches”中Status列中有很多批次都在排隊等待，如圖示：

這時需要調大Spark的批次處理時間，消除排隊等待的任務。

4. 分配足夠的資源

選擇耗時較長的batch，點擊進入 選擇耗時較長的Job id，點擊進入 選擇耗時較長的stage，點擊進入 進入了stage的詳情頁，可以看到該stage劃分的tasks數量，分配的executor數量，

理想情況下num-executors * executor-cores >= tasks數量，這樣所有task都可以並行跑，不過需要根據集羣的資源而定。

5. 避免循環調用低效的接口

如果分配給Job的資源足夠（主要是executor-memory，num-executors，executor-cores），tasks併發度高，每個task的運行時間太長，可能需要分析業務代碼，或許是業務代碼中循環調用了一些低效的接口，這個時候可能需要在代碼記錄log，縮小範圍來確定問題

比如：對每一個RDD的每一個元素調用如下接口，

  logger.info("############## start JSON.parseFull ")
  val JsonString = JSON.parseFull(log)
  logger.info("############## start JSON.parseFull ")

log打印

2016-10-19 10:21:01,402 | INFO  | [Executor task launch worker-0] | ############## start JSON.parseFull
2016-10-19 10:21:01,406 | INFO  | [Executor task launch worker-0] | ############## start JSON.parseFull

發現該接口每處理一條日誌，都耗時在4ms以上；RDD中的每一個元素都需要調用該接口，如果一個RDD中的元素有幾千條，耗時就有幾秒甚至十幾秒了。