大数据Spark技术研究

摘要：文章从技术角度对Spark进行了深入探讨。首先提出了Hadoop的技术缺陷；然后提出了Spark的设计思想和系统架构，分析了Spark在Spark SQL、MLlib、Spark 流和GraphX方面技术处理过程。接着重点分析了Spark的六种运行模式的执行过程；最后分析了Spark当前应用现状和未来发展趋势。

关键词：大数据 Hadoop Spark Spark 流

中图分类号：TP311 文献标识码：A 文章编号：1007-9416（2015）09-0000-00

大数据远不止大量的数据（TB）和处理大量数据的技术，它以一种前所未有的方式，通过对海量数据进行分析，获得有巨大价值的产品和服务[1]。然而面对庞大的数据来获得有价值的信息是一个巨大的挑战。为了克服上述困难，近几年来推出了Hadoop、PureData和Exadata等多种大数据系统分析平台，以Hadoop平台最为突出，深受用户的欢迎。但是随着应用的不断深入，Hadoop暴露出了它的局限性。主要体现在以下几方面：第一，操作过于单一，仅支持Map和Reduce两种操作；第二，迭代计算效率较低，尤其在机器学习和图形计算方面[2]。 2013年底由Apache 软件基金会提出的Spark框架技术较好地解决了这些问题。

1 Spark技术架构

1.1 Spark设计思想

Spark是一种基于HDFS的并行计算架构。主要思想是通过一种新的作业和数据容错方式来减少磁盘和网络的I/O开销 其核心技术是弹性分布式数据集（RDD），是指在一组存储计算机中的只读数据集合，这个数据集合可以在分区对象丢失后进行重建[5]。也就是说RDD的元素不一定需要存储在物理介质中，相反，一个RDD的处理进程包含了如何从可靠的数据存储中去获取足够的信息来对这个RDD进行处理。如果RDDS的任务节点失败，总可以进行重建[3]。

1.2 Spark系统架构

与MapReduce不同，Spark并不仅仅局限于编写map和reduce两个方法，它为用户提供了更为强大的内存计算模型，使得用户可以通过编程将数据读取到集群的内存当中，这样可以快速在内存中对数据集进行多次迭代，支持复杂的数据挖掘算法和图计算算法使用Scala语言开发，以Mesos作为底层的调度框架，可以和 Hadoop和Ec2紧密集成，直接读取HDFS或S3的文件进行计算并把结果写回HDFS或S3，是Hadoop和Amazon云计算生态圈的一部分，项目的core部分代码只有63个Scala文件，执行效率高效。Spark主要由四个模块组成：Spark SQL、MLlib、Spark 流和GraphX。Spark SQL为了兼容主流关系型数据库系统（RDBMS）可以允许用户编写SQL和HQL两种脚本执行查询，其核心组件是JavaSchemaRDD，它是一个类似于RDBMS的一个Table，由Row和Schema对象来描述Table中行对象和列的DataType。

2 Spark运行模式

2.1 Spark任务调度方式

Spark的运行模式有多种，主要由SparkContext的MASTER环境变量所获得的值来决定，有些模式还需要程序接口来配合辅助决定。但概括起来，Spark运行都以Spark-Context为总调度驱动程序，负责应用程序的资源分配，期间分别创建作业调度和任务调度两级模块。作业调度模块是基于阶段的高层调度模块，每个Spark 作业计算通常有多个阶段，每个阶段分解为一组任务集，以任务组的形式提交给底层任务调度模块来具体执行实际计算任务，任务调度模块负责启动实际任务，监控和汇报任务运行情况。如果分配任务成功，SparkContext会将应用程序代码给指定的执行者完成一个或多个任务[4]。

2.2 Spark运行模式类型

Spark的运行模式，归纳起来有六种。

（1）Local[M]。该模式使用 LocalBackend 调用TaskSchedulerImpl 实现。LocalBackend 响应Scheduler的receiveOffers请求，根据可用CPU Core的设定值[M]直接生成WorkerOffer资源返回给Scheduler，并通过Executor类在线程池中依次启动和运行Scheduler返回的任务列表。

（2）Standalone。该模式使用SparkDeploySchedulerBackend调用TaskSchedulerImpl来实现 ，而SparkDeploySchedulerBackend同时继承了CoarseGrainedSchedulerBackend。是一个在Akka Actor上实现的粗粒度的资源调度类，在整个Spark Job运行期间，监听和拥有注册给它的Executor资源，比如接受Executor注册，状态更新，响应Scheduler请求等，并且根据现有Executor资源发起任务流程调度。

（3）Local-cluster。伪分布模式实际上是在Standalone模式上实现的，也就是在SparkContext初始化的过程中在本地启动一个单机的伪分布Spark集群，后面的执行流程与Standalone模式相同。

（4）Mesos。该模式主要根据颗粒度大小来区分，粗粒度的CoarseMesosSchedulerBackend继承了CoarseGrained SchedulerBackend，相对于父类额外做的工作还要实现MScheduler接口，注册到Mesos资源调度的框架中，用于接收Mesos的资源分配，在得到资源后通过Mesos框架远程启动CoarseGrainedExecutorBackend，以后的任务交互过程和Spark standalone模式一样，由DriverActor和Executor Actor直接完成。 细粒度的MesosSchedulerBackend直接继承SchedulerBackend，但同样实现了MScheduler接口，完成Mesos资源调度框架中的注册，接收Mesos的资源分配。不同之处是在接收资源分配以后，MesosSchedulerBackend启动的是远程Executor，通过在远程执行命令来启动MesosExecutorBackend，直接执行对应的任务。

（5）Yarn-standalone。Yarn-Standalone模式相对其它模式有些特殊，需要外部程序辅助启动应用程序。Client通过Yarn Client API在Hadoop集群上启动一个Spark App Master，Spark App Master首先为自己注册一个Yarn App Master，再启动用户程序，然后根据Client传递过来的参数，Spark App Master通过Yarn RM/NM接口在集群中启动多个Container运行CoarseGrainedExecutorBackend往CoarseGrainedSchedulerBackend注册。后面的任务调度流程跟其它Cluster模式类似，不再述说。

（6）Yarn-client。该模式的SparkContext运行在本地，适用于应用程序本身需要在本地交互的情景。这种模式下SparkContext在初始化时首先启动YarnClientSchedulerBackend，然后再调用客户端包远程启动一个作业作为Spark的App Master，相对于Yarn-standalone模式，此模式不再负责启动用户程序，而只是启动Backend便于跟客户端本地Driver进行数据传递，后面的任务调度流程跟其它模式类似。

3 Spark应用现状及发展

目前SPARK已经构建了自己的整个大数据处理生态系统，如流处理、图技术、机器学习、NoSQL查询等方面的技术，并且是Apache顶级项目。虽然Spark对内存要求较高，推出时间较短未经过实践考验，但伴随着大数据相关技术和产业的逐步成熟，继Hadoop之后，Spark技术以集大成的无可比拟的优势，发展迅速，将成为替代Hadoop的下一代云计算、大数据核心技术。可以预计2015年下半年在社区和商业应用上会有爆发式的增长。

参考文献

[1] K. Shvachko， K. Hairong， S. Radia e R. Chansler. The Hadoop Distributed File System[C]. IEEE 26th Symposium on Mass Storage Systems and Technologies， 2010.

[2] Spark： Lighting-fast cluster computing[EB/OL]. http：///.

[3] M. Hirzel， H. Andrade， B. Gedik， et al. IBM Streams Processing Language： Analyzing Big Data in motion[J]. IBM Journal of Research and Development.2013，57（7）：1-7.

[4] T. Chardonnens， P. Cudre-Mauroux， M. Grund ，et al.Big data analytics on high Velocity streams： A case study[C]. IEEE International Conference on Big Data， 2013.

收稿日期：2015-08-18

作者简介：刘峰波，（1982―），男，广州广东人，硕士，职称：信息技术一级教师，主研领域： 计算机网络。