Spark实践的阶段性总结

时间:2023-12-19 23:46:20

写这篇小总结是因为前段时间是自己业余时间对Spark相关进行了些探索,接下来可能有别的同事一起加入,且会去借用一些别的服务器资源,希望可以借此理下思路。

实践Spark的原因

在之前Spark简介及安装的文章前面,介绍了Spark在大数据处理领域的一个定位,以及AMP实验室构建的生态圈,总之我定义Spark为一个值得研究的东西,包括他的实现语言Scala,底层的资源管理Mesos/YARN。对于Spark的实践,我理了下思路,大致有以下几个阶段:

1.看paper,官网等网上的资源介绍,了解熟悉Spark,熟悉scala之后看看源码

2.搭建Spark,以standalone的方式run example,在spark-shell下体验一下Scala的API,在pyspark下体验Python API

3.搭建Mesos,让Spark依赖Mesos跑起来

4.更大规模搭建Spark集群,测试一个场景,对性能进行评估,出一个具有说服力的报告

5.优化Spark集群配置,编写更多算法去体验

6.最后,基于Spark这个核心,打算建立一个平台,现在的构想还比较初步

现在处于从3进入4的阶段,而关于Spark的构想,也还有一些东西需要去实践,新的技术需要去调研和了解。大致是有了Spark集群之后,对Mesos和YARN有一个选择问题,从Spark读取另一个Hadoop的HDFS上文件,这件事的网络延迟影响究竟有多大,毕竟现在的情况是hadoop和spark肯定是部署两套机器上,存储节点和计算节点分离,特别是基于Mesos的话,肯定是这种状态。像豆瓣的Dpark可能是和MFS上的数据打交道的,可能会比较好地解决本地化的问题,可能能检测到目标数据存在某个节点上,而把这次任务调度到那台机器上,类似这样的感知我们肯定做不了。其次,现在搭建的Spark,目标是为了一些ML,DM的算法服务,如果是SQL能完成的简单查询任务,ad-hoc的东西让Shark来做应该就满足了,所以相关python的算法包支持,甚至能否支持结合R在Spark上,也是有待考察的一件事。关于这点,AMP实验室正在开发的MLbase是支持了不同抽象程度的算法api,今年夏天应该是要release一部分,冬天还会release一部分,MLBase能在Spark上提供给我们什么样程度的支持也有待考察。更远的,Scala其实还蛮适合编写DSL的,最后我们希望能在Spark这层之上,基于python等算法包,在最上面再封装一层DSL,类似Hadoop上的pig,而不是hive,来把数据处理的整个过程可视化出来,每个过程都可以清楚地剥离,甚至可以可视化。

Spark及周边

我可以使用的开发机无法连接外网,所以搭建Spark时使用的是编译过的Spark版本。Spark的编译依赖scala的sbt(simple build tool),相当于java的maven,但会更强大。sbt方面,本来Spark可以支持sbt构建的scala项目,但是sbt compile test package这些步骤在开发机上无法完成,根据项目里的build.sbt,构建是需要联网的。无奈的做法是使用spark的pyspark跑一些.py的程序,而spark支持的python API有些功能还没有完全完善,而且python是动态语言,在进行RDD相关操作时候,api使用起来总有些区别,不像java和scala的api会大同小异。

Mesos的搭建也是费了一番力,Mesos的优势在于利用linux container,完成了资源的分离和调度工作,不过也比较迷茫Mesos是否真的可靠,是不是YARN会更靠谱,比较Mesos是C++写成的,与Spark的交互会依赖JNI。淘宝的Spark是搭建在阿里的YARN集群上,所以我也还要进一步确定对于Mesos和YARN两套资源管理系统的异同。

以上两点是关于sbt和Mesos的,还有最近有意学习了下Scala这门语言的情况,有一些总结。《programming in scala》和《scala程序设计》都看了一遍,后者更适合java程序员读,从实践和特性介绍角度,都更好。整体上,scala的创新也许就是综合了其他语言的优点,本身是纯OO且面向函数的,这两者之间你可以使用任何一种你习惯的编程方式。与java的兼容不需要任何特殊写法和胶水代码,继承、调用、访问域、实现接口都没有问题,trait拥有类似接口的实现,介于单一和多继承之间,可以做到类似AOP那样切面的效果。函数式编程方面把immutable贯彻在每一处,从变量声明val到不可变的容器。函数式编程的思想主要就体现在两点上:函数是一级公民;方法引用透明。前者让函数可以像值一样互相传递,函数内可以内嵌函数;后者保证任何方法的调用都可以用他的结果来代替,而不影响程序语义,即函数不会有任何副作用。并行编程方面借鉴erlang的actor模型,每个传递对象本身就是不可变的,自然不用担心多线程时候对某个变量的修改操作会带来的任何影响。其实Spark里很多对RDD的transform操作,都大量依赖了scala本身带的filter(), map(), reduce(), foldLeft(), foreach()等操作,而scala的不可变也完全符合RDD。

阶段总结及展望

现在正在尝试一个可测试的场景,稍微编写一些代码,从HDFS上取数据,做一些处理。然后将这个程序放到更大的集群上去对比,性能怎么样?关于Mesos和YARN,也需要更多的调研和尝试,而sbt如果在现有的开发机上不可行的话,是否先编写python版本的程序运行?尝试部署一个Shark,看看Shark是否能够投入到一些场景中使用?python、R,怎样/是否可以融入Spark?MLbase?Spark本身源码层面的了解,以及scala语言本身更深入的认识。

在探索Spark的过程中,还需要更多的实践,更深的了解,更广的涉猎。

(全文完)