Spark发展现状与战线

最后更新于:2022-04-01 20:32:55

### 前言 现今Spark正是风头正劲时,Spark本是UCBerkeley的AMPLab诞生的项目,后来捐赠给了Apache来管理源码和后续发展。今年从Apache孵化器终于孵化出了1.0版本。其对大数据的支持从内存计算和流处理,到交互式查询,一直到图计算和机器学习,可谓摆开了架势、拉长了战线,一方面挑战老前辈Hadoop和MapReduce,另一方面又随时准备迎接同样的后起之秀的挑战。 ### 大数据的今天 今天的大数据系统生物圈百花齐放,有已经如日中天的通用批处理MapReduce,也有针对不同应用场景而特殊化的处理系统。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-08-31_57c6b1355d54d.jpg) ### 全栈式的Spark Spark作为后起之秀,以其RDD模型的强大表现能力,不断完善自己的功能,逐渐形成了一套自己的生物圈,提供了full-stack的解决方案。其中主要包括Spark内存中批处理,Shark交互式查询,Spark Streaming流式计算三大部分。此外还有GraphX和MLBase提供的常用图计算和机器学习算法。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-08-31_57c6b13574a99.jpg) 而Spark由于采用Scala编写,底层使用Akka,代码十分简洁。而且借助RDD的强大表现力,Spark各种子项目的代码量也很小。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-08-31_57c6b1358cce4.jpg) ### Spark使用情况 援引自[一篇博文](http://www.beagledata.com/news/764.html),看一下Spark在互联网界的使用情况。 **1. 腾讯** **“**广点通是最早使用Spark的应用之一。腾讯大数据精准推荐借助Spark快速迭代的优势,围绕“数据+算法+系统”这套技术方案,实现了在“数据实时采集、算法实时训练、系统实时预测”的全流程实时并行高维算法,最终成功应用于广点通pCTR投放系统上,支持每天上百亿的请求量。 基于日志数据的快速查询系统业务构建于Spark之上的Shark,利用其快速查询以及内存表等优势,承担了日志数据的即席查询工作。在性能方面,普遍比Hive高2-10倍,如果使用内存表的功能,性能将会比Hive快百倍。 **2. Yahoo** **“**Yahoo将Spark用在Audience Expansion中的应用。Audience Expansion是广告中寻找目标用户的一种方法:首先广告者提供一些观看了广告并且购买产品的样本客户,据此进行学习,寻找更多可能转化的用户,对他们定向广告。Yahoo采用的算法是logistic regression。同时由于有些SQL负载需要更高的服务质量,又加入了专门跑Shark的大内存集群,用于取代商业BI/OLAP工具,承担报表/仪表盘和交互式/即席查询,同时与桌面BI工具对接。目前在Yahoo部署的Spark集群有112台节点,9.2TB内存。 **3. 淘宝** **“**阿里搜索和广告业务,最初使用Mahout或者自己写的MR来解决复杂的机器学习,导致效率低而且代码不易维护。淘宝技术团队使用了Spark来解决多次迭代的机器学习算法、高计算复杂度的算法等。将Spark运用于淘宝的推荐相关算法上,同时还利用Graphx解决了许多生产问题,包括以下计算场景:基于度分布的中枢节点发现、基于最大连通图的社区发现、基于三角形计数的关系衡量、基于随机游走的用户属性传播等。 **4. 优酷土豆** **“**优酷土豆在使用Hadoop集群的突出问题主要包括:第一是商业智能BI方面,分析师提交任务之后需要等待很久才得到结果;第二就是大数据量计算,比如进行一些模拟广告投放之时,计算量非常大的同时对效率要求也比较高,最后就是机器学习和图计算的迭代运算也是需要耗费大量资源且速度很慢。 最终发现这些应用场景并不适合在MapReduce里面去处理。通过对比,发现Spark性能比MapReduce提升很多。首先,交互查询响应快,性能比Hadoop提高若干倍;模拟广告投放计算效率高、延迟小(同hadoop比延迟至少降低一个数量级);机器学习、图计算等迭代计算,大大减少了网络传输、数据落地等,极大的提高的计算性能。目前Spark已经广泛使用在优酷土豆的视频推荐(图计算)、广告业务等。 ### Spark的战线 Ø  **DAG执行引擎**:不少框架都提出了类似的基于DAG图的执行引擎,来对MapReduce模型的缺点进行优化。如Apache下的Ooize和Tez。 Ø  **内存计算**:作为Spark的杀手锏,分布式内存计算的市场竞争也非常激烈,有非常火的SAP的HANA平台,微软的Dryad,以及Druid。此外,还有众多的数据库厂商推出了内存数据库、内存表或内存计算网格(data grid)等产品。 Ø **交互式查询(Shark)**:Hive的性能问题和(近)实时分析的需求使得不少公司都提出了自己的解决方案。其中最耀眼的当属无敌的Google提出的Dremel嵌套计算模型。而其开源版本也是众多,有Cloudera Impala配合Parquet,以及Apache的Drill。 Ø  **流式计算(Streaming Spark)**:Spark通过将连续的数据流划分成离散的数据段,从而将触角伸到了流式处理领域。而在这一领域,Twitter的Storm(已捐给Apache)被许多公司采用,也是不可小觑。相比之下,Yahoo的S4就显得冷清多了。 Ø **图计算(GraphX)**:图计算方面,Spark借鉴了Pregel和PowerGraph中的图分布式计算和图切割思想,提出了自己的工具包GraphX。它扩展了Spark,例如用EdgeRDD了和VertextRDD表示边和顶点等。 Ø  **机器学习(MLBase)**:机器学习方面,Mahout是个有力的竞争对手,但Mahout也是基于MapReduce任务实现的。而在线机器学习框架Jubatus资料很少,进展不明。 看完这些总结后,不得不佩服Spark的应用范围之广!感觉目前Spark唯一没有单独建立子项目的就是存储方面了,主要是中间内存计算时的存储引擎。目前要么完全由Spark在内存中管理,要么通过Tachyon统一管理。 ### Spark的未来 **Spark 1.0.1** Ø  Spark SQL(原Shark)支持JSON **Spark 1.1** Ø  通用Shuffle接口 Ø  MLLib统计算法 Ø  JDBC驱动 Ø  基于排序的Shuffle **Spark 1.2** Ø  重构存储支持 **Spark 1.3+** Ø  **SparkR对R语言统计分析的支持**(目前已能下载) ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-08-31_57c6b135a50a9.jpg) ### 参考资料 1 The State of Spark 2[大数据计算新贵Spark在腾讯雅虎优酷成功应用解析](http://www.beagledata.com/news/764.html) 3 The Future of Apache Spark
';