最近因為種種原因，複習了Spark的架構和概念，參考的是歐萊禮的Spark學習手冊，筆記在這裡。

一般來說，有大量資料運算需求的Cluster比較會需要常做效能調校，可能是Working Node主機或是Code的問題。最簡單的查詢方式就是透過 Spark UI，預設網址是 http://{your_server_ip}:4040 。

Spark UI主要包含幾個頁面：Job, Stage, Storage, Executor, Environment，每個頁面大概可以檢視的內容及觀察重點如下：

工作頁面(job page): 評量工作的執行效能

• 檢查組成工作的stage，觀察是否有執行特別慢，或是在多次執行中執行時間變化很大的stage
  • 如果有某個花特別久的stage，可點擊該stage並觀察該stage連結了哪些使用者程式碼

階段頁面(stage page): 獨立檢查某個stage的效能

• 觀察stage頁面不同的指標在所有task中的分佈情況
  • 如果有相對少數的任務花了大量時間 (此狀況稱作skew)，需檢視這些task過慢的原因
  • 且這些task是否花了比其他任務多的讀寫時間? 或是在某個節點執行的工作是否都比較慢?
• task花費少量的讀寫時間，整體執行時間卻很長
  • 代表使用者程式碼本身的操作是花費昂貴的，需考慮Spark Partition的基礎工作原理，將程式碼最佳化
• 某些任務可能消耗將近全部的時間從外部讀取資料，因為瓶頸在於讀取輸入資料
  • 代表程式碼最佳化不會獲益太多，可能在於資料量或其他問題

儲存頁面(storage page): 快取RDD資訊

• RDD可透過呼叫persist()進行快取，並在之後的工作使用
  • 如果快取RDD的請求超過所能負荷量，較舊的快取RDD會被移出memory，以提供足夠空間給新的快取RDD。
  • 顯示每個RDD有多少部份被快取、在不同儲存媒介中分別快取的資料量(disk, memory)。
• 了解重要的資料集是否被快取，對效能調校有很大幫助

執行器頁面(executor page): 應用程式目前的執行器列表

• 確認應用程式有取得預期的資源量
  • 錯誤的配置將導致執行器數量比預期中少，明顯影響效能
  • 觀察執行器是否有異常行為
    • task失敗比例特別高?
      代表實體主機有錯誤配置或是設備異常)，從cluster中移除該主機可能提升整體效能
• 透過 Thread Dump，收集堆疊追蹤資訊(stack trace)
  • 掌握某個時間點執行的程式碼
    • 如果執行器短時間內被捕捉到很多次，可推測此執行器為熱點(hot spots)或是代價昂貴的程式碼段。

環境頁面(environment page): Spark配置的除錯

• 察看應用程式正在使用中的設定值
  • 檢查應用程式執行的當下，哪些配置flag是否有開啟 (尤其是使用多重配置來源時)
• 列舉應用程式加入的JARS和檔案
  • 檢查是否有相依性遺失問題