Spark实践的阶段性总结

写这篇小总结是因为前段时间是自己业余时间对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的过程中，还需要更多的实践，更深的了解，更广的涉猎。

(全文完)