当下已活跃在Hortonworks、IBM、Cloudera、MapR和Pivotal等众多知名大数据公司，更拥有Spark SQL、Spark Streaming、MLlib、GraphX等多个相关项目。那么如此多的关注下，Spark又会有什么样的变化，下面看Spark 1.2版本新特性。
在2014年，Spark开源生态系统得到了大幅增长，已成为大数据领域最活跃的开源项目之一，当下已活跃在Hortonworks、IBM、Cloudera、MapR和Pivotal等众多知名大数据公司，更拥有Spark SQL、Spark Streaming、MLlib、GraphX等多个相关项目。那么如此多的关注下，Spark又会有什么样的变化，下面我们一起看Spark Contributor、Spark布道者陈超总结的Spark 1.2版本新特性：
下为原文
1.2居然真的在12月份发布了，我表示略感意外，我一直以为稍微跳个票要到明年一月初才能发的。这次更新有172个开发者参与，并且有1000多个commits。这真是一个了不起的数字。本次版本给我们带来了很多新特性，并且也有不少的性能优化点。我说几个比较重要的吧。
Spark Core：
1、在传大量数据的情况下，communication manager终于换成netty-based的实现了。之前的实现慢的要死是因为每次都要从磁盘读到内核，再到用户态，再回到内核态进入网卡，现在用zerocopy来实现了。（想起来没，Kafka也是用的这个）。
2、shuffle manager换成sort based了，在shuffle数据比较大的时候，性能会有提升。不过也有不少人认为这个Hadoop的sort是一样的，微博上也有人提出了这一点，本想回复解释时，发现连城已经回复了。其实目前Spark的sort只是按照Partition key排序，Partition内部目前是不排序的，不过就算内部要排序，也是比较容易实现的。而Hadoop是按照每个Partition内的每个KV排序的。
Spark Streaming :
终于“号称”支持fully H/A模式了。以前当driver挂掉的时候，可能会丢失掉一小部分数据。现在加上一层WAL（write ahead log），好多地方都在用这玩意儿，还记得HBase的write path吗？每次写到memstore之前都会写到一个叫HLog的地方，以防止数据丢失。回到这个问题，每次receiver收到数据后都会存在HDFS上，这样即使driver挂掉，当它重启起来后，还是可以接着处理。当然WAL的实现也还是那样子，到driver重启后，要recover data，并且也要clean掉那些过时的数据。
当然，我还要特别提醒下 unreliable receivers和reliable receivers这两个事情，有兴趣的自己去看下什么个情况吧。
MLlib
这里最重大的改变应该是Pipeline了，很多从事机器学习的朋友肯定会有兴趣的。MLlib的老大祥瑞在北京已经谈过这个了，这里不展开，需要指出的是，目前MLlib是用SchemaRDD来代表数据集的。也就是说，打通了Spark SQL与MLlib间的通道。话说在一起吃饭时我揪着祥瑞谈了一些DataBricks Cloud的事情，没问MLlib的事情，就知道他回来度个假，PR已经急剧增加了。
GraphX
这一版本最引人注意的应该是给出了stable api，这意味着你们不用担心现在写的代码以后还要由于API的变化而改动了。插播广告，下周杭州Spark Meetup，会有GraphX的一个精彩主题。
Spark SQL
把这块放最后的原因是，Spark SQL真是太火了，所以你们要提PR就赶快提，赶快响应，赶快merge，不然保不准在短时间内就给你来个conflict。这版本最重要的特性毫无疑问应该属于external data source吧，套用连城PPT上的一句话，push predicates to datasource，什么意思呢，譬如你要从HBase取数据后做一些筛选，一般我们需要把数据从HBase全取出来后在Spark引擎中筛选，现在呢，你可以把这个步骤推到Data Source端，让你在取数据的时候就可以筛选。当然，这块肯定还会有很大的改动。
另一点必须要指出，我以前在很多场合都提醒大家，Spark SQL中缓存表一定要用cacheTable(“tableName”)这种形式，否则无法享受到列式存储带来的一系列好处，但是很多朋友仍然采用rdd.cache这种原生的方式来缓存，社区也意识到这样不行，所以现在无论是cacheTable还是直接cache，都是表达相同的语义，都能享受到列式存储带来的好处。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
