Yahoo的Spark实践

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的架构就应运而生了，基本设计是Ha