What’s new in Spark 1.2.0

What’s new in Spark 1.2.0

1.2.0 was released on 12/18, 2014

在2014年5月30日公佈了Spark 1.0 和9月11日公佈了Spark1.1.後，Spark 1.2 最終在12月18日公佈。做爲1.X時代的第三個release，它有什麼重要更新呢？

1.    Spark Core：性能和易用性的改進

對於超大規模的Shuffle，Spark Core在性能和穩定性方面作了兩個重要的更新：

一）     Communication Manager使用Netty實現

在1.1 以前，對於Shuffle的結果回傳。有兩種方式，對於較小的結果，直接使用akka的消息傳遞機制。對於較大的結果。則採用BlockManager。採用BlockManager是不錯的設計，可以避免Driver佔用過多的內存而OOM而且下降了GC的風險。但是，BlockManger的處理是低效的：它先從Disk中將結果讀取到kernel的buffer，而後到用戶空間的buffer，而後又到了kernel的send buffer，這期間有屢次的內存拷貝和kernel space到user space的切換代價。着不僅僅是佔用了JVM的沒必要要的內存，而且還添加了GC的頻率。

只是。使用FileChannel.transferTo，可以作到zero copy。詳細可見http://www.ibm.com/developerworks/library/j-zerocopy/

當中一種實現就是Netty。1.2中。使用Netty 重寫了Communication Manager。實際上。在org.apache.spark.network.netty中已經實現了netty得網絡模塊，但是因爲不無缺而這個選項默認是沒有打開的。

而且，使用Netty已是默認的了。spark.shuffle.blockTransferService 已經從1.1的nio變成1.2 中新增的netty了。

關於這個PR的詳情可見 https://issues.apache.org/jira/browse/SPARK-2468

二）     Shuffle的默認機制從hashbased 轉化爲sort based

MapReduce被人詬病之中的一個就是不管sort是否必要，都需要排序。Spark在1.1以前。都是hash based Shuffle。但是hash based會佔用大量的內存。固然了在內存不夠用時，也會spill到disk，而後最後再作一次merge。對於比較大的數據集，因爲有disk IO，所以性能也會有所降低。Shuffle的性能的好壞可以說直接影響整個job的性能也不爲過。在1.1的時候，引入了sort based shuffle。在1.2的時候，這個已經可以成熟而且成爲默認的選項：

spark.shuffle.manager 從hash 變爲sort。

而且從做者Reynold Xin的測試來看。sort 在速度和內存使用方面優於hash：「sort-based shuffle has lower memory usage and seems to outperformhash-based in almost all of our testing.」

2.    MLlib： 擴充了Python API

3.    Spark Streaming：實現了基於WriteAhead Log（WAL）的HA，避免因爲Driver異常退出致使的數據丟失

4.    GraphX： 性能和API的改進（alpha）

 

Spark 1.2 是來自60多家企業，學校等研究機構的172位貢獻者的一次重要公佈。從Contributor的數量看。Spark社區依舊是最活躍的開源社區之中的一個。

 

從Spark的歷次更新都可以看出，高速迭代是互聯網的王道。

Spark發展到現在，儘管依舊有這種那樣的問題，但是依靠不斷的迭代，各大廠商的支持和各位contributor的不斷付出，相信社區會持續高速發展。

儘管商業軟件可能幾年前就已經攻克了這些問題。商業軟件可能在某個應用場景已經有了最佳的實現。但是互聯網的稟賦就在於不求最優。僅僅求合適。而且對於各個中小型的互聯網公司來講。場景不斷在變。需要一個本身可以掌控的架構，隨着自身的發展不斷的在這個架構上作高速的迭代。

而Spark，也許就是這個適合你們的架構。

 

後記：儘管沒有幾個小時間，我發現實力徹底死。你還須要鍛鍊。練習啊。