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，也许就是这个适合你们的架构。

 

后记：尽管没有几个小时间，我发现实力彻底死。你还须要锻炼。练习啊。