Spark The Definitive Guide(Spark權威指南) 中文版。本書詳細介紹了Spark2.x版本的各個模塊，目前市面上最好的Spark2.x學習書籍！！！
掃碼關注公衆號:登峯大數據，閱讀中文Spark權威指南(完整版)，系統學習Spark大數據框架！
如果您覺得作者翻譯的內容有幫助，請分享給更多人。您的分享，是作者翻譯的動力
本章將介紹監控和調試Spark應用程序所需的關鍵細節。爲此，我們將使用一個示例查詢遍歷Spark UI，該查詢旨在幫助您理解如何在執行生命週期中跟蹤自己的作業。我們將看到的示例還將幫助您瞭解如何調試作業以及可能發生錯誤的位置。
18.1. 監控概覽
在某種程度上，您需要監控Spark作業，以瞭解其中發生的問題。有必要回顧一下我們實際上可以監控的不同內容，並概述一些選項。讓我們回顧一下可以監控的組件(參見圖18-1)。
圖18-1可以監控的Spark應用程序的組件
Spark應用程序和作業jobs
在調試或更好地理解應用程序如何在集羣上執行時，首先要監控的是Spark UI和Spark日誌。這些是有關當前在Spark概念級別上運行的應用程序的信息，例如RDDs和查詢計劃。我們將在本章中詳細討論如何使用這些Spark監控工具。
JVM
Spark在單個Java虛擬機(jvm)中運行Executor。因此，下一個詳細級別將是監控各個虛擬機(vm)，以便更好地理解代碼的運行方式。JVM工具，如用於提供堆棧跟蹤的jstack、用於創建堆轉儲的jmap、用於報告時間序列統計信息的jstat和用於可視化地研究各種JVM屬性的jconsole，對於熟悉JVM內部的人來說是非常有用的。您還可以使用像jvisualvm這樣的工具來幫助配置Spark作業。其中一些信息是在Spark UI中提供的，但是對於非常底層的調試，上述工具可以派上用場。
操作系統/服務器
jvm運行在主機操作系統(OS)上，監控這些機器的狀態以確保它們是健康的非常重要。這包括監控CPU、網絡和I/O之類的東西。這些通常在集羣級監控解決方案中報告;但是，您可以使用更具體的工具，包括dstat、iostat和iotop。
集羣
當然，您可以監控將要運行Spark應用程序的集羣。這可能是一個yarn、Mesos或standalone集羣。通常，在這裏有某種監控解決方案是很重要的，因爲很明顯，如果集羣不工作，您可能很快就會知道。一些流行的集羣級監控工具包括Ganglia和Prometheus。
18.2. 如何監控
在簡要介紹了監控環境之後，讓我們討論如何監控和調試Spark應用程序。您需要監控兩件主要的事情:運行應用程序的進程(在CPU使用量、內存使用量等級別)，以及其中的查詢執行(例如，作業和任務)。
18.2.1. Driver程序和Executor程序進程
當您監視Spark應用程序時，您肯定想要監視driver程序。這是應用程序的所有狀態所在的位置，您需要確保它以穩定的方式運行。如果您只能監視一臺機器或單個JVM，那麼它肯定是driver程序。話雖如此，瞭解executors的狀態對於監視單個Spark作業也非常重要。爲了幫助解決這個問題，Spark提供了一個基於Dropwizard metrics庫(https://metrics.dropwizard.io/4.0.0/)的可配置度量系統。度量系統是通過配置文件配置的，默認配置文件位於$SPARK_HOME/conf/metrics.properties。可以通過更改spark.metrics.conf配置屬性來指定自定義文件位置。這些度量可以輸出到各種不同的接收器，包括Ganglia之類的集羣監控解決方案。
18.2.2. Queries, Jobs, Stages, 和 Tasks
儘管監控driver程序和executor程序進程很重要，但有時您需要調試特定查詢級別上發生的事情。Spark提供了深入Queries, Jobs, Stages, 和Tasks的能力。(我們在第15章學過這些)該信息允許您準確地知道在給定時間集羣上運行的是什麼。在尋找性能調優或調試時，您最有可能從這裏開始。
現在我們知道了想要監控的內容，讓我們來看看兩種最常見的方法:Spark日誌和Spark UI。
18.2.2.1.Spark日誌
監控Spark最詳細的方法之一是通過它的日誌文件。Spark日誌中的特定日誌輸出，或者您添加到Spark應用程序的日誌中的特定日誌輸出，可以幫助您準確地記錄job的失敗位置或導致失敗的原因。如果您使用該書提供的應用程序模板(https://github.com/databricks/Spark-The-Definitive-Guide)，我們在模板中設置的日誌框架將允許您的應用程序日誌與Spark自己的日誌一起顯示，使它們非常容易關聯。然而，一個挑戰是Python不能直接與Spark的基於java的日誌庫集成。然而，使用Python的日誌模塊，甚至簡單的print語句，仍然會將結果打印到標準錯誤輸出中，並使它們更容易找到。
要更改Spark的日誌級別，只需運行以下命令:
spark.sparkContext.setLogLevel("INFO")
這將允許你查看日誌，如果使用我們的應用程序模板，可以將自己的相關信息與這些日誌一起記錄下來，從而允許您同時檢查自己的應用程序和Spark。在運行本地模式應用程序時，日誌本身將打印爲標準錯誤，或者在集羣上運行Spark時由集羣管理器保存到文件中。參考每個集羣管理器的文檔，瞭解如何找到它們——通常，它們可以通過集羣管理器的web UI獲得。
僅僅通過搜索日誌並不總能找到所需的答案，但是它可以幫助您精確定位遇到的給定問題，並可能在應用程序中添加新的日誌語句來更好地理解它。隨着時間的推移，收集日誌以便將來引用它們也很方便。例如，如果您的應用程序崩潰，您將需要調試原因，而不需要訪問現在已崩潰的應用程序。還可能希望將寫在上面的日誌從機器上發出，以便在機器崩潰或關閉(例如，如果在雲中運行)時保存日誌。
18.2.2.2.Spark UI
Spark UI提供了一種可視化的方法，可以在應用程序運行時監控它們，並在Spark和JVM級別監視有關Spark工作負載的指標。運行中的每個SparkContext都會啓動一個web UI(默認情況下是在端口4040上)，顯示關於應用程序的有用信息。例如，在本地local模式下運行Spark時，只需導航到http://localhost:4040，以查看在本地機器上運行Spark應用程序時的UI。如果正在運行多個應用程序，它們將在增加端口號(4041、4042、…)的情況下啓動web ui。集羣管理器還將從各自的UI鏈接到每個應用程序的web UI。
圖18-2顯示了Spark UI中可用的所有選項卡。
這些選項卡可用於我們想要監控的每個選項。在大多數情況下，每一項都應不言自明:
-
Jobs選項卡用於查看Spark jobs。
-
Stage選項卡屬於各個stage(及其相關task)。
-
Storage選項卡包含當前緩存在Spark應用程序中的信息和數據。
-
Environment選項卡包含有關Spark應用程序的配置和當前設置的相關信息。
-
SQL選項卡展示我們的結構化API查詢(包括SQL和DataFrames)。
-
Executor選項卡提供關於運行應用程序的每個Executor的詳細信息。
讓我們通過一個示例來了解如何深入到給定的查詢。打開一個新的Spark shell，運行以下代碼，我們將通過Spark UI跟蹤它的執行情況:
這將產生三行不同的值。這段代碼啓動了一個SQL查詢，所以讓我們導航到SQL選項卡，您應該會看到類似於圖18-3的內容。
您首先看到的是關於這個查詢的聚合統計信息:
這些稍後將變得非常重要，但首先讓我們看一下Spark stage的有向無環圖(DAG)。這些選項卡中的每個藍色框表示包含Spark tasks的一個stage。所有這些stage代表了我們的Spark job。讓我們詳細查看每個stage，以便更好地理解每個級別正在發生什麼，從圖18-4開始。
頂部的框名爲WholeStateCodegen，表示CSV文件的完整掃描。下面的框表示我們在調用重分區時強制執行的shuffle。這將我們的原始數據集(一個尚未指定分區數量的數據集)轉換爲兩個分區。
下一步是投影(選擇/添加/過濾列)和聚合。注意，在圖18-5中，輸出行數爲6。這很容易與聚合時輸出行數乘以分區數相乘。這是因爲在對數據進行shuffle之前，Spark對每個分區執行聚合(在本例中是基於散列的聚合)，準備進入最後一個stage。
最後一個stage是子聚合的聚合，我們在前一個stage看到的子聚合是基於每個分區的。我們將這兩個分區合併到最後三行中，這三行是總查詢的輸出(圖18-6)。
讓我們進一步研究這項工作的執行情況。在“Jobs”選項卡上，單擊“SucceededJob”旁邊的“2”。如圖18-7所示，我們的工作分爲三個stage(與我們在SQL選項卡上看到的相對應)。
這些stage的信息或多或少與圖18-6所示相同，但是單擊其中一個stage的標籤將顯示給定stage的詳細信息。在本例中，運行了三個stage，每個stage有8個、2個和200個任務。在深入討論stage細節之前，讓我們回顧一下爲什麼會出現這種情況。
第一個stage有八個任務。CSV文件是可分割的，Spark將需要在機器上不同core之間相對均勻分配的工作進行了分割。這發生在集羣級別，並指向一個重要的優化:如何存儲文件。下面的stage有兩個任務，因爲我們顯式地調用了一個重分區來將數據移動到兩個分區中。最後一個stage有200個任務，因爲默認的shuffle分區值是200。
現在我們已經回顧了我們是如何到達這裏的，單擊帶有8個任務的stage來查看下一個級別的詳細信息，如圖18-8所示。
Spark提供了很多關於該作業運行時的詳細信息。在頂部，請注意Summary Metrics部分。這提供了關於各種度量的統計數據的概要。您需要注意的是值的不均勻分佈(我們將在第19章中討論這個問題)。在本例中，一切看起來都非常一致;值的分佈沒有大的波動。
在底部的表中，我們還可以根據每個Executor檢查(在本例中，針對此特定機器上的每個core)。這可以幫助確定特定的Executor是否充分利用了其工作負載。
Spark還提供了一組更詳細的指標，如圖18-8所示，這些指標可能與大多數用戶無關。要查看這些，單擊Show Additional Metrics，然後根據您想要看到的內容，選擇對應的統計信息。
您可以對要分析的每個階段重複此基本分析。我們把它留給讀者作爲練習。
18.2.2.3.其他Spark UI選項卡
其餘的Spark選項卡：Storage, Environment, 和Executors相當容易理解。Storage選項卡顯示關於集羣上緩存的RDDs/DataFrames的信息。這可以幫助您查看某些數據是否已隨時間從緩存中刪除。Environment選項卡顯示有關運行時環境的信息，包括關於Scala和Java的信息，以及您在集羣上配置的各種Spark屬性。
18.2.2.4.配置SparkUI
您可以針對Spark UI設置許多配置。其中許多是網絡配置，比如啓用訪問控制。另一些工具允許您配置Spark UI的行爲(例如，存儲了多少作業、階段和任務)。由於空間限制，我們不能在這裏包含整個配置集。請參閱Spark文檔中有關Spark UI配置的相關表(http://spark.apache.org/docs/latest/monitoring.html#spark-configuration-options)。
18.2.2.5.Spark REST API
除了Spark UI之外，您還可以通過REST API訪問Spark的狀態和指標。這可以在http://localhost:4040/api/v1上找到，這是一種基於Spark本身構建可視化和監視工具的方法。在大多數情況下，這個API公開了web UI中呈現的相同信息，只是它不包含任何sql相關的信息。如果您希望基於Spark UI中的可用信息構建自己的報表解決方案，那麼這將是一個非常有用的工具。由於空間限制，我們不能在這裏包含API端點列表。參考Spark文檔中有關REST API端點的相關表。
18.2.2.6.Spark UI History Server
通常，Spark UI只在SparkContext運行時可用，所以在應用程序崩潰或結束後如何訪問它?爲此，Spark包含一個名爲Spark History Server的工具，允許您重現Spark UI和REST API，前提是將應用程序配置爲保存事件日誌。您可以在Spark文檔中找到關於如何使用此工具的最新信息。
要使用history server，首先需要配置應用程序將事件日誌存儲到特定位置。您可以通過啓用spark.eventLog.enabled來實現這一點，並配置spark.eventLog.dir事件日誌位置。然後，一旦存儲了事件，就可以將history server作爲獨立的應用程序運行，它將根據這些日誌自動重構web UI。一些集羣管理器和雲服務還自動配置日誌記錄，默認情況下運行了history server。
history server還有許多其他配置。由於空間限制，我們不能在這裏包含整個配置集。請參閱Spark文檔中有關Spark History Server配置的相關表。
18.3. 常見Spark問題解決方法
前面的部分定義了一些核心的“生命體徵”，即我們可以監視的東西，以檢查Spark應用程序的健康狀況。在本章的其餘部分中，我們將採用“急救”方法來進行Spark調試:我們將回顧Spark作業中出現的一些問題的跡象和症狀，包括您可能觀察到的跡象(例如，緩慢的任務)，以及Spark本身的症狀(例如OutOfMemoryError)。有很多問題可能會影響Spark jobs，所以不可能涵蓋所有內容。但我們將討論一些更常見的Spark問題，您可能會遇到。除了症狀和體徵外，我們還將探討一些治療這些問題的潛在方法。