问题导读 1.在传大量数据的情况下,communication manager换成netty-based的实现了,实现这个功能有什么好处? 2.Spark SQL中缓存表一定要用cacheTable(“tableName”)这种形式,为什么?
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,都是表达相同的语义,都能享受到列式存储带来的好处。
|