，从Spark的未来，到各种计算范式的实操，到最前沿的科学应用（用Spark做脑神经元的分析研究），再到新创业公司基于Spark的产品发布，让场内和场外的Spark以及大数据爱好者们饱享了一次饕餮盛宴。
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的好处：
- 实时+批量，融合实时洞察和历史洞察形成全时洞察，采用Spark Streaming + Spark/Shark/BlinkDB；
- 流处理+机器学习，实时获得更复杂的洞察，采用Spark Streaming+MLlib；
- 图流水线（图创建/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。他已经着手开始这个工作。
总体而言，这个演讲的信息量很高，实操性强，很值得借鉴。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
