拥抱Spark，机遇无限——Spark Summit 2013精彩回顾

2013年12月2日-3日，第一届Spark峰会在美国旧金山举行，来自180个不同机构的近500位技术专家见证了这次盛会。来自Databricks、UC Berkeley AMPLab、Yahoo、Intel、Amazon、Red Hat等20个机构的30个报告精彩纷呈，从Spark的未来，到各种计算范式的实操，到最前沿的科学应用（用Spark做脑神经元的分析研究），再到新创业公司基于Spark的产品发布，让场内和场外的Spark以及大数据爱好者们饱享了一次饕餮盛宴。一个个精彩的应用案例宣告了Spark已经从一个学术研究项目成长了起来，走入了广泛的企业级应用场景。

时光回拨到去年九月， UC Berkeley AMPLab的几个成员从硅谷风投Andreessen Horowitz融资成立了Databricks公司，志在从Apache Spark开始，打造一系列工具和平台，从而更快、更方便地从大数据中挖掘有价值的信息。公司成立不久团队成员便着手组织第一届的Spark峰会，会议的组织和宣传只用了两个多月。

Spark今年的发展势头很猛，当Databricks的团队对外宣布要筹备第一届峰会后，很快大会组织者就收到了包括Intel、 Cloudera和 Amazon等近20个公司的赞助。开源社区的合作者对这个峰会也十分支持，不到两个礼拜我们就收到了几十份技术报告的意向书。

因为是第一次组织和Spark有关的会议，在人数参与上我们内部产生了很大争议。最有信心的组织者预计应该有500人参会，而比较悲观的觉得有100个报名人员就很满足了。刚开始大会议程还没在官网公布时，注册人数还不到20个。这个时候赞助公司的数目都比报名人数高，让我们非常担心。后来大会议程确定之后开始宣传，报名人数直线上升。同事中的乐观派获胜，这让我们对Spark的未来也充满了信心。

回到峰会，内容实在精彩，我们要给没能参加的同学们发福利：这次所有的演讲都被记录了下来，所有的幻灯片以及视频都可以在 官方网站找到。在这里笔者和大家分享一些比较有意思的演讲话题。

 

Databricks CTO Matei Zaharia: Spark的未来的蓝图

Matei Zaharia在Berkeley AMPLab博士生涯的时候设计和编写了第一个版本的Spark。作为Spark的灵魂人物，年纪轻轻的Matei同时也是麻省理工学院的教授以及Databricks公司的CTO。Matei在会上描述了Spark现在强劲的发展势头以及他个人以及Databricks对Spark未来的设想：

• Spark已经有来自全球各地的100个工程师贡献过代码（其中包括很多中国工程师）
• 在过去的六个月，Spark开发活跃程度已经超出了Hadoop本身
• Spark会成为最主流的大数据处理框架。它和其他框架最大的不同是在Shark、MLlib、GraphX以及Spark Streaming的支持下，Spark可以用同一个引擎高效的支持从ETL到SQL到Machine Learning再到流数据处理的应用。

Databricks CEO Ion Stoica：把数据炼成价值

Ion着重讲了三类计算问题，交互式查询（快决策）、流数据查询（基于新鲜数据的决策）和更复杂的运算，分别对应于交互式、流式和批量（包括机器学习、图计算等）三类软件栈，需要三份数据。很自然的，BDAS是一个unified软件栈，只需一份数据。他讲了三个用例展现unification的好处：

1. 实时+批量，融合实时洞察和历史洞察形成全时洞察，采用Spark Streaming + Spark/Shark/BlinkDB；
2. 流处理+机器学习，实时获得更复杂的洞察，采用Spark Streaming+MLlib；
3. 图流水线（图创建/ETL+图计算+后处理），原来是用Hadoop+特殊图引擎，现在可以用Spark+GraphX。

笔者（Reynold）原来还有个例子是即席查询+机器学习，采用Shark+MLlib。简单、融合，这是BDAS遇见未来的独特优势。 

UC Berkeley AMPLab主任Mike Franklin：AMPLab的大数据研究

Mike着重介绍了一些Spark爱好者比较陌生的技术，如基于采样的BlinkDB，基于众包的人机混合计算（解决DB-hard和AI-hard问题），声明式（做什么）而非命令式（怎么做）的机器学习MLBase。还纠结于怎么用MLIib吗？小伙伴们的福音来了，MLBase将在2014年春天开源。另外，Mike透露未来三年还要广邀才俊加入AMPLab，有意申请AMPLab的准博士和博士后们，盯着点哦。

Hortonworks前CEO/CTO Eric Baldeschwieler: Spark和Hadoop

这个世界上恐怕很难找到另外一个人对Hadoop的发展历程比Eric Baldeschwieler更熟悉的了。江湖人称Eric 14（他的姓有14个字母并且难以拼写），他见证了Hadoop的发展：Hadoop最早正是他在Yahoo!的团队开发，后来贡献给了开源社区，然后又在他的带领下成立了Hortonworks。Eric 14的演讲从Hadoop MapReduce的弊端开始涵盖到了Spark如何很好的弥补了这些弊端。他认为Spark在不久的将来会取代Hadoop MapReduce，成为大数据生态圈内编写和分享算法的标准平台（原话是”lingua franca”）。

霍华德·休斯医学研究所研究员Jeremy Freeman：大规模脑计算——操控脑，绘制脑地图

这无疑是整个峰会最吸引眼球的一个演讲。这个研究所很有财，搭了个250个节点的Spark集群，研究大脑的工作机制，特别是神经元及其网路如何将外界刺激映射到反应行为。实验对象是斑马鱼，有两个原因：它有10万个神经元；科研人员培育出了一个斑马鱼的新品种，它的皮肤是透明的，神经元工作时会发光，这样就可以通过精密光学设备去观测每一个神经元的工作状态。

该系统的数据量在神经科学研究中是空前的，每30分钟产生1TB的影像数据，Freeman试图从数据里发现有价值的“结构”和模式。最简单的分析是统计分析，如每个神经元的平均活动指标和标准方差。其次是做回归分析，根据刺激和行为预测神经元的响应。更复杂的需要检视整个数据集的结构，做降维和聚类分析。分析要求低延迟、交互式，而且很多算法（如模型拟合）是反复迭代的，于是Spark是天然之选。Freeman在GitHub开源了一套 神经数据分析的库，其中既包括通用机器学习算法，又有神经科学的特定算法，他认为Thunder是对MLlib/MLBase的很好补充。

科研人员利用Spark做了几个很有趣的科学实验。首先是研究大脑不同区域在处理特定方向移动时的表现（想象下接飞盘时的大脑活动）。Spark在几秒钟之内对6800万条时间序列进行处理，生成大脑对方向响应的高清区域图。有些区域对所有方向都有响应，而另外一些区域整块地只对某些方向响应。

第二个实验是分析鱼跟踪动态物体时身体的响应行为。Spark需要对每个神经元的时间序列进行周期平均，接着采用主成分分析（PCA）把高维时间序列数据降维到二维空间，进一步将其可视化，构造出大脑的颜色图：绿色是最先出现响应的神经元，代表对刺激的立即响应；而蓝色部分接着出现响应，这跟动作的产生（这里是尾巴的摇动）相关；而红色部分在动作产生后响应，应该是跟协调动作的机能相关。

这两个实验显示了如何从整体数据中寻找结构和模式，但无法揭示每一个神经元对鱼的反应动作的贡献。于是，他们开展了第三个实验，用Spark Streaming实时监视神经元的活动，同时用激光来控制和干扰神经元的工作，即在图形界面上选择部分神经元，用激光杀死，反复迭代先前的实验，来观察结果的异同。实验发现部分神经元的失效不仅改变了鱼的行为，也对其他神经元的活动产生了影响。

这个演讲让人眼花缭乱。当像Spark和Spark Streaming这样的生产率工具解开了大数据笨重的桎梏后，一下子也释放了领域专家的创造力。

Sharethrough公司Ryan Weald：Spark Streaming的产品化

Spark Streaming是最近借Spark之势声名鹊起的流计算新贵，它到底离生产环境有多远？Ryan的演讲告诉大家，只要加一点容错的原料，再和上设计模式和几种开源系统作为调料，Spark Streaming就是完美的产品。

Spark Streaming天然能够得心应手地处理Ryan所在的移动广告业务：首先是实时性；其次是它的mini-batch特点，相比连续流容易实现聚合操作；再者，它比纯流计算平台（如Storm）更适合实现多迭代的机器学习。

Spark Streaming要产品化，需要配上一点容错的原料。在它的前端，即数据源的接收者处，需要有自愈能力；在它的执行过程中，需要对作业的持续监控；而在它的后端，需要对结果的持续性进行跟踪。Ryan介绍了两种方法保证前端的接收者容错，分别是要求接收者（如RabbitMQ StreamReceiver）采用Actor机制，以及部署自愈能力的网络连接池。在后端，Ryan考虑了对结果流跟踪的三种选项， 谷歌Mill Wheel的低水位、数据库的updated_at游标，以及基于固定周期内结果文件的平均大小进行预警。由于Spark Streaming天生支持第三种选项，Ryan认为它是简单而有效的选择。

Ryan又介绍了Spark Streaming的最佳设计模式，Map-Aggregate-Store。Map负责对流数据项进行ETL，Aggregate可以从简单的计数到复杂的统计，Store则是持久化数据。Map可以用Spark的map算子实现，Ryan的心得是不要把所有的逻辑写在匿名函数里，而应该把逻辑封装在Scala的object里，这样对测试大有裨益。Ryan着重讲了后两个阶段，并建议Spark Streaming加入相关的API。

Aggregate的最佳实现方式是把具有结合律的聚合操作变成函数编程中的可重用Monoid。Twitter的一个开源项目 Algebird已经实现了很多种Monoid，其中有一个 HyperLogLog Monoid采用了概率数据结构，用近似的方法计算非重复项数目，在较小的误差下达到极高的空间和时间效率。

对于Store而言，最重要的是灵活性。Spark生态系统主要使用HDFS，Ryan认为未来会更多使用NoSQL数据库，因为后者有更好的查询速度。Twitter的又一个开源项目 Storehaus能够灵活地支持不同的持久性机制，从Redis到Dynamo到Cassandra。或者，可以用内存存储做测试，进入生产环境后无缝切换到持久存储。

Ryan还提了一个设想，就是用Twitter的另一个开源项目 Summingbird，来实现统一API下MapReduce和Spark Streaming的灵活切换。由于Summingbird本身支持一个简单的内存计算实现，可以用它来开发调试，而部署时切换到Spark Streaming。他已经着手开始这个工作。

总体而言，这个演讲的信息量很高，实操性强，很值得借鉴。

Yahoo的Spark实践

Yahoo是大数据巨头中对Spark最情有独钟的一家。这次峰会，Yahoo贡献了三个演讲，让我们一一道来。

Andy Feng是从浙大走出来的Yahoo杰出架构师，他的主题演讲试图回答两个问题。

第一个问题，为什么Yahoo爱上Spark？当Yahoo的内容从编辑选择变成数据驱动的、上下文敏感的、个性化的页面时，机器学习、数据科学是盖子下面的引擎。技术团队苦苦寻找一个可以支撑大规模、实时、适合机器学习探索的平台，特别是内容的生命周期短、对突发内容的响应要快，模型需要在一个小时或者更短的时间内重新训练，而训练数据可能来自150PB的巨大黑洞，计算可能发生在35000台服务器上。Yahoo的解决方案是Hadoop+Spark。

这就引出了第二个问题，Hadoop和Spark如何精诚合作？简单来说，前者做批量计算，后者做迭代计算，两者共存于YARN之上，同时共享HDFS、HBase等数据存储。Yahoo的第一个试验项目是用于Yahoo日本的电商。第一个Spark程序是Collaborative Filtering，30行的代码，在10台机器上耗时10分钟，而基于Hadoop的实现需要106分钟。第二个试验项目是流广告，算法是基于Vowpal Wabbit的logistic regression，120行代码，1亿样本、13000个特征，30个迭代，耗时30分钟。最有意思的是这个算法在Spark-on-YARN宣布后2个小时就完成了。

目前Yahoo已经有4个Spark committer，在Spark-on-YARN、Shark、安全、可扩展性和可运营性上做出了可观的贡献。

下一个主题演讲者Tim Tully同样是Yahoo的杰出架构师，他详细讲述了Spark和Shark在Yahoo数据和分析平台里的应用。

1999到2007年间的Yahoo数据处理平台采用NFS保存数据，C++写就的Map/Reduce实现，和Perl脚本做粘合，这个架构的缺点就是要把数据搬到计算所在的地方。逐渐演化到以Hadoop为核心的架构：日志先采集到NFS，进而移到HDFS，用Pig或MapReduce做ETL或massive joins，结果加载到数据仓库，然后用Pig、MapReduce或Hive做聚合和报表生成，报表存入Oracle/MySQL，同时还有一些商业BI工具，和Storm-on-YARN做流处理。这个架构的问题是，太慢。报表的生成延迟长达2-6小时，海量的join耗时更长，交互式查询也几乎不可能。原先的解决方案并不完美，如预先计算、把结果存下来供未来查询，但结果不能反映实时的变化。

Yahoo考虑过Pig on Tez，或者Hive on Tez。这时候，Spark/Shark的出现使之成为Yahoo的圣杯。所以，Hadoop+Spark的架构就应运而生了，基本设计是Hadoop和Spark肩并肩共存于YARN之上，而由于有些SQL负载需要可预测的服务质量，所以又加入了一些专门跑Shark的大内存集群（卫星集群）。在这个架构里，Spark取代Hadoop做ETL，而Shark取代商业BI/OLAP工具，承担报表/仪表盘和交互式/即席查询，同时与桌面BI工具（如Tableau）对接。目前在Yahoo部署的Spark集群有112台节点，9.2TB内存，还在考虑加入SSD。

Tim介绍了未来的工作。首先，Pig/MapReduce将完全让位，由Spark承担所有的ETL任务。其次，虽然卫星集群仍将存在，Shark-on-Spark-on-YARN将在2014年部署。

第三个出场的是Yahoo的工程师Gavin Li，此君介绍了Spark在Audience Expansion中的应用。Audience Expansion是广告中寻找目标用户的一种方法：首先广告者提供一些观看了广告并且购买产品的样本客户，据此进行学习，寻找更多可能转化的用户，对他们定向广告。Yahoo采用的算法是logistic regression，输入数据和中间数据都是TB级，原来的系统采用Hadoop Streaming，2万多行代码，运行时30000+ mappers，2000 reducers，20+作业，耗时16小时。直接移植到Spark需要6个工程师3个季度的工作量。Yahoo的做法是构建一个transition层，自动把Hadoop Streaming作业转化为Spark作业，只需2人季。下一步就是分析性能，进行优化。

开始的Spark版本相比Hadoop Streaming版本的加速只是2倍多，远远低于期望。下面对可扩展性的分析和优化就跟Audience Expansion不相干了，有普遍的借鉴意义。影响可扩展性的主要因素是shuffle，其过程如下：mapper-side把中间结果（非压缩数据）写到文件里，每个文件对应一个reducer的partition；reducer-side把文件读到内存里才能计算，所以reducer所在机器的内存决定了partition的大小；所有的mapper结束后，reducer才开始把全部shuffle文件拉过来，进行计算。

下面仔细分析一下它的问题：由于partition受限内存大小，在数据量较大时，partition的数目、也就是shuffle文件的数目将会很大。在Yahoo的例子中，3TB压缩数据（相当于90TB非压缩）需要46080个partition/shuffle文件。第一个问题在mapper-side，每个mapper需要并发写46080个文件，每个文件要164KB的I/O buffer，如果一个服务器有16个mapper，这需要115GB的内存。解决方案是减小buffer大小到12KB，这样使内存消耗降到10GB。第二个问题是巨大数量的小文件使得磁盘读写效率降低，文件系统元数据的开销也大（光删除这些文件就要花2个小时），怎么解决呢？直接的办法是在reducer-side做内存压缩，这样使得内存“大”了10-100倍，这样partition的有效大小也变大了，shuffle文件的数目可以减少到1600个左右。Yahoo的patch甚至允许reducer在内存不够时spill到磁盘，这就完全解决了可扩展性的问题。

Gavin还描述了个场景，Spark的输入数据来自Hadoop，如果Spark采用与Hadoop同样的hash函数，就可以免去反复partition、极大减少shuffle文件的数量。最后一个问题，考虑到reducer必须等所有mapper结束才能开始拉shuffle文件，为了提高资源利用率，Yahoo增大了maxBytesInFlight来提升网络效率，同时分配相当于物理核数目2倍的线程数来增加核的使用率。

Yahoo的解决方案具有普遍意义，其贡献已经进入Spark的codebase，这也是很多公司开始拥抱Spark的原因，一方面其尚年轻、有贡献的机会，另一方面它又很活跃，迅速成熟。

Adatao CEO Christopher Nguyen：一个全功能企业级大数据分析解决方案

除了Matei的主题演讲，有一个演讲在Youtube上获得了最多的点击率，它来自Adatao。Adatao是Spark社区的早期贡献者之一，这次的演讲不仅描绘了一个建筑在Spark之上数据智能的美好愿景，而且带来了精彩的demo。Christopher从穿越大西洋说起，泰坦尼克悲剧性地在中途沉没；同样的，当横跨大数据之洋时，黄色小象（Hadoop）也只能行一半的路。

紧接着就是干货了。Christopher展示了第一个demo：Adatao的pInsight是个叙述式的BI工具，表现为文字处理工具（基于浏览器）；Adatao的cofounder，Michael在文档中键入类似自然语言的操作语句，其被送往云中（EC2）的pAnalytics后端服务器；pAnalytics运行于Spark之上，做数据处理和挖掘，返回结果后，pInsight对其做可视化，显示于文档中。Michael演示了从data.gov抓下航班数据，可视化到美国地图之上，可以看数据的schema，进行各种聚合、分析和交互式的可视化，非常简单。

除了商业视图，pInsight还提供了数据科学视图。该视图基于一个集成开发环境，交互式开发可以基于R语言，可以很好利用R的可视化（plot）能力。Michael演示了利用航班数据，分析并且预测延误，非常简单。

有趣的是，商业视图也支持数据科学工作，它的交互语言也支持R和Python。

随后Christopher介绍了几个商业案例：互联网服务提供商（ISP）从Hive+Tableau转到Adatao，做交互式、即席查询；客户服务提供商做多渠道（mobile、Web等）销售和产品推荐；重型机械设备生产商对传感器数据分析，做预测性维护，之前MongoDB，不易分析，现转到Spark；移动广告平台做定向广告和转化率预测。

pAnalytics能够在10秒内完成所有的分析。Christopher认为10秒跟10分钟的差距不是60倍，而是天壤之别，因为一旦延迟超过某个阈值，数据科学家会改变行为，他们将失去一些创造力。另外，对于linear modeling，pAnalytics达到了1GB/秒的吞吐量，相当可观。

Christopher感叹Spark社区的强大，能够让Adatao在短期内实现目前的成就，他承诺未来将代码回馈给社区。

Databricks联合创始人Patrick Wendell：理解Spark应用的性能

对于Spark程序员来说，这个演讲是必看的。Patrick从一个简单的例子说明理解Spark工作机制的重要性，使用Group By Key的实现比基于reduceByKey的版本性能慢10-100倍。随着他介绍了RDD、DAG、Stage和Task的概念，尤其是Task内部的工作机制相信对很多Spark工程师都是新的认识。

他演示了Spark 0.9将发布的带有更丰富性能数据的Web UI，用以了解Spark应用的底层细节。最后，他分析了性能的几个常见问题和解决方案：

1. map算子的闭包（Closure）如果自由变量是个大的数据结构，序列化的代价非常高，要采用广播变量；
2. 因为filter类算子导致结果RDD稀疏，可能会生成很多空的task（或执行时间<20ms的task），可以用coalesce或repartition对RDD重新划分；
3. 如果map算子的闭包需要做heavy的初始化和结束工作（如连接MongoDB，算完后关闭连接），这些开销是对每个数据记录都要付出的，可以用mapPartitions或mapWith，仅对每个partition（而不是每个记录）做一次这种工作；
4. 因为partition key不合适导致的数据skew，需要重写程序；
5. 因为straggler导致的worker skew，可以打开spark.speculation开关或手动关掉有问题的节点；
6. Stage之间的shuffle需要写大量数据到文件，这依赖于OS的buffer cache，因此不要让JVM的heap把内存用满，留20%给OS buffer cache；
7. 本地shuffle文件不要写到/tmp，用spark.local.dir配置多个硬盘保证高吞吐量；
8. 控制reducer的数量，过多的话任务启动开销大，过少的话并行性不够；
9. 最后，用户常常用collect算子退入Scala空间，在driver里串行执行一些逻辑，又慢又容易出现内存不够的问题，尽量用Spark算子并行地计算或存储数据。

UC Berkeley AMPLabKay Ousterhout：下一代的Spark调度器——Sparrow

Kay是斯坦福教授、Tcl/Tk和Lustre主创者John Ousterhout的女儿，操作系统功力自然深厚。目前Spark的调度是中心式的，一个节点上的Spark Context调度众多的task到很多worker节点上。多个用户可能同时使用同一个Spark Context，造成瓶颈。从趋势上看，作业越来越短，从MapReduce最早的10分钟级别，到Spark的秒级和Spark Streaming的亚秒级（<100ms）；同时，集群越来越大，大到几百台以后，调度成为主要瓶颈。对于0.8版本，Spark的调度吞吐量是1500个task/sec，这限制了task的运行时间和集群的大小：如果task运行时间在10秒级，能够支持1000个16核节点；如果task是秒级，支持最多100节点；而到100ms级时，最多只能10个节点。在现有调度器上做优化边际效益有限。

Sparrow应运而生，它首先让每个用户有独立的调度器，另外，要支持更大的集群或更短的task时，只需增加新的调度器，整体的吞吐量和容错性都得到提升。Sparrow设计了一个调度器对众多worker的探测协议来选择合适的worker来执行task，具体细节请参考 视频、 slides和 SOSP’13论文。当task运行时间小于3秒时，Sparrow已经优于现在的Spark调度器，小于1.5秒时，则远为优胜。而跑TPC-H时Sparrow相比理论最优的调度器只有12%的差距。

英特尔软件与服务部门首席工程师 Jason Dai（戴金权）：实时分析处理

Jason的团队试图在Spark上构建一个集流处理、交互式查询、多迭代计算（图计算和机器学习）于一身的分析栈。他讨论了三个案例。第一个是实时的日志聚合和分析，采用了Kafka+Spark mini-batch的做法，未来会迁移到Spark Streaming。第二个是交互式查询，基于Spark/Shark，他特别介绍了一个统计Unique Event Occurrence（如Unique View）的时间序列分析，采用2-level aggregation。第三个是复杂机器学习和图计算，他介绍了一个N-degree Association问题，用于视频相似性图谱做聚类，做视频推荐。这些案例都来自实际需求，如优酷土豆的生产环境。

结语

因为篇幅有限，这里只能对一部分演讲做介绍，对其他部分的介绍要留待未来。但即使对本文已经介绍的部分，我们仍强烈鼓励大家下载slides和 视频，亲自品味其中的细微之处。