Druid中国用户组第一次线下技术交流资料分享

Druid(http://www.druid.io)作为一个开源的大数据OLAP分析引擎,得到了越来越多的关注。在Druid co-founder Fangjin Yang的支持下,阿里,OneAPM,Hulu,小米,蚂蜂窝,滴滴,携程等公司的同学共同成立了Druid China User Group的微信群,并决定与2016年2月20日下午举办第一次线下技术交流,欢迎对大数据分析,Druid,OLAP引擎等话题感兴趣的同学参加。

PPT下载链接:http://pan.baidu.com/s/1jHFspRg

技术交流议题:
1. Druid在Hulu的应用
演讲人:张汉生,Hulu北京AdIntelligence组软件研发工程师。主要参与Hulu广告定位和广告预测等相关工作,同时负责维护Druid集群。

2. Real-time Architecture for Online Travel
演讲人:Jin Yu,蚂蜂窝技术VP兼首席架构师。蚂蜂窝是中国最大的在线旅游社区,拥有超过1亿用户。在加入蚂蜂窝之前,Jin Yu是OpenX的技术VP和首席架构师,负责公司的数据战略,移动产品线和整体架构,其中就包括由5个全球数据中心的6000多台服务器组成的数据业务。Jin Yu还是连续创业者,他联合创办过2个创业公司:移动社交大数据领域的Portaura和电商搜索引擎领域的Martsoft。

3. OneAPM的Druid分析实践
演讲人:刘麒赟,OneAPM大数据高级架构师,主要负责OneAPM大数据架构的设计和开发工作。加入OneAPM之前是IBM BigInsights的大数据架构师,是多个Apache开源大数据项目的Contributor。

 

基于OpenStack, Docker和Spark打造SuperVessel大数据公有云

今年4月的Spark技术峰会上我做了《SuperVessel:基于OpenStack, Docker和Spark打造大数据公有云》的技术分享:

基于OpenStack和Docker打造Spark大数据服务

新浪微盘下载链接

1.首先请介绍下您自己,以及您在 Spark 技术方面所做的工作。

我是IBM中国研究院的高级研究员,大数据云方向的技术负责人,我的微博是@冠诚。我们围绕Spark主要做两方面的事情:

(1) 在IBM研究院的SuperVessel公有云(http://www.ptopenlab.com)上开发和运维Spark as a Service大数据服务。
(2) 在OpenPOWER架构的服务器上做Spark的性能分析与优化。

2.您所在的企业是如何使用 Spark 技术的?带来了哪些好处?

Spark作为新一代的大数据处理引擎主要带来了两方面的好处:
(1)相比于MapReduce在性能上得到了很大提升;
(2)在一个统一的平台上将批处理,SQL,流计算,图计算,机器学习算法等多种范式集中在一起,使得混合计算变得更加的容易。

3.您认为 Spark 技术最适用于哪些应用场景?

大规模机器学习,图计算,SQL等类型数据分析业务是非常适合使用Spark的。当然,在企业的技术选型过程中,并不是说因为Spark很火就一定要使用它。例如还有很多公司在用Impala做数据分析,一些公司在用Storm和Samaza做流计算,具体的技术选型应该根据自己的业务场景,人员技能等多方面因素来做综合考量。

4.企业在应用 Spark 技术时,需要做哪些改变吗?企业如果想快速应用 Spark 应该如何去做?

企业想要拥抱Spark技术,首先需要技术人员改变。是否有给力的Spark人才会是企业能否成功应用Spark最重要的因素。多参与Spark社区的讨论,参加Spark Meetup,给upstream贡献代码都是很好的切入方式。如果个人开发者想快速上手Spark,可以考虑使用SuperVessel免费的Spark公有云服务,它能快速创建一个Spark集群供大家使用。

5.您所在的企业在应用 Spark 技术时遇到了哪些问题?是如何解决的?

我们在对Spark进行性能调优时遇到很多问题。例如JVM GC的性能瓶颈,序列化反序列化的开销,多进程好还是多线程好等等。在遇到这些问题的时候,最好的方法是做好Profiling,准确的将性能瓶颈找到,再去调整相关的参数去优化这些性能瓶颈。
另一方面,我们发现如果将Spark部署在云环境里(例如OpenStack管理的Docker Container)时,它的性能特征和在物理机上部署又会有很大的不同,目前我们还在继续这方面的工作,希望以后能有机会跟大家继续分享。

6.作为当前流行的大数据处理技术,您认为 Spark 还有哪些方面需要改进?

在与OpenStack这样的云操作系统的集成上Spark还是有很多工作可以做的。例如与Docker Container更好的集成,对Swift对象存储的性能优化等等。

7.您在本次演讲中将分享哪些话题?

我将分享的话题是“基于OpenStack, Docker和Spark打造SuperVessel大数据公有云”:

随着Spark在2014年的蓬勃发展,Spark as a Service大数据服务正成为OpenStack生态系统中的新热点。另一方面,Docker Container因为在提升云的资源利用率和生产效率方面的优势而备受瞩目。在IBM中国研究院为高校和技术爱好者打造的SuperVessel公有云(www.ptopenlab.com)中,我们使用OpenStack, Docker和Spark三项开源技术,在OpenPOWER服务器上打造了一个大数据公有云服务。本次演讲我们会向大家介绍如何一步一步使用Spark, Docker和OpenStack打造一个大数据公有云,并分享我们在开发过程中遇到的问题和经验教训。

8.哪些听众最应该了解这些话题?您所分享的主题可以帮助听众解决哪些问题?

对如何构造一个大数据云感兴趣的同学应该会对这个话题感兴趣。对于开发SuperVessel的Spark as a Service服务过程中我们做的技术选型,架构设计,以及解决的问题应该能对大家有所帮助。

9. 您有什么需要对读者补充的吗?

Spark与云的结合将会是未来一个非常热的方向,希望有更多关注这个方向的同学与我交流,谢谢大家。

一步一步教你怎样给Apache Spark贡献代码

本文将教大家怎样用10个步骤完成给Apache Spark贡献代码这个任务:)

  1. 到 Apache Spark 的github 页面内点击 fork 按钮
  2. 你的github帐户中会出现 spark 这个项目
  3. 本地电脑上, 使用
git clone [你的 spark repository 的 github 地址]
例如:
git clone git@github.com:gchen/spark.git

本地得到一个叫 spark 的文件夹

4. 进入该文件夹,使用

git remote add upstream https://github.com/apache/spark.git

添加 Apache/spark 的远程地址

5. 使用

git pull upstream master 

得到目前的 Apache/spark 的最新代码,现在我们在 你自己fork的Spark代码仓库的master 这个分支上,以后这个分支就留作跟踪 upstream 的远程代码

6. 好了,现在你可以开始贡献自己的代码了。

按照开发惯例,我们一般不在自己代码仓库的master上提交新的代码,而是需要为每一个新增的功能或者bugfix新增一个新的branch。使用:

git checkout -b my_change

创建新的分支,现在我们可以在这个分支上更改代码

7. 添加代码,并提交代码:

* git add .

* git commit -m “message need to be added here”

8. 提交Pull Request前合并冲突

在我们提交完我们的代码更新之后,一个常见的问题是远程的upstream(即apache/spark)已经有了新的更新,从而会导致我们提交Pull Request时会导致conflict。为此我们可以在提交自己这段代码前手动先把远程其他开发者的commit与我们的commit合并。使用:

git checkout master

切换到我们自己的主分支,使用

git pull upstream master 

拉出apache spark的最新的代码。切换回 my_change 分支,使用

git checkout my_change
git rebase master

然后把自己在my_change分支中的代码更新到在自己github代码仓库的my_change分支中去:

git push origin my_change 

将代码提交到自己的仓库。

9. 提交Pull Request

这时候可以在自己的仓库页面跳转到自己的my_change分支,然后点击 new pull request。按照Spark的风格规定,我们需要在新的Pull Request的标题最前面加上JIRA代号。所以我们需要在https://issues.apache.org/jira/上创建一个新的JIRA,例如https://issues.apache.org/jira/browse/SPARK-2859。然后把SPARK-2859这个代号加到你的Pull Request的标题里面。

例如:https://github.com/apache/spark/pull/1782

Pull Rquest的描述的写法很重要。有几个要点:

(1)在Pull Request的描述中,一定记得加上你提交的JIRA的url,方便JIRA系统自动把Pull Request的链接加进去,例如https://issues.apache.org/jira/browse/SPARK-2859。

(2)PR的描述要言简意赅,讲清楚你要解决的问题是什么,你怎么解决的。大家可以多参考其他committer提交的PR。

10. 等待Spark committer审核你的PR。

如果需要进一步的代码修改,你可以继续在本地的my_change分支下commit新的代码,所有新的代码会在”git push origin my_change”之后自动被加入你之前提交的Pull Request中,方便进行问题的跟踪和讨论。

11.  如果一切顺利,具有apache/spark.git 写权限的commiter就会把你的代码merge到apache/spark.git的master里面去了!

恭喜你!相信你一定很开心吧?

Happy contributing to Spark!

ps. 你的代码被merge完之后,就可以把my_change这个分支给删掉了:)

注:本文写的比较仓促,是在@lufeihaidao的基础上直接修改而成,特此感谢:https://github.com/19wu/19wu/issues/41

参考:

How to use github pull request: https://help.github.com/articles/using-pull-requests

github的多人协作: https://gist.github.com/suziewong/4378619

How to rebase a pull request:https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request

我提交的一个JIRA例子:https://issues.apache.org/jira/browse/SPARK-2859

我提交的一个Spark PR的例子:https://github.com/apache/spark/pull/1782

大数据的价值密度

文 / 陈冠诚

注:原文刊载于《程序员》2014年第5期,略有删改。

在大数据和云计算如火如荼的今天,怎样将数据的商业价值变现成为各位老板和技术男们最关心的问题。马云经常讲,我不懂技术,所以我才要发力做云计算,做大数据。相信马总一定因为看到了云计算和大数据的潜在商业价值才做出上述决定的。在各位大佬争相跑马圈地的年代,各大公司都开始占领数据源头,从构建自己线上应用的生态圈入手,将用户的数据牢牢掌握在自己手中,以期望将来能从这些数据中挖掘出“潜在”的商业价值,例如在2014年风生水起的互联网金融行业就是其中典型。请注意,笔者这里专门对大数据的商业价值加上了“潜在”这两字。为什么需要这么关注这个字?其实这跟你的投资回报率非常有关系。

例如,大家都知道如果你能把新浪微博上的数据都扒拉下来,必然对很多生意都非常有帮助,例如各大电商网站,各大招聘网站等等。但是,你必须考虑清楚构建一个能存储和分析新浪微博数据的大数据平台的成本有多高,而你基于这些数据构建的解决方案能给你创造多大的商业价值。举例来说,电商网站可以通过微博数据进行社交推荐,也可以根据用户正在谈论的关键热词进行针对性的商品需求趋势预测并作针对性的营销。这些用法都很好,都能看到商业价值,可是,最关键的问题在于,如果你知道花五百万搭建整个大数据团队和平台,一年后只能为你的生意带来四百万的增长,你还愿意干这件事情吗?

这里面牵涉到一个很关键的因素:大数据的价值密度问题。要知道,存储和计算PB级的数据是需要非常高的成本的,大数据虽然看起来很美,但是价值密度却远远低于传统关系型数据库中已经有的那些数据。有一句话笔者很认同:“如果用石油行业来类比大数据分析,那么在互联网金融领域甚至整个互联网行业中,最重要的并不是如何炼油(分析数据),而是如何获得优质原油(优质元数据)”。以股市为例,真正有价值的数据都只会在很小范围内(例如庄家之间)传播,极少可能会流落到互联网上来,所以你如果想去只靠分析微博上网民对股票涨跌的评论来做行情预测的话,真的是要小心了。

阿里之所以牛气,就因为他掌握了全国上亿网民实名制的历史交易记录,这会成为将来阿里金融帝国最重要的资产。而像“挖财”这样的理财软件,则选择了围魏救赵的策略,用“免费”的噱头积累大量用户的理财数据,以便他日能转换成商业价值。而像雪球,知乎这样的高质量UGC社区,最大的资本也就是在于这些高价值密度的内容所拥有的巨大可能性。当年友盟被高价收购的时候,他们最大的资产也就是来自于他们所掌握的移动互联网领域的高价值数据。笔者愚见,当大家为各种层出不穷的大数据新技术而热血沸腾的同时,一定不要忘记了兄弟们用大数据的初衷,只是为了挖掘更大的商业价值而已。

回到刚刚提到的阿里巴巴金融数据,微博上的大数据怎么被更高效利用的问题,阿里和微博正在做的就是所谓Big-Data-As-a-Service的服务,所以你不需要自建一个专门用来存放淘宝和新浪微博海量数据的平台,产生不必要的成本浪费,而只需要根据自己的需求,直接通过阿里和微博提供的大数据服务的付费和免费接口,去对那些真正能对你产生价值的淘宝、微博数据进行分析,按需付费,实现双赢,甚至多赢。也许到那一天,我们才能真正在大数据的成本和收益之间取得一个很好的平衡,以创造更多的社会价值。

简而言之,玩大数据的时候,请一定要考虑清楚你所面对的数据的价值密度有多高,归根结底,商业的本质只是希望通过大数据挖掘更多的商业价值,仅此而已。

Impala:新一代开源大数据分析引擎

原文发表在《程序员》杂志2013年第8期,略有删改。

/ 耿益锋 陈冠诚

 大数据处理是云计算中非常重要的问题,自Google公司提出MapReduce分布式处理框架以来,以Hadoop为代表的开源软件受到越来越多公司的重视和青睐。以Hadoop为基础,之后的HBase,Hive,Pig等系统如雨后春笋般的加入了Hadoop的生态系统中。今天我们就来谈谈Hadoop系统中的一个新成员 – Impala。

Impala架构分析

Impala是Cloudera公司主导开发的新型查询系统,它提供SQL语义,能够查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义,但是由于Hive底层执行使用的是MapReduce引擎,仍然是一个批处理过程,难以满足查询的交互性;相比之下,Impala的最大特点也是最大卖点就是它的快速。那么Impala如何实现大数据的快速查询呢?在回答这个问题之前,我们需要先介绍Google的Dremel系统[1],因为Impala最开始就是参照Dremel系统进行设计的。

 Dremel是Google的交互式数据分析系统,它构建于Google的GFS(Google File System)等系统之上,支撑了Google的数据分析服务BigQuery等诸多服务。Dremel的技术亮点主要有两个:一个是实现了嵌套型数据的列存储;二是使用了多层查询树,使得任务可以在数千个节点上的并行执行和聚合结果。列存储在关系型数据库中并不陌生,它可以减少查询时处理的数据量,有效的提升查询效率。Dremel的列存储的不同之处在于它针对的并不是传统的关系数据,而是针对嵌套结构的数据。Dremel可以将一条条的嵌套结构的记录转换成列存储形式,查询时根据查询条件读取需要的列,然后进行条件过滤,输出时再将列组装成嵌套结构的记录输出,记录的正向和反向转换都通过高效的状态机实现。另一方面,Dremel的多层查询树则借鉴了分布式搜索引擎的设计,查询树的根节点负责接收查询,并将查询分发到下一层节点,底层节点负责具体的数据读取和查询执行,然后将结果返回上层节点。关于Dremel技术实现上的更多信息,读者可以参阅[9]。

 Impala其实就是Hadoop的Dremel,Impala使用的列存储格式是Parquet。Parquet实现了Dremel中的列存储,未来还将支持Hive并添加字典编码,游程编码等功能。Impala的系统架构如图一所示。Impala使用了Hive 的SQL接口(包括SELECT,INSERT,Join等操作),但目前只实现了Hive的SQL语义的子集(例如尚未对UDF提供支持),表的元数据信息存储在Hive的Metastore中。StateStore是Impala的一个子服务,用来监控集群中各个节点的健康状况,提供节点注册,错误检测等功能。Impala在每个节点运行了一个后台服务impalad,impalad用来响应外部请求,并完成实际的查询处理。Impalad主要包含Query Planner,Query Coordinator和Query Exec Engine三个模块。QueryPalnner接收来自SQL APP和 ODBC的查询,然后将查询转换为许多子查询,Query Coordinator将这些子查询分发到各个节点上,由各个节点上的Query Exec Engine负责子查询的执行,最后返回子查询的结果,这些中间结果经过聚集之后最终返回给用户。

 图1

图1. Impala的系统架构图 [2]

在Cloudera的测试中,Impala的查询效率相比Hive,有数量级的提升。从技术角度上来看,Impala之所以能有好的性能,主要有如下几方面的原因:

 1) Impala不需要把中间结果写入磁盘,省掉了大量的I/O开销。

2) 省掉了MapReduce作业启动的开销。MapReduce启动task的速度是很慢的(默认每个心跳间隔是3秒钟),Impala直接通过相应的服务进程来进行作业调度,速度快了很多。

3) Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式,而是像Dremel一样借鉴了MPP并行数据库的思想,从新另起炉灶,因此可以做更多的查询优化,从而能省掉不必要的shuffle,sort等开销;

4) 通过使用LLVM来统一编译运行时代码,避免了为支持通用编译而带来的不必要开销;

5) 用C++实现,做了很多有针对性的硬件优化,例如使用SSE指令;

6) 使用了支持Data locality的I/O调度机制,尽可能的将数据和计算分配在同一台机器上进行,减少了网络开销;

虽然Impala是参照Dremel来实现,但是Impala也有一些自己的特色,例如Impala不仅仅支持Parquet格式,同时也可以直接处理文本,SequenceFile等Hadoop中常用的文件格式。另外一个更关键的地方在于,Impala是开源的,再加上Cloudera在Hadoop领域的领导地位,其生态圈有很大可能会在将来快速成长。可以预见在不久的未来,Impala很可能像之前的Hadoop和Hive一样在大数据处理领域大展拳脚。Cloudera自己也说期待未来Impala能完全取代Hive。当然,用户从Hive上迁移到Impala上来是需要时间的,而且Impala也只是刚刚发布1.0版,虽然号称已经可以稳定的在生产环境上运行,但相信仍然有很多可改进的空间[7]。需要说明的是,Impala并不是用来取代已有的MapReduce系统,而是作为MapReduce的一个强力补充,总的来说Impala适合用来处理输出数据适中或比较小的查询,而对于大数据量的批处理任务,MapReduce依然是更好的选择。另外一个花边消息是,Cloudera里负责Impala的架构师Marcel Komacker就曾在Google负责过F1系统的查询引擎开发,可见Google确实为大数据的流行出钱出力J

Impala与Shark,Drill等的比较

开源组织Apache也发起了名为Drill的项目来实现Hadoop上的Dremel,目前该项目正在开发当中,相关的文档和代码还不多,可以说暂时还未对Impala构成足够的威胁[10]。从Quora上的问答来看,Cloudera有7-8名工程师全职在Impala项目上,而相比之下Drill目前的动作稍显迟钝。具体来说,截止到2012年10月底,Drill的代码库里实现了query parser, plan parser,及能对JSON格式的数据进行扫描的plan evaluator;而Impala同期已经有了一个比较完毕的分布式query execution引擎,并对HDFS和HBase上的数据读入,错误检测,INSERT的数据修改,LLVM动态翻译等都提供了支持。当然,Drill作为Apache的项目,从一开始就避免了某个vendor的一家独大,而且对所有Hadoop流行的发行版都会做相应的支持,不像Impala只支持Cloudera自己的发行版CDH。从长远来看,谁会占据上风还真不一定[10]。

除此之外,加州伯克利大学AMPLab也开发了名为Shark的大数据分析系统。在今天6月份的《程序员》上有一篇专门分析与Shark相关的Spark系统的文章,感兴趣的读者朋友可以参考。从长远目标来看,Shark想成为一个既支持大数据SQL查询,又能支持高级数据分析任务的一体化数据处理系统。从技术实现的角度上来看,Shark基于Scala语言的算子推导实现了良好的容错机制,因此对失败了的长任务和短任务都能从上一个“快照点”进行快速恢复。相比之下,Impala由于缺失足够强大的容错机制,其上运行的任务一旦失败就必须“从头来过”,这样的设计必然会在性能上有所缺失。而且Shark是把内存当作第一类的存储介质来做的系统设计,所以在处理速度上也会有一些优势[11]。实际上,AMPLab最近对Hive,Impala,Shark及Amazon采用的商业MPP数据库Redshift进行了一次对比试验,在Scan Query,Aggregation Query和Join Query三种类型的任务中对它们进行了比较。图2就是AMPLab报告中Aggregation Query的性能对比。在图中我们可以看到,商业版本的Redshift的性能是最好的, Impala和Shark则各有胜负,且两者都比Hive的性能高出了一大截。更多相关的实验结果读者朋友可以参考[12]。

图2

图2. Redshift,Impala,Shark与Hive的Aggregation Query性能对比 [12]

以笔者愚见,其实对大数据分析的项目来说,技术往往不是最关键的。例如Hadoop中的MapReduce和HDFS都是源于Google,原创性较少。事实上,开源项目的生态圈,社区,发展速度等,往往在很大程度上会影响Impala和Shark等开源大数据分析系统的发展。就像Cloudera一开始就决定会把Impala开源,以期望利用开源社区的力量来推广这个产品;Shark也是一开始就开源了出来,更不用说Apache的Drill更是如此。说到底还是谁的生态系统更强的问题。技术上一时的领先并不足以保证项目的最终成功。虽然最后那一款产品会成为事实上的标准还很难说,但是,我们唯一可以确定并坚信的一点是,大数据分析将随着新技术的不断推陈出新而不断普及开来,这对用户永远都是一件幸事。举个例子,如果读者注意过下一代Hadoop(YARN)的发展的话就会发现,其实YARN已经支持MapReduce之外的计算范式(例如Shark,Impala等),因此将来Hadoop将可能作为一个兼容并包的大平台存在,在其上提供各种各样的数据处理技术,有应对秒量级查询的,有应对大数据批处理的,各种功能应有尽有,满足用户各方面的需求。

未来展望

其实除了Impala,Shark,Drill这样的开源方案外,像Oracle,EMC等传统厂商也没在坐以待毙等着自己的市场被开源软件侵吞。像EMC就推出了HAWQ系统,并号称其性能比之Impala快上十几倍,而前面提到的Amazon的Redshift也提供了比Impala更好的性能。虽然说开源软件因为其强大的成本优势而拥有极其强大的力量,但是传统数据库厂商仍会尝试推出性能、稳定性、维护服务等指标上更加强大的产品与之进行差异化竞争,并同时参与开源社区、借力开源软件来丰富自己的产品线、提升自己的竞争力,并通过更多的高附加值服务来满足某些消费者需求。毕竟,这些厂商往往已在并行数据库等传统领域积累了大量的技术和经验,这些底蕴还是非常深厚的。甚至现在还有像NuoDB(一个创业公司)这样号称即支持ACID,又有Scalability的NewSQL系统出来。总的来看,未来的大数据分析技术将会变得越来越成熟、越来越便宜、越来越易用;相应的,用户将会更容易更方便地从自己的大数据中挖掘出有价值的商业信息。

参考资料

[1]http://research.google.com/pubs/pub36632.html

[2]http://blog.cloudera.com/blog/2012/10/cloudera-impala-real-time-queries-in-apache-hadoop-for-real/

[3]http://www.slideshare.net/cloudera/data-science-on-hadoop

[4] Impala重点问题列表:http://yuntai.1kapp.com/?p=1089

[5] Hive原理与不足:http://www.ccplat.com/?p=1035

[6] Impala/Hive现状分析与前景展望:http://yanbohappy.sinaapp.com/?p=220

[7] What’s next for Cloudera Impala: http://blog.cloudera.com/blog/2012/12/whats-next-for-cloudera-impala/

[8] MapReduce:一个巨大的倒退:http://t.cn/zQLFnWs

[9] Google Dremel 原理 — 如何能3秒分析1PB:http://www.yankay.com/google-dremel-rationale/

[10] Isn’t Cloudera Impala doing the same job as Apache Drill incubator project? http://www.quora.com/Cloudera-Impala/Isnt-Cloudera-Impala-doing-the-same-job-as-Apache-Drill-incubator-project

[11] Shark:https://github.com/amplab/shark/wiki

[12] Big Data Benchmark: https://amplab.cs.berkeley.edu/benchmark/

[13] Impala wiki:http://dirlt.com/impala.html

[14]How does Impala compare to Shark: http://www.quora.com/Apache-Hadoop/How-does-Impala-compare-to-Shark

[15] EMC讲解Hawq SQL性能:左手Hive右手Impala: http://stor-age.zdnet.com.cn/stor-age/2013/0308/2147607.shtml

作者简介

耿益锋,清华大学计算机系博士研究生,主要研究方向包括大数据处理和云计算中新应用和新场景下分布式系统的设计和优化。

陈冠诚,IBM中国研究院研究员,主要技术方向为大规模分布式系统中的软硬件协同设计。个人博客为并行实验室(www.parallellabs.com),新浪微博@冠诚

Impala与Stinger对比

Tez和Impala现在竞争非常激烈,前者走的是基于DAG的精细化管理,后者是基于MPP的技术架构重头开始造了一个C++版本的SQL引擎。截止到2013年7月,Hortonworks的Stinger(Hive 0.11 + Tez)还是比Impala慢不少,毕竟Impala的动作更早一些。Hortonworks跟Cloudera这场硬仗干的真是激烈啊。

与大家分享三个演讲(墙外),一个是Impala与Stinger的对比,一个是Stinger的核心-Tez的介绍,一个是Impala跟微策略合作的情况。