新的可視化幫助更好地了解Spark Streaming應用程序

之前，我們展示了在Spark1.4.0中 新推出的可視化功能 （ 《Spark 1.4：SparkR發布，鎢絲計劃鋒芒初露》 [中文版]），用以更好的了解Spark應用程序的行為。接著這個主題，這篇博文將重點介紹為理解Spark Streaming應用程序而引入的新的可視化功能。我們已經更新了Spark UI 中的 Streaming標簽頁來顯示以下信息：

• 時間軸視圖和事件率統計，調度延遲統計以及以往的批處理時間統計
• 每個批次中所有JOB的詳細信息

此外，為了理解在Streaming操作上下文中job的執行情況，有向無環執行圖的可視化（ execution DAG visualization ）增加了Streaming的信息。

讓我們通過一個從頭到尾分析Streaming應用程序的例子詳細看一下上面這些新的功能。

處理趨勢的時間軸和直方圖

當我們調試一個Spark Streaming應用程序的時候，我們更希望看到數據正在以什么樣的速率被接收以及每個批次的處理時間是多少。Streaming標簽頁中新的UI能夠 讓你很容易的看到目前的值和之前1000個批次的趨勢情況。當你在運行一個Streaming應用程序的時候，如果你去訪問Spark UI中的Streaming標簽頁，你將會看到類似下面圖一的一些東西（紅色的字母，例如[A]，是我們的注釋，并不是UI的一部分）。

圖1：Spark UI中的Streaming標簽頁

第一行（標記為 [A] ）展示了Streaming應用程序當前的狀態；在這個例子中，應用已經以1秒的批處理間隔運行了將近40分鐘;在它下面是輸入速率（Input rate）的時間軸（標記為  [B] ），顯示了Streaming應用從它所有的源頭以大約49 events每秒的速度接收數據。在這個例子中，時間軸顯示了在中間位置（標記為 [C] ）平均速率有明顯的下降，在時間軸快結束的地方應用又恢復了。如果你想得到更多詳細的信息，你可以點擊  Input Rate 旁邊（靠近 [B] ）的下拉列表來顯示每個源頭各自的時間軸，正如下面圖2所示：

圖2

圖2顯示了這個應用有兩個來源，( SocketReceiver-0 和  SocketReceiver-1) ， 其中的一個導致了整個接收速率的下降，因為它在接收數據的過程中停止了一段時間。

這一頁再向下（在圖1中標記為 [D] ），處理時間（ Processing Time ） 的時間軸顯示，這些批次大約在平均20毫秒內被處理完成，和批處理間隔（在本例中是1s）相比花費的處理時間更少，意味著調度延遲（被定義為：一個批次等待之前批次處理完成的時間，被標記為  [E] ）幾乎是零，因為這些批次在創建的時候就已經被處理了。調度延遲是你的Streaming引用程序是否穩定的關鍵所在，UI的新功能使得對它的監控更加容易。

批次細節

再次參照圖1，你可能很好奇，為什么向右的一些批次花費更長的時間才能完成（注意圖1中的 [F] ）。你可以通過UI輕松的分析原因。首先，你可以點擊時間軸視圖中批處理時間比較長的點，這將會在頁面下方產生一個關于完成批次的詳細信息列表。

圖3

它將顯示這個批次的所有主要信息（在上圖3中以綠色高亮顯示）。正如你所看到的，這個批次較之其他批次有更長的處理時間。另一個很明顯的問題是： 到底是哪個spark job引起了這個批次的處理時間過長。你可以通過點擊Batch Time（第一列中的藍色鏈接），這將帶你看到對應批次的詳細信息，向你展示輸出操作和它們的spark job，正如圖4所示。

圖4

圖4顯示有一個輸出操作，它產生了3個spark job。你可以點擊job ID鏈接繼續深入到stages和tasks做更深入的分析。

Streaming RDDs 的有向無環執行圖

一旦你開始分析批處理job產生的stages和tasks，更加深入的理解執行圖將非常有用。正如之前的博文所說，Spark1.4.0加入了有向無環 執行圖（execution DAG ）的可視化（DAG即有向無環圖），它顯示了RDD的依賴關系鏈以及如何處理RDD和一系列相關的stages。如果在一個Streaming應 用程序中，這些RDD是通過DStreams產生的，那么可視化將展示額外的Streaming語義。讓我們從一個簡單的Streaming字數統計 （word count）程序開始，我們將統計每個批次接收的字數。程序示例 NetworkWordCount 。它使用DStream操作 flatMap, map 和  reduceByKey 來計算字數。任一個批次中一個Spark job的有向無環執行圖將會是如下圖5所示。

圖5

可視化展示中的黑點代表著在批處理時16:06:50由DStream產生的RDD。藍色陰影的正方形是指用來轉換RDD的DStream操作，粉色的方框代表這些轉換操作執行的階段。總之圖5顯示了如下信息：

• 數據是在批處理時間16:06:50通過一個socket文本流（ socket text stream ）接收的。
• Job用了兩個stage和 flatMap ,  map ,  reduceByKey 轉換操作來計算數據中的字數

盡管這是一個簡單的圖表，它可以通過增加更多的輸入流和類似 window 操作和 updateStateByKey 操作等高級的DStream轉換而變得更加復雜。例如，如果我們通過一個含三個批次的移動窗口來計算字數（即使用 reduceByKeyAndWindow ），它的數據來自兩個socket文本流，那么，一個批處理job的有向無環執行圖將會像如下圖6所示。

圖6

圖6顯示了于一個跨3個批次統計字數的Spark job的許多相關信息：

• 前三個stage實際上是各自統計窗口中3個批次的字數。這有點像上面例子 NetworkWordCount 的第一個stage，使用的是map和flatmap操作。不過要注意以下不同點：

• 這里有兩個輸入RDD，分別來自兩個socket文本流，這兩個RDD通過union結合成一個RDD，然后進一步轉換，產生每個批次的中間統計結果。
• 其中的兩個stage都變灰了，因為兩個較舊批次的中間結果已經緩存在內存中，因此不需要再次計算，只有最近的批次需要從頭開始計算。

• 最后一個右邊的stage使用 reduceByKeyAndWindow 來聯合每個批次的統計字數最終形成一個“窗口”的字數。

這些可視化使得開發人員不僅能夠監控Streaming應用程序的狀態和趨勢，而且能夠理解它們與底層spark job和執行計劃的關系。

未來方向

Spark1.5.0中備受期待的一個重要提升是關于每個批次( JIRA ,  PR )中輸入數據的更多信息。例如：如果你正在使用Kafka，批處理詳細信息頁面將會顯示這個批次處理的topics, partitions和offsets，預覽如下圖：

圖7

備注： 本文中的所有圖片均是大圖（有的超過3000PX），還請點擊下面的原文鏈接獲取高清大圖。

英文原文： New Visualizations for Understanding Spark Streaming Applications （譯者/付軍 審校/朱正貴 責編/仲浩） 

關于譯者： 付軍，平安科技資深開發工程師，主要做數據處理及報表展示方面工作，關注Hive、Spark SQL等大數據處理技術。