Spark独门秘籍：打造结构一体化、功能多元化的高效数据流水线

2014年4月19日“中国Spark技术峰会”（Spark Summit China 2014）将在北京召开，国内外Apache Spark社区成员和企业用户将首次齐聚北京。AMPLab、Databricks、Intel、淘宝、网易等公司的Spark贡献者及一线开发者将分享他们在生产环境中的Spark项目经验和最佳实践方案。

在Spark技术峰会召开前夕，记者和本次Spark峰会的演讲嘉宾连城做了一次简单的沟通，他就Spark技术优势、Spark技术发展、企业应用Spark遇到的困境等话题分享了自己的看法。

连城  @连城404

Intel物联技术研究院研究员，Spark contributor目前专注于以Apache Spark为主的大数据处理平台，即将加入Databricks。

以下是记者采访原文：

- 什么原因吸引你钻研Spark技术？

最初接触Spark纯粹是出于个人兴趣。我感兴趣的技术方向主要有二，即分布式系统和函数式语言。Spark作为一套用Scala写成的分布式内存计算系统，很好地结合了这两个领域。Spark提供的Scala API本身也很类似于一套分布式、惰性求值的纯函数式语言。然而后来，越是深入探寻，便越是被Spark所吸引。Spark背后的不少想法在先前的系统中或多或少都有所体现，但Matei Zaharia博士众人非常巧妙地集众家之所长，融会贯通，克服了众多旧有特化系统中的各种缺陷，浓缩提炼出了RDD（Resilient Distributed Dataset，弹性分布式数据集）这一高度通用的抽象结构。围绕RDD这一核心，AMPLab团队以扎实的工程功底和开放的心态，打造了全新的Spark生态圈，又以Spark为核心提出了极富创意的BDAS（Berkeley Data Analytics Stack，伯克利数据分析栈）。在研究成果的工业转化方面，AMPLab团队可谓典范：他们不仅是富有远见的科学家，也是功力深厚的工程师，同时还扮演着开源社区中循循善诱的良师益友角色。正是基于以上这些原因，去年得知Spark核心团队创办Databricks后我便力求加盟，并最终幸运地得偿所愿。能与这样一群杰出的同事工作，本身就是一件令人非常兴奋的事。

- 对于解决哪些问题Spark独具优势？

随着大数据相关技术和产业的逐渐成熟，单个组织内往往需要同时进行多种类型的大数据分析作业。如：传统hadoop MapReduce最为擅长的批量计算、各种机器学习算法为代表的迭代型计算、流式计算、社交网络中常用的图计算、SQL关系查询、交互式即席查询等等。在Spark出现之前，要在一个组织内同时完成数种大数据分析任务，就不得不与多套特化系统打交道，一方面引入了不容小觑的运维复杂性，另一方面还免不了要在多个系统间频繁进行代价高昂的数据转储（ETL）。AMPLab在介绍以Spark为核心的BDAS时常说的一句话是：one stack to rule them all，也就是说可以在一套软件栈内完成前述各种大数据分析任务。相对于MapReduce上的批量计算、迭代型计算以及基于Hive的SQL查询，Spark更是可以带来一到两个数量级的效率提升，在传统MapReduce近乎不可能的交互式即席查询也因而得以实现。这种“全能”特质，很大程度上源自RDD这一合理抽象和AMPLab/Databricks团队扎实的工程功底。当然，Spark并不真的是全能的。RDD模型适合的是粗粒度的数据并行计算，而不适合细粒度的、需要异步更新的计算；对于这些计算需求，如果要追求极致的性能，还是需要求助于特化系统（如图计算领域的GraphLab等）。但就现有成果来看，Spark的覆盖面已然相当广泛。简而言之，Spark的独门秘籍便是打造结构上一体化、功能上多元化的高效数据流水线。

- 目前企业应用Spark最大的困难是什么？

据我有限的了解，最大的困难还是人才方面的短缺。无论Spark还是Spark所使用的Scala，都还是相当年轻的事物。虽然它们各自都已经吸引了大批富有远见和才华的开发者，但不得不说距离大规模普及还有相当长的一段路要走。另一个相关问题是Spark方面的参考材料还不多。目前社区内开发者们主要的学习方式还限于阅读有限的官方文档、源码、AMPLab发表的论文，以及社区讨论。所幸Fast Data Processing with Spark一书的中文版已经在翻译中；由O'Reilly出品，来自Spark核心团队的Learning Spark今年也有望面世。

- 根据您的了解，目前Spark发展的情况如何？

评价一个开源项目发展情况的重要指标之一就是该项目的贡献者人数。对于这一点，在去年12月份的Spark Summit上，Spark的创始人Matei Zaharia博士十分自豪：“过去六个月内，Spark的活跃开发者人数超过了Hadoop MapReduce！”那时Spark贡献者总人数是103人；而今四个月过去了，根据GitHub最新的统计，这一数字已然增长到了153人。特别值得一提的是，在最近发布的几个版本中，华人开发者的人数飞速上升。Spark项目主站中Powered by Spark页面中不断增长的公司列表也是Spark在工业界稳步推进的有力证明。这份列表中不乏阿里巴巴、百度、点评、搜狐等中国企业的身影。如前所述，Spark的推广还任重道远，但其良好的向下兼容性、相对传统方法的显著优势，以及来自社区的巨大热情令我非常看好Spark的发展前景。

- 请谈谈你在这次大会上即将分享的话题。

本次大会上，我将为大家介绍新近加入Spark主线版本的alpha组件Catalyst/Spark SQL。在去年的Spark Summit上，Catalyst的主要设计者Michael Armbrust曾将Catalyst描绘为一套简洁强大的SQL查询计划优化框架。随着时间的推移，Catalyst已经逐渐进化为一整套完整的SQL on Spark解决方案并更名为Spark SQL。后续Catalyst/Spark SQL有望成为Shark的新引擎。Catalyst/Spark SQL的特点主要包括： 向下兼容HiveQL，可以操纵现存的各种Hive数据格式。 支持针对原生RDD对象的关系查询；用户既可以选择HiveQL，也可以选择Catalyst提供的精简SQL子集或Scala DSL，从而完全摆脱对Hive的依赖。 在执行效率方面，Catalyst内建的查询优化引擎可以对用户编写的HQL/SQL查询进行有效优化，从而有效减轻用户在Spark应用性能调优方面的负担。 借力于Scala 2.10新近的反射能力，Catalyst实现了一套可扩展的代码生成框架，可以针对特定逻辑直接生成字节码，进一步提升性能。

- 哪些听众最应该了解这些话题，这个话题可以帮助听众解决哪些问题？

所有正在应用Hive、Shark等SQL data warehouse的听众都应该会对这个话题感兴趣。相对于Hive，和Shark一样，Catalyst可以提供一到两个数量级的性能提升，实现真正的交互式大数据即席查询。相对于Shark，Catalyst提供了针对原生RDD对象的关系查询支持，并且在保留Hive兼容性的前提下进一步解耦了对Hive的依赖，精简了代码库；全新的执行计划优化和代码生成框架简洁清爽，为更进一步的性能提升打开了更大的想像空间。

部门领导想让我用 spark sql 做数据处理。。我看是走错路了。。。

spark sql 看来更多是为了支持 即席查询的