虚拟座谈会：大数据一栈式方案Spark
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工程师，熟悉并热爱机器学习相关内容，对自然语言处理、推荐系统等有所涉猎。
孙元浩（@孙元浩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台的集群。
培养或者招聘对折腾语言有兴趣的极客型（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实践中，遇到了哪些坎儿或坑？
明风：我们是从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/。
孙元浩：我对BlinkDB比较感兴趣，很多情况下用户需要迅速做出决策，特别是数据量在数百TB，为得到完整结果需要等待很长时间时。不过目前的BlinkDB还不能达到这个目的，因为构造采样的时间过长。
尹绪森：就我个人所言，我觉得BlinkDB和MLBase都属于“next generation platform”，这两者也都非常有意思。一个是用采样的方法做大数据统计的“时间消耗”和“准确性”上的权衡，另一个是做机器学习领域的“4GL”。我去年也想更多的涉猎这两个项目，后来觉得还是先把MLlib打造的更完美吧。个人觉得BlinkDB非常适合工业界，并且很快就会有很好的发展。同时非常倾慕MLBase的思路，虽然现在还不太成熟，但是一种非常好的导向，对学术界的价值很大。