虚拟座谈会：大数据一栈式方案 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 本身来说，我想其优点主要有如下三个方面：

1. RDD 概念的提出使得数据基于内存的共享成为了可能，可以使得用户有更多的手段来控制数据。 2.DAG 的调度模式使得用户能够非常清晰地写出非常复杂的业务逻辑。
2. 流水线式的函数编程模式非常适用于来写大数据并行处理程序，代码量相比 Hadoop 而言只是后者的 1/5 到 1/2。

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

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

1. 全面性很好，综合能力强，而且性能优良，不会比其它第一位的差太多。
2. 善于接力，直接运行在 Yarn 模式和读取 HDFS，支持 AWS，这些都是让它有合作者，而非竞争者。
3. 函数式编程和多次迭代的特性，它对于复杂机器学习算法的适应度也很高。

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

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

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

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

1. 高素质的运营团队，如果是 Spark on Yarn，需要有一个高效的 Hadoop 支撑团队。Spark 有多种集群运行模式，目前比较推荐公司使用 Standalone 和 Yarn 两种模式，但是无论哪种模式，到了一定规模，一个高素质的运营团队是必不可少的（人数不是关键）。而对于 Yarn 模式来说，一个有经验的 Hadoop 团队是非常必要的。阿里由于有云梯 Hadoop 团队，在 Yarn 的支持和运维上，是有很强的专业度的。所以我们在上 Spark on Yarn 的时候，基本上是很快的解决了各种小问题，成功的架设了 100 台的集群。
2. 培养或者招聘对折腾语言有兴趣的极客型（Scala）开发人员，快速解决公司在 Spark 遇到的问题。Spark 的开发语言是 Scala，它基于 JVM 构建，但是生产力确是非常高的一门语言。当然这是双刃剑，这也注定了它的学习成本较高，难以直接招聘到大量合适人员。愿意去折腾 Scala（包括 Closure）的工程师一般都是对 Java 有比较深的感情和经验，又不愿意转向 C++ 或者 Erlang，从而寻找 JVM 系的高效开发人员。这种人虽然不好找，但是刨除那些纯粹追求奇技淫巧的虚荣者外，剩下的大部分都是有一定极客基因的人才。所以内部培养也不是很难，找到这种 taste 的人加以引导即可。作为一家公司，如果希望在 Spark 上投入并依靠，必须能够快速解决使用 Spark 中发现的异常，而不是坐等社区或者外部公司的帮助，虽然这也是必不可少的。但是 Spark 作为新生的事务，很多细节还是需要打磨，很多的小 Bug，如果解决不了就迈不过去，所以必须拥有自己的研发力量。
3. 为 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 的思路，虽然现在还不太成熟，但是一种非常好的导向，对学术界的价值很大。