【編者按】在"Spark 1.4：SparkR發布，鎢絲計劃鋒芒初露"一文中，我們有簡單地介紹了1.4版本給Spark注入的新特性，在各個組件的介紹中也提到了新UI給用戶帶來的便捷。而從本文開始，我們將通過Databricks Blog上的系列文章深入了解新版本中的數據可視化，首先分享的是這個系列的第一篇博文——Understanding your Spark application through visualization，作者 Andrew Or。
以下為譯文
圖片最大的價值就是它可以讓我們發現未曾預期的事情——John Tukey。
在過去，Spark UI一直是用戶應用程序調試的幫手。而在最新版本的Spark 1.4中，我們很高興地宣布，一個新的因素被注入到Spark UI——數據可視化。在此版本中，可視化帶來的提升主要包括三個部分：
Spark events時間軸視圖
Execution DAG
Spark Streaming統計數字可視化
我們會通過一個系列的兩篇博文來介紹上述特性，本次則主要分享前兩個部分——Spark events時間軸視圖和Execution DAG。Spark Streaming統計數字可視化將在下一篇博文中解釋。
Spark events時間軸視圖
從Spark 初期版本至今，Spark events一直是面向用戶API的一部分。在最新的1.4版本，Spark UI將會把這些events在一個時間軸中顯示，讓用戶可以一眼區別相對和交叉順序。
時間軸視圖可以覆蓋3個等級：所有Job，指定的某個Job，以及指定的某個stage。在下圖中，時間軸顯示了橫跨一個應用程序所有作業中的Spark events。
這里的events順序相對簡單，在所有 executors 注冊后，在應用程序并行運行的4個job中，有一個失敗，其余成功。當所有工作完成，并在應用程序退出后，executors同樣被移除。下面不妨點擊關注其中的一個job：
該job在3個文件中做word count，最后join并輸出結果。從時間軸上看，很明顯， 3個 word count stages 并行運行，因為它們不互相依賴。同時，最后一個階段需要依賴前3個文件word count的結果，所以相應階段一直等到所有先行階段完成后才開始。下面著眼單個stage：
這個stage被切分為20個partitions，分別在4臺主機上完成（圖片并沒有完全顯示）。每段代表了這個階段的一個單一任務。從這個時間軸來看，我們可以得到這個stage上的幾點信息。
首先，partitions在機器中的分布狀態比較樂觀。其次，大部分的任務執行時間分配在原始的計算上，而不是網絡或I/ O開銷。這并不奇怪，因為傳輸的數據很少。最后，我們可以通過給executors分配更多的核心來提升并行度；從目前來看，每個executors可以同時執行不超過兩個任務。
借此機會展示一下Spark通過該時間軸獲得的另一個特性——動態分配。該特性允許Spark基于工作負載來動態地衡量executors 的數量，從而讓集群資源更有效地共享。不妨看向下張圖表：
首先要注意的是，這個應用程序是在工作的過程中獲得executors ，而不是預先分配好。在第一個job結束后，用于該job的executors將閑置并返回到集群。因此在這個期間，同集群中運行的其他應用程序可以獲得這些資源，從而增加集群資源利用率。只有當一個新的job執行時，Spark應用程序才會獲取一組新的executors 來運行它。
在一個時間軸中查看Spark events的能力有助于確定應用程序瓶頸，從而在調試過程中進行更有針對性的優化。
Execution DAG
在新版本的Spark中，第二個可視化聚焦DAG執行的每個作業。在Spark中，job與被組織在DAG中的一組RDD依賴性密切相關，類似下圖：
這個job執行一個簡單的word cout。首先，它執行一個textFile從HDFS中讀取輸入文件，然后進行一個flatMap操作把每一行分割成word，接下來進行一個map操作，以形成form（word，1）對，最后進行一個reduceByKey操作總結每個word的數值。
可視化的藍色陰影框對應到Spark操作，即用戶調用的代碼。每個框中的點代表對應操作下創建的RDDs。操作本身由每個流入的stages劃分。
通過可視化我們可以發現很多有價值的地方。首先，根據顯示我們可以看出Spark對流水線操作的優化——它們不會被分割。尤其是，從HDF S讀取輸入分區后，每個executor隨后即對相同任務上的partion做flatMap和map，從而避免與下一個stage產生關聯。
其次，RDDs在第一個stage中會進行緩存（用綠色突出表示），從而避免對HDFS（磁盤）相關讀取工作。在這里，通過緩存和最小化文件讀取可以獲得更高的性能。
DAG可視化的價值在復雜jobs中體現的尤為明顯。比如下圖中的ALS計算，它會涉及到大量的map、join、groupByKey操作。
值得注意的是，在ALS中，緩存準確性將對性能產生的影響非常大，因為該算法在每次迭代中會重度使用之前步驟產生的結果。如今通過DAG可視化，用戶和開發人員可以一目了然地查明RDDS是否被恰當地緩存，如果沒有，可以快速理理解實現緩慢的原因。
與時間軸視圖一樣，DAG可視化允許用戶點擊進入一個stage進行更詳細地觀察。下圖描述了ALS中一個獨立的stage。
在stage視圖中，屬于這個stage的所有RDDS細節被自動展開。當前，用戶可以快速地找到具體的RDDS信息，而不必job頁面通過懸停各個點來猜測和檢查。
最后，在這里突出一下DAG可視化和 SparkSQL之間的一個初步的集成。對比更接近物理實體層面的Spark操作，Spark SQL用戶顯然更熟悉一些高級操作，因此一些高級操作更需要被可視化。其結果類似將一個SQL查詢計劃映射到底層執行的DAG。
與SparkStreaming的整合在Spark 1.4版本中同樣有所實現，這里在下一篇博文中會詳細介紹。
在不久的將來，Spark UI可以更理解一些更高級別的函數庫語義，以提供更多相關細節。 同時，Spark SQL將與Spark Streaming一樣獲得類似的標簽。而在Spark Core中，當用戶查看RDD時，類似partitions數量、調用點、緩存率都將會被可視化。
在此感謝社區中所有對可視化工作有所貢獻的組織和個人，更特別感謝NTT Data的@sarutak在時間軸可視化特性中的主要貢獻。
京公網安備 11010502049343號