新的可視化幫助更好地瞭解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所示。