虚拟座谈会:大数据一栈式方案Spark

标签: 虚拟 大数据 spark | 发表时间:2014-04-16 17:21 | 作者:u014539179
出处:http://blog.csdn.net

Spark正在占据越来越多的大数据新闻的重要位置,除了性能优异,Spark到底具备了那些特性,让学术界和工业界对其充满了兴趣?同时,Spark还处在快速发展的阶段,开发者和用户不得不解决不稳定和bug,Scala语言也有较高的学习门槛,这些也会成为Spark普及的障碍。当然,尽管Spark提供了一栈式的大数据方案,但并不意味着他适合任何场景。本期虚拟座谈会将讨论Spark的优势和不足,分享在国内领先的Spark开发者遇到的挑战和瓶颈。本期虚拟座谈会邀请了如下嘉宾:

夏俊鸾( @Andrew-Xia),英特尔大数据部门构架师 。开源软件爱好者,11年加入英特尔亚太研发有限公司,8年软件开发管理经验,曾在Palm Source, Trend Micro公司参与Linux内核和安全的开发工作。目前专注于大数据领域,是国内最早一批关注Spark大数据处理框架的开发者,现为Apache Spark project的Initial Committer, 另外也关注和参与Hadoop,Mesos,Yarn等大数据处理和调度框架的开发。

明风( @明风Andy),淘宝技术部数据挖掘与计算团队负责人,带领团队构建了国内第一个100台规模的Spark on Yarn集群,并基于Spark进行大量机器学习,实时计算和图计算的先行尝试,并将实践成果快速应用于淘宝网数据相关的业务和产品。

王健宗( @BigData大数据),网易公司大数据高级研究员,负责网易游戏大数据框架的研究和部署工作,国内最早一批Spark研究者,在其推广下成功将Spark稳定应用在生产环境中。

尹绪森( @尹绪森),Intel工程师,熟悉并热爱机器学习相关内容,对自然语言处理、推荐系统等有所涉猎。


进入亚马逊,谷歌,微软等美国IT企业工作,百度搜索(MUMCS)


孙元浩( @孙元浩pixelray),星环科技CTO,专注大数据、实时数据处理、Hadoop和HBase的技术研发和应用研究。

以下是本期嘉宾的观点:

InfoQ:Spark似乎一夜间成为了Hadoop的颠覆者,Spark不仅性能更好,而且与Hadoop生态圈很好的兼容。在你看来,Spark的优势是什么?哪些场景适合Spark?

尹绪森:说是颠覆者,倒不如说是继承者。在技术上,Spark最大的优势莫过于RDD这个抽象数据结构。RDD带来很多限制,但也给出了更多优势。有了RDD,Spark在某种程度上就变成了分布函数式编程语言。除此之外,在技术之外我觉得最大的优势在于兼容性,保持兼容性给Spark及Hadoop生态圈都带来更大的生机与活力。

马铁(http://people.csail.mit.edu/matei/)博士在毕业论文中给出了详细的适合Spark的场景。Spark适合的场景其实就是RDD适合的场景,RDD是数据并行,适宜大规模数据并行,不适合细粒度事务性数据处理。

孙元浩:Spark是MapReduce的Scala实现。技术优势主要是高性能,这背后有两个原因:为执行计划建立DAG进行延迟计算,采用线程模型进行任务调度。这两个因素对性能的贡献是最大的,也由于性能快,Spark适合做交互式数据探索和需要反复迭代的机器学习算法。

夏俊鸾:从Spark本身来说,我想其优点主要有如下三个方面:

RDD概念的提出使得数据基于内存的共享成为了可能,可以使得用户有更多的手段来控制数据。 2.DAG的调度模式使得用户能够非常清晰地写出非常复杂的业务逻辑。

流水线式的函数编程模式非常适用于来写大数据并行处理程序,代码量相比Hadoop而言只是后者的1/5到1/2。

如果从Spark生态来看的话,那么优势就更加明显了,可以在一套软件栈的构架内,处理batch、Ad-hoc、Streaming、Graph等各种类型的业务。从其应用场景来说,除了公认的机器学习等领域外,由于其功能的多样性,极容易打造端到端的整体解决方案,包括流式数据,在线学习处理,即时查询等。

明风:Spark其实不是颠覆者,是集大成者。它和Hadoop都是相同的MapReduce模式,而非创新的并行计算模式。它的DAG借鉴了微软Dryad的模式,Shark借鉴了Hive,Streaming借鉴了Storm,Graphx借鉴了GraphLab。除了内存计算的RDD,其它扩展,都可以找到前辈。但是它的优势在于:

全面性很好,综合能力强,而且性能优良,不会比其它第一位的差太多。

善于接力,直接运行在Yarn模式和读取HDFS,支持AWS,这些都是让它有合作者,而非竞争者。

函数式编程和多次迭代的特性,它对于复杂机器学习算法的适应度也很高。

所以其实你在每一个场景,都可以找到比Spark更好的NO.1,但是综合起来看的话,你很难有更好的选择了。

InfoQ:与成熟的Hadoop生态圈相比,Spark还处在成熟完善的路上,这对公司的技术积累和研发能力提出了更高的要求。企业如果要选型Spark技术,你有哪些建议?

孙元浩:我们作为推出Spark商业版本土公司,建议企业选用经过验证的稳定版本,同时不推荐用户采用Scala编程,因为研发成本很高。我们在产品中内置Spark,对外提供跟Oracle兼容的PL/SQL和R两种语言,用户的应用迁移变得很简单,可以使用熟悉的语言开发应用,但性能有数量级上的提升。

明风:我认为需要满足以下三点:

高素质的运营团队,如果是Spark on Yarn,需要有一个高效的Hadoop支撑团队。Spark有多种集群运行模式,目前比较推荐公司使用Standalone和Yarn两种模式,但是无论哪种模式,到了一定规模,一个高素质的运营团队是必不可少的(人数不是关键)。而对于Yarn模式来说,一个有经验的Hadoop团队是非常必要的。阿里由于有云梯Hadoop团队,在Yarn的支持和运维上,是有很强的专业度的。所以我们在上Spark on Yarn的时候,基本上是很快的解决了各种小问题,成功的架设了100台的集群。


进入亚马逊,谷歌,微软等美国IT企业工作,百度搜索(MUMCS)


培养或者招聘对折腾语言有兴趣的极客型(Scala)开发人员,快速解决公司在Spark遇到的问题。Spark的开发语言是Scala,它基于JVM构建,但是生产力确是非常高的一门语言。当然这是双刃剑,这也注定了它的学习成本较高,难以直接招聘到大量合适人员。愿意去折腾Scala(包括Closure)的工程师一般都是对Java有比较深的感情和经验,又不愿意转向C++或者Erlang,从而寻找JVM系的高效开发人员。这种人虽然不好找,但是刨除那些纯粹追求奇技淫巧的虚荣者外,剩下的大部分都是有一定极客基因的人才。所以内部培养也不是很难,找到这种taste的人加以引导即可。作为一家公司,如果希望在Spark上投入并依靠,必须能够快速解决使用Spark中发现的异常,而不是坐等社区或者外部公司的帮助,虽然这也是必不可少的。但是Spark作为新生的事务,很多细节还是需要打磨,很多的小Bug,如果解决不了就迈不过去,所以必须拥有自己的研发力量。

为Spark社区贡献有质量的PR,成为Committer,增加话语权。只贡献小Bug的PR意义是有限的,高质量的PR成为Committer后,增加话语权,引领社区望正确和有前途的方向发展,这个是非常关键的。

尹绪森:如果没有这方面的积累,也不打算发展自己的技术团队,那么求助于Cloudera等发行商是个不错的选择,他们已经开始逐渐支持Spark。如果是技术类的初创公司,建议与社区加强联系,相互合作,一起发展。对于技术类大公司,我想应该没什么问题,可以成立专门的team来做,或者现有的Hadoop维护团队直接转过来,也很简单。

InfoQ:你期望Spark增加和改进哪些方面?如更强大的MLlib,更细粒度的读/写,对Python生态圈更好的支持等。

尹绪森:我自己天天混迹于MLlib,当然期待更强大的MLlib。我个人对MLlib期待颇高,而且我觉得MLlib有能力达到一个很好的水准,也有很多好玩的改进。不过我觉得还是要自己想清楚,因为Spark也不是万能的,总有不适应的场景。另外,如果把Spark比作编程语言,那么我觉得在其“编译器”层面也可以有很大的可发挥之处,我们团队也在持续关注这些点,目前有一些想法,还在完善。

明风:Spark在诞生之初,可能没有想过它对机器学习社区能够有大的影响。但是从前几天稀疏矩阵的一个PR讨论来看,已经有很多机器学习算法的大牛关注和使用Spark了,投入或者协助MLLib的发展。我对Spark的增强和改进期望点是:增强型的复杂算法开发和调试功能。惰性、分布式、异步、多迭代这几个特征下,机器学习算法的开发人员目前能够用的调试界面还是非常有限的。之前连城贡献了一个Debugger,现在还没正式发布,相信能够对解决这个问题有一定的帮助,但还远远不够。Spark想要做大数据时代的iPhone,目前从功能的覆盖度来看是够了,基本是一栈式的。从ETL、实时计算和图计算,功能齐全了。但是从易用性和用户体验来说,离iPhone有很大的距离,这是Spark最需要解决的。如果这些解决了,就能够吸引越来越多的机器学习算法大牛加入到Spark的阵营中来,形成更大的力量。

孙元浩:我们公司在持续增强Spark,主要在PL/SQL和R语言方面。我们选择PL/SQL实现控制流和存储过程,主要是为了与Oracle兼容。我们不是很赞同MLlib的做法,我们希望给用户提供一致的R语言体验,这样可以结合使用R语言中现有的上千种算法,我们同时在重新改写常用的机器学习算法,将它们并行化。

InfoQ:GraphX向图并行计算迈出了一步,但它不能很好的解决细粒度和异步更新。你是如何优化GraphX,使其更好的提升机器学习的效果?

明风:目前,Graphx我们还处于使用阶段,对于细粒度和异步更新,我们暂时没有优化计划。但是在这个milestone的开发结束后,我们会给社区提出合适的建议,使得Graphx能够有更好的效果。

尹绪森:我并没有实际操作过GraphX,但据我所知GraphX相比于GraphLab有自己的强项。例如ETL和迭代式的图计算一体化,全局的数据信息,以及易编程性等都是GraphLab比不了的。

孙元浩:我们没有使用GraphX,而是自己开发了图并行算法库。GraphX只适合解决少量可以转变成MapReduce的算法,我们的客户需要解决的问题无法用MapReduce解决。

InfoQ:Spark的发展和硬件发展上有什么联系吗?

王健宗:硬件的发展目前的主要趋势是逐渐来迎合软件的发展,比如Google、百度都依据自己的需求来设计硬件,Spark目前的一个重要发展方向是提出适合自己、能提高自己性能的硬件架构,这样可以很好的随大势,实现分析型硬件,软件定义的硬件的趋势发展。

尹绪森:其实Spark有个很有意思的论断,除了Spark自身消耗的内存外,只给它一个L3 cache,也能完成工作。就目前而言没有看到Spark发展和硬件发展的关系,只是感觉Spark跑的更快,用的机器更少,Intel的服务器可能卖的少了 (开玩笑的)。在executor的执行阶段,如果能有SIMD的支持(如GPU), Spark可以做的更快。不过需求决定生产力,当前可能业界需求不大,而且这个点子也不好发论文,所以学术界的动力也不大。对于应用来讲,除了Deep Learning也没想到更好的使用SIMD的场景。如果想做Deep Learning on Spark的话,估计还需要更多深刻的思考和艰苦的工作。

孙元浩:Spark的发展跟硬件没有什么关系,但是大内存服务器的普及为Spark的广泛应用奠定了基础。未来NVRAM技术和高速互联技术的发展会对计算框架带来更大的革新。

明风:Spark的发展和两个硬件有很大的关系:一是内存,二是SSD。Spark的最大卖点之一就是内存计算,它对内存的消耗和依赖是很大的。所以集群机器的内存越大,它的性能就越好。得益于内存白菜价,现在公司采购192G内存的机器不是什么难事,而且以后肯定T级别内存的服务器会普及。所以Spark敢赌内存计算,也是看好这一点。另外是SSD,虽然内存计算很快,但是不代表没有落地的时刻,如果集群基于SSD硬盘,性能肯定会有提升。目前公司已经有另外一个集群是基于SSD的了,以后有时间的话,我们会考虑跑一跑性能测试的。

InfoQ:在你Spark实践中,遇到了哪些砍或坑?


进入亚马逊,谷歌,微软等美国IT企业工作,百度搜索(MUMCS)


明风:我们是从Spark 0.4就开始尝试了,当时Spark还很不成熟,我们遇到的第一个大坑就是Mesos,这个留下了严重的心理阴影。搭建和调试的难度很高,很多地方也是黑洞。后来直到0.6版,Spark自己也有点受不了,出了Standalone模式,这个时候才好起来了。

Spark实践中,最难的还是对RDD的使用把握。RDD的计算是懒性的,需要有action才会触发。所以按照传统的方法,通过print日志来调试的话,你很难保证打印的每个点都是恰到好处的action触发点,需要反复调整,才能够保证日志和执行的过程对上钩,这点到现在还是让我们有点头大。

为了提高RDD的复用,又有cache(persist)和unpersist,以及checkpoint这几种对RDD进行物理操作的方法。这几个方法对于机器学习算法开发人员,尤其是数学系出身,而非计算机系出身的同学来说,把控难度很高(虽然比起MPI已经简单一些了)。

王健宗:主要的坑是Spark在权限控制方面没有Hadoop强大,对于权限控制要求很高的用户可能需要注意,此外Spark的语言是Scala,可能用Java不太合适,或者说性能不会很好,所以对于学习Scala也是有一些需要注意的。

孙元浩:开源版本的Spark主要问题是稳定性,我们经常听到国内外客户对Spark不稳定,经常需要重启的抱怨,有时候性能也不稳定,偶尔会比Hive更差,主要是因为GC问题导致,特别是当数据量达到TB级别时。我碰到的几个VC都跟我说Spark在美国的用户体验问题,当然有些可能是美国Hadoop厂商的宣传。这些问题是存在的,需要对Spark的内部架构做出重要调整,我们已经解决这些问题并且在生产环境7x24小时运行,请大家相信Spark是可以做得很稳定的。

尹绪森:有很多啊。学习Scala就是一道坎,但是跨过后受益匪浅。不熟悉Spark运行模式和一些隐藏属性也是一道坎,不跨过就写不了高效的Spark应用。还有一些小坑,比如哪天你checkout了最新的Spark的主线,写完自己的程序发现通不过测试,或者编译有问题,可能你需要再checkout更新的版本,或者使用稳定版。还有就是开发Scala程序对硬件设施的要求较高,大内存,SSD基本上必备,否则很痛苦。国内网络环境经常不稳定,也是一个问题。

InfoQ:Spark生态圈内有很多前瞻的研究性项目,比如说BlinkDB、MLBase等。你对哪个项目比较感兴趣呢?

明风:我比较感兴趣的项目有三个:Streaming、MLBase、Graphx。其实大数据时代,如果要利用好数据,对数据计算的要求已经变得又快又复杂。流式计算、机器学习、图计算三个范畴都是非常关键的,你也可以认为图计算是机器学习的一部分,当然独立性很强,所以单独提出来了。对于Spark底层优化的一些东西,其实我个人是非常有兴趣去研究的,但是由于目前工作职位的原因,我会把重心放到上层多一些,而且由于Spark的牛人已经很多了,我相信他们会把这些事情做好的。我可以更加关注在,如何用Spark这把瑞士军刀,去发掘淘宝数据中更大和更多的价值。

王健宗:BlinkDB和MLBase我都比较看好,因为AMP Lab的一些孵化项目都是非常优秀的,大家可以充分关注一下,更多的孵化项目可以关注:https://amplab.cs.berkeley.edu/projects/。


进入亚马逊,谷歌,微软等美国IT企业工作,百度搜索(MUMCS)


孙元浩:我对BlinkDB比较感兴趣,很多情况下用户需要迅速做出决策,特别是数据量在数百TB,为得到完整结果需要等待很长时间时。不过目前的BlinkDB还不能达到这个目的,因为构造采样的时间过长。

尹绪森:就我个人所言,我觉得BlinkDB和MLBase都属于“next generation platform”,这两者也都非常有意思。一个是用采样的方法做大数据统计的“时间消耗”和“准确性”上的权衡,另一个是做机器学习领域的“4GL”。我去年也想更多的涉猎这两个项目,后来觉得还是先把MLlib打造的更完美吧。个人觉得BlinkDB非常适合工业界,并且很快就会有很好的发展。同时非常倾慕MLBase的思路,虽然现在还不太成熟,但是一种非常好的导向,对学术界的价值很大。

作者:u014539179 发表于2014-4-16 17:21:55 原文链接
阅读:58 评论:0 查看评论

相关 [虚拟 大数据 spark] 推荐:

虚拟座谈会:大数据一栈式方案Spark

- - CSDN博客架构设计推荐文章
Spark正在占据越来越多的大数据新闻的重要位置,除了性能优异,Spark到底具备了那些特性,让学术界和工业界对其充满了兴趣. 同时,Spark还处在快速发展的阶段,开发者和用户不得不解决不稳定和bug,Scala语言也有较高的学习门槛,这些也会成为Spark普及的障碍. 当然,尽管Spark提供了一栈式的大数据方案,但并不意味着他适合任何场景.

颠覆大数据分析之Spark弹性分布式数据集

- - 并发编程网 - ifeve.com
颠覆大数据分析之Spark弹性数据集. 译者:黄经业     购书. Spark中迭代式机器学习算法的数据流可以通过图2.3来进行理解. 将它和图2.1中Hadoop MR的迭代式机器学习的数据流比较一下. MR中每次迭代都会涉及HDFS的读写,而在Spark中则要简单得多. 它仅需从HDFS到Spark中的分布式共享对象空间的一次读入——从HDFS文件中创建RDD.

Spark算子:RDD键值转换操作(4)–cogroup、join – lxw的大数据田地

- -
关键字:Spark算子、Spark RDD键值转换、cogroup、join. cogroup相当于SQL中的全外关联full outer join,返回左右RDD中的记录,关联不上的为空. 参数numPartitions用于指定结果的分区数. 参数partitioner用于指定分区函数. ##参数为3个RDD示例略,同上.

[原]基于Spark的大数据精准营销中搜狗搜索引擎的用户画像挖掘

- - Soul Joy Hub
转载请注明:转载 from. from CCF举办的“大数据精准营销中搜狗用户画像挖掘”竞赛. “用户画像”是近几年诞生的名词. 很多营销项目或很多广告主,在打算投放广告前,都要求媒体提供其用户画像. 在以前,大多媒体会针对自身用户做一个分类,但是有了大数据后,企业及消费者行为带来一系列改变与重塑,通过用户画像可以更加拟人化的描述用户特点.

Spark概览

- - 简单文本
Spark具有先进的DAG执行引擎,支持cyclic data flow和内存计算. 因此,它的运行速度,在内存中是Hadoop MapReduce的100倍,在磁盘中是10倍. 这样的性能指标,真的让人心动啊. Spark的API更为简单,提供了80个High Level的操作,可以很好地支持并行应用.

Spark与Mapreduce?

- - 崔永键的博客
我本人是类似Hive平台的系统工程师,我对MapReduce的熟悉程度是一般,它是我的底层框架. 我隔壁组在实验Spark,想将一部分计算迁移到Spark上. 年初的时候,看Spark的评价,几乎一致表示,Spark是小数据集上处理复杂迭代的交互系统,并不擅长大数据集,也没有稳定性. 但是最近的风评已经变化,尤其是14年10月他们完成了Peta sort的实验,这标志着Spark越来越接近替代Hadoop MapReduce了.

Spark迷思

- - ITeye博客
目前在媒体上有很大的关于Apache Spark框架的声音,渐渐的它成为了大数据领域的下一个大的东西. 证明这件事的最简单的方式就是看google的趋势图:. 上图展示的过去两年Hadoop和Spark的趋势. Spark在终端用户之间变得越来越受欢迎,而且这些用户经常在网上找Spark相关资料. 这给了Spark起了很大的宣传作用;同时围绕着它的也有误区和思维错误,而且很多人还把这些误区作为银弹,认为它可以解决他们的问题并提供比Hadoop好100倍的性能.

Spark 优化

- - CSDN博客推荐文章
提到Spark与Hadoop的区别,基本最常说的就是Spark采用基于内存的计算方式,尽管这种方式对数据处理的效率很高,但也会往往引发各种各样的问题,Spark中常见的OOM等等. 效率高的特点,注定了Spark对性能的严苛要求,那Spark不同程序的性能会碰到不同的资源瓶颈,比如:CPU,带宽、内存.

Spark&Spark性能调优实战

- - CSDN博客互联网推荐文章
       Spark特别适用于多次操作特定的数据,分mem-only和mem & disk. 其中mem-only:效率高,但占用大量的内存,成本很高;mem & disk:内存用完后,会自动向磁盘迁移,解决了内存不足的问题,却带来了数据的置换的消费. Spark常见的调优工具有nman、Jmeter和Jprofile,以下是Spark调优的一个实例分析:.

Mesos上部署spark

- - 开源小站
还是回到之前一直持续的 Mesos话题. 在之前的环节里,我们已经尝试了Mesos的安装,Marathon守护服务以及相对比较主流的Mesos作为Hadoop的资源管理器的实际操作. 这次就说说同属于伯克利出品的Spark. 其实spark最初0.7以前的版本还没有自己的资源管理系统,资源的调度都是通过Mesos来执行的.