【編者按】在"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對流水線操作的優化——它們不會被分割。尤其是，從HDFS讀取輸入分區後，每個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在時間軸可視化特性中的主要貢獻。
英文原文：Understanding your Spark application through visualization（翻譯/王輝
責編/仲浩）
