監控Spark應用方法簡介

監控Spark應用有不少種方法。

Web接口
每個SparkContext啓動一個web UI用來展現應用相關的一些很是有用的信息，默認在4040端口。這些信息包括：

任務和調度狀態的列表
RDD大小和內存使用的統計信息
正在運行的executor的信息
環境信息
你能夠在瀏覽器中打開http://<driver-node>:4040網址來訪問這些信息。若是在同一臺機器上有多個SparkContext正在運行，那麼他們的端口從4040開始依次增長（4041，4042等）。

Spark在單機模式下也提供了web UI。

注意，在全部這些web接口能夠經過點擊「表頭」來對這些表格進行排序。這使得鑑別運行速度慢的任務、判別數據傾斜等很是容易。

Metrics
Spark基於Coda Hale Metrics庫提供一個可配置的統計系統。這容許用戶向不一樣的終端發送統計信息，包括HTTP、JMX和CSV文件。統計系統能夠經過配置文件來進行配置，Spark默認將配置文件保存在$SPARK_HOME/conf/mertics.conf。用戶能夠經過Java property spark.metrics.conf來修改配置文件的保存路徑。Spark根據組件的不一樣將統計信息分爲多個實例。能夠配置每個實例向多個方向發送統計信息。目前支持下面幾種實例：

master:Spark管理進程
applications:位於master的組件，統計發送各類應用的信息
worker:Spark工做進程
executor:執行器
driver:Spark驅動程序
每個實例能夠向多個渠道發送統計信息。渠道包含在包org.apache.spark.metrics.sink：

ConsoleSink：將統計信息發送到控制檯
CSVSink：每隔一段時間將統計信息寫入到CSV文件
GangliaSink：將統計信息發送到Ganglia或者多播組
JmxSink：將統計信息註冊到JMX控制檯
MetricsServlet：在Spark UI中添加servlet用來以JSON的方式提供統計信息
統計信息配置文件的語法有一個示例文件——$SPARK_HOME/conf/metrics.conf.template.

外部工具
有幾個外部工具可用來衡量Spark做業的性能：

集羣範圍的監控工具，好比 Ganglia，能夠洞察整個集羣的利用率和資源瓶頸。例如，Ganglia儀表盤能夠迅速揭示出某個特定載荷是磁盤相關，網絡相關，仍是CPU相關的。
OS性能分析工具，好比 dstat, iostat,和 iotop， 能夠提供各個節點的細粒度的分析。
JVM工具，好比 jstack提供了堆棧跟蹤，jmap提供了建立堆轉儲，jstat提供了時間序列統計報告，還有jconsole提供了各類JVM屬性的視覺顯示，它們對JVM內部構件的溫馨運做都是很是有用的。

 

討論Spark的配置監控和性能優化（某課程筆記）
 
上完這節課之後，你將可以描述集羣的概念
經過修改Spark的屬性，環境變量，或者是日誌屬性來配置Spark
使用Web端界面，以及各類不一樣的外部工具來監控Spark和應用程序
 
 
在Spark集羣中有三種主要的組成部分。驅動程序，是放置主程序中SparkContext的地方,要運行一個集羣，你須要一個集羣管理器
它能夠是單機版的集羣管理器，也能夠是 Mesos 或者 Yarn
而worker節點，就是放置執行器的地方


 
執行器，是運行計算和儲存應用程序數據的地方。SparkContext以JAR或者Python文件
的形式向每一個執行器發送應用程序。最終，它向每一個執行器發送任務並運行
 
由於驅動程序在集羣上調配任務，它應該在相同的本地網絡中
  
的woker節點運行。若是要向集羣發送遠端請求


最好使用一個RPC，而且從附近的節點提交操做
 
咱們前面提到三個支持的集羣管理器
 
對於Spark的配置，主要有三個主要的地方


Spark屬性，你能夠用SparkConf對象或者經過Java系統屬性來設置應用程序的參數
環境變量，你能夠用它們來設置每個機器的設定，好比IP地址這是經過配置每個節點上的conf/spark-env.sh腳本實現的
對於日誌屬性，它能夠經過log4j.propertieis來進行設置
你能夠選擇修改目前位於SPARK_HOME/conf目錄下的默認配置目錄設定SPARK_CONF_DIR環境變量而且在這個目錄下提供你的配置文件


 
 
這裏有兩種方法來設定Spark屬性：
第一種方法是經過SparkConf對象來傳遞應用程序屬性
第二種方法是動態地設置Spark的屬性。Spark容許你在建立一個SparkContext的時候傳遞一個空的SparkConf
而後，在運行時用 「—master」 或者 「—conf」 參數命令行選項來提供設置值


你能夠運行spark-submit腳本的時候，經過「—－help」來查看各類選項
另外一種設定Spark屬性的方法是在spark-defaults.conf文件裏設置
spark-submit腳本會從你的文件中讀取這些配置
你能夠在應用程序的默認端口爲4040的Web客戶端上查看Spark屬性


最後我想提到的一件注意事項，直接SparkConf上設置的屬性具備最高的優先級
spark-submit或者spark-shell是第二優先級，最後是spark-default.conf文件裏的設置。


監控Spark應用程序有三種方法：第一種方法是使用基於Web的客戶端，它的默認端口是4040
在應用程序運行期間，你能夠在這個客戶端上得到Spark實時監控信息
若是你但願在程序運行完之後查看這些信息，你須要在應用程序開始以前把spark.eventlog.enabled屬性設定爲true,這樣全部運行的信息就會被儲存起來




Metrics是另外一種檢測Spark應用程序的方法。這個metric系統是基於Coda Hale Metrics庫的
你能夠自定義輸出的格式，例如CSV格式的運行報告
能夠在conf目錄下的metrics.properties文件中配置metrics系統


最後，也能夠經過外部工具來監控Spark。例如，Gangalia是用來查看總體集羣的利用狀況和資源瓶頸的工具。
各類不一樣的OS profiling工具和JVM工具也能夠用來監測Spark


默認設置下，Web客戶端能夠在端口4040下查看，它顯示當前
正在運行的應用程序的信息。Web客戶端，能夠看到任務協調器的狀態，提交的任務狀態，RDD的大小，內存使用量的報告，環境設置信息以及
正在運行的執行器的信息




要在應用程序運行完之後查看應用程序的歷史，你須要啓動歷史記錄服務器配置歷史記錄服務器能夠規定給它分配多少內存
各類JVM的選項，服務器的公共地址以及一系列的屬性




集羣中的任何一種資源都有可能成爲Spark的瓶頸
Spark的內存計算屬性，數據序列化以及內存優化成爲可以提高Spark效能的
兩個主要的因素。


數據的序列化是一種提高網絡效能並減小內存使用的關鍵這是當你要優化Spark應用程序須要優先考慮的
Spark提供兩個數據序列化的庫。Java序列化提供更多的選擇，可是它們一般很慢
並且生成過大的序列化對象。但這個是Spark用來序列化對象的默認庫
Kyro序列化比Java要快不少，可是不支持全部的序列化類型
你須要提早註冊這些類庫，來得到最好的性能效果,能夠經過設置SparkConf對象來使用Kyro序列化




在內存優化中，你須要考慮三件事：
1)對象使用的內存有多少(不管你是否想將所有對象導入到內存中); 
2)獲取這些對象的成本;
3)垃圾回收的管理費用


你建立一個RDD，先將它緩存，而後查看你驅動程序中的
SparkContext日誌。查看日誌能夠幫助你瞭解數據集須要多少內存
這裏有減小每一個對象內存使用量的一些建議。儘可能避免增長管理費用的某些Java特徵
好比基於指針的數據結構和wrapper對象。若是能夠的話,使用數組或者原始數據類型而且避免使用迭代結構




序列化儲存也能夠幫助減小內存使用。缺點是它會致使要花更多的時間來獲取數據
由於在你使用這些數據以前，你必需要對它們進行反序列化


你能夠在垃圾回收器中查看它發生的頻率，以及它使用時間的、一系列指標。你能夠經過將此行增長到SPARK_JAVA_OPTS環境變量中來實現它


爲了要充分利用集羣，並行的級別也是須要考慮的因素之一
它自動地被設置爲任務文件的大小，可是你能夠經過例如在SparkContext.textFile裏的
選項參數來配置它。你也能夠對spark.default.parallelism的config屬性設置默認的並行級別。一般來講，咱們建議在集羣中
爲每個CPU核設置2到3個任務
當你的內存不能容納你的RDD的時候，你會獲得一個OutOfMemoryError錯誤
在這種狀況下，經過提高並行級別能夠解決這個問題
經過提高並行級別，每個輸入的任務集都會變得更小，這樣內存就能夠容納了




經過Spark的廣播變量的功能，能夠極大地減少序列化對象的大小
有一個比較好的例子，好比你有某種靜態的公共查詢表
考慮一下把它變成一個廣播變量，這樣它就不須要被髮送到
每個worker節點上，省去了不少序列化對象的工做
Spark將每個任務序列化以後的大小打印到主節點上。經過查看這些信息，
也能夠幫助檢查否有任務過大。若是你發現某些任務超過20KB，你就有必要考慮
是否須要對它進行優化，好比建立廣播變量

 

 

 

 Spark1.0.0能夠經過如下幾種方式來對Spark應用程序進行監控：

• Spark應用程序的WebUI或者Spark Standalone的集羣監控
• 指標，而後經過支持指標收集的集羣監控系統，如ganglia進行監控
• 輔助監控工具

1：WebUI
      Spark應用程序提交後，driver和Executor之間不斷的交換運行信息，能夠經過driver的4040端口（默認端口）獲取有用的Spark應用程序的運行信息，如：

• Stage和Task
• RDD大小和內存使用狀況
• 環境變量信息
• executor的運行信息
• ...

      若是多個Spark應用程序在同一個client上以client方式提交，那麼driver的WebUI端口將綁定從4040開始的連續端口，如4040、404一、4042...。
      須要注意的是，用過WebUI只能查看Spark應用程序在運行期間的信息，一旦Spark應用程序運行完，這些信息將沒法查看，由於WebUI端口隨Spark應用程序的完成而關閉。若是想要過後查看Spark應用程序的運行信息，那麼須要配置history Server來持久化Spark應用程序運行信息。關於history Server參見Spark1.0.0 history server配置（正在撰寫，遲點給上連接） 。

2：指標
      Spark採用了基於Coda Hale Metrics Library 的可配置的指標體系，經過各類指標收集器，如JMX、CSV、GraphiteSink、Ganglia等能夠進行彙總報告。該指標體系的配置文件位於conf/metrics.properties（經過複製conf/metrics.properties.template生成或自建），若是要採用自定義的配置文件，還須要在屬性配置上配置一下spark.metrics.conf。
      Spark的指標體系針對Spark不一樣的組件分解成相應的實例，每一個實例涵蓋一套指標。Spark如今支持的實例有：

• master
• worker
• applications
• driver
• executor

      Spark的指標體系支持多種收集器，每一個實例能夠採用多個收集器，也能夠不採用。Spark支持的收集器定義在org.apache.spark.metrics.sink，如今支持的收集器有：

• ConsoleSink
• CSVSink.
• JmxSink
• MetricsServlet
• GraphiteSink
• GangliaSink 由於版權問題，部署包默認不含有該收集器；若是須要，要從新編譯嵌入LGPL受權代碼的源碼。具體使用參見用ganglia監控Spark1.0.0（正在撰寫，遲點給上連接）。

3：輔助監控工具
      能夠經過一些輔助監控工具對Spark應用程序運行先後和運行過程當中系統性能變化來監控Spark應用程序。這些輔助工具備：

• 集羣監控系統，如ganglia、negios、zabbix等，這些工具能夠監控整個集羣的磁盤、網絡、內存利用率和性能瓶頸；
• 操做系統性能分析工具，如dstat、iostat、iotop，這些工具能夠對單臺機器的性能進行細緻地分析；
• JVM性能分析工具，如 jstack、jmap、jstat 、jconsole，這些工具能夠對JVM進行詳細的性能分析。