Spark集群環境配置
我們有2個節點，每個節點是一個worker，每個worker上啟動一個Executor，其中Driver也跑在master上。每個Executor可使用的核數為2，可用的內存為2g，集群中所有Executor最大可用核數為4。
conf/spark-defaults.conf 部分參數配置如下：
spark.master spark://Master:7077
spark.executor.memory 2g
spark.executor.cores 2
spark.cores.max 4
在提交jar包的時，按照需求分配executor的核數和memory數給不同的應用,若某個應用占用了所有的核和內存，剩下的應用只能等待這個程序執行完畢釋放資源后才可執行。
conf/spark-env.sh 部分參數配置如下：
export SPARK_WORKER_CORES=2
export SPARK_WORDER_INSTANCES=1
export SPARK_WORKER_MEMORY=2g
執行節點負載均衡問題
比如啟動四個節點，但是在處理數據的時候負載不均衡，只有兩個節點的使用率很高。可以推測與分區數有關，測試數據集為267MB，hdfs中默認的數據分片大小為128MB，約有兩個分區。推測只有兩個分區能拿到數據進行計算，所以將hdfs的數據分片大小改為64MB，這樣約有4個分區，與集群中的Executor數目相符。經測試證明，負載不均衡的問題得到解決。
修改配置文件hdfs-site.xml，將block size設置為64MB
<property>
<name>dfs.block.size</name>
<value>67108864</value> 說明：64M=64*1024*1024
</property>
8080
如上圖所示，此頁面自上而下包括：
spark版本信息，
spark master 的URL（worker用來連接此master的URL）
worker的數量：4
所有worker節點中可用和在用的core（查看資源的使用情況，參考是否適合再啟動一個應用等）
所有worker節點中可用和在用的memory（如上）
正在運行和已經完成的應用數量
master當前狀態
workers部分
- 展示集群中每個worker的位置，到當前狀態，內核使用情況，內存使用情況
（通過查看內核和內存的用量情況確定是否足夠運行一個新的應用）
- 點擊workerID進入worker的detail頁面會顯示與該worker更詳細的信息
（理想情況下，所有worker節點使用的內核數和內存應該是相同的，如果出現使用率不同的情況，說明集群資源未平均分配，應用未最佳化運行，需停止所有應用重新啟動集群）
Running/Completed Application部分
- 分別展示在運行和已經運行完的應用信息，包括名稱，獲得的資源，開始時間，所有者，已運行時間，目前狀態（RUNNING/FINISHED/結束原因）
（若state顯示WAITING，則說明Spark對於應用沒有足夠的內存或內核，將保持等待直到有足夠資源可用，有幾種情況，一是直到已經在運行的一個應用完成運行，二是增加分配給spark worker的資源，三是將少應用的請求資源）
- 點擊ApplicationID進入detail頁面會顯示看到關於該應用運行時的詳細信息，包括參與的worker/使用的資源數/日志等
（如果一個任務失敗或拋出了異常，可以查看stderr文件來調試問題）
4040
localhost:4040（當應用在運行中的時候可以訪問，一旦應用執行結束該端口關閉不可訪問）
如下圖，顯示基本的運行時間，調度模式（FIFO為先進先出），不狀態中作業的統計量，並顯示正在運行/已經完成/運行失敗的spark作業較為詳細的信息列表，例如，Job的提交時間/運行時間/目前為止每個Job完成的Stage和Task數量等
（從運行時間項可以觀察到，若某一個Job花費時間異常，可以把問題縮小到該Job下的Stage或者Task）
點擊某JobID，進入detail頁面顯示如下信息：
該Job當前狀態
活躍/延遲/已完成的Stage數量
該Job的事件時間線
[spark為該Job生成的DAG的可視化呈現]
表格部分的信息有助於定位性能問題，檢查Duration列是否存在運行時間異常的Stage，Tasks表明一個Stage內的並行量（根據集群大小，太少或太多可能導致性能問題）。數據Shuffle會對應用性能造成負面影響，所以要最小化Shuffle Read和Write數量。
DGA可視化
Stage
點擊某Stage，進入detail頁面顯示如下信息。
Summary 部分：
若任務持續時間在任一個四分位處過高，則說明有問題。可能是分開太大，也可能是數據Shuffle的負面效應。也可以檢查GC活動是否影響性能。
Executor的聚合信息部分：
可以有效找出處理緩慢的任務，檢查GC時間
Locality Level（數據的區域級別）：
標明任務所處理的數據是緩存在內存中的（PROCESS_LOCAL），還是本地讀取（NODE_LOCAL），還是來自於集群中的任意節點（ANY）。以PROCESS_LOCAL級別處理數據是極快的。
事件時間線監控，顯示了每個worker節點上並行運行了多少個任務，已經增加任務完成所需的總時間
Storage頁顯示Spark應用緩存在內存或硬盤中的數據量，提供每一個持久化RDD的信息。（可以是以Hive表格或者是RDD的形式緩存在內存中）
Storage Level展示數據集如何緩存，以及所緩存數據的副本數量。
點擊具體的RDDID，進入detail頁。包括：
緩存RDD的概要信息
在不同EXecutor上的分布（每個Executor上需要的內存）
分塊信息，如存儲級別/位置/每個緩存RDD分塊大小
Enviroment頁面顯示不同環境和配置變量的值：
Executor顯示Spark為該應用創建的執行者的概要信息：
Storage Memory表示緩存數據所預留的和所使用的內存量（若內存小於正在嘗試緩存的數據，則會出現性能問題）
Shuffle的讀寫都是昂貴的，如果這兩個值過大，應該重構應用代碼或者調整Spark參數減少Shuffling
18080
localhost:18080（spark的歷史管理中心，包含所有已經運行完成的Application及其詳細信息）
點擊具體的APP ID 展現的頁面結構與4040相同
50070
- master:50070 訪問namenode的hdfs web UI監控頁面
（理想情況下，Summary下的表格右邊是有正常數據的而不是0）
- 查看已經啟動的datanode信息
- 查看文件目錄
總結
本文主要介紹spark webui相關的監控頁面指標信息。在我們排查問題，做性能優化時，了解spark監控項可以幫我們快速定位問題的症結，因而需要我們對相關監控頁面的地址以及里面的監控項要非常了解。