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，或許就是這個適合你們的架構。

 

後記：雖然沒有幾個小時，發現體力徹底不行了。之後仍是須要鍛鍊身體，鍛鍊身體啊。