spark on yarn架构简介

spark自从问世以来就收到了广泛的关注，其热度一直居高不下。spark的出现，为实时数据的处理带来了极大的方便，相比Hadoop，spark在某些情况下处理数据的速度要快于Hadoop，其主要原因有以下两点：

1. spark中间的数据不落地，这是最主要的原因，中间的数据存放在内存中，这就极大的减少了磁盘的读取以及IO的操作，所以，这也是spark适合迭代式工作的原因。

2. spark中DAGScheduler的出现，对任务进行了一个很好的划分，其主要的划分的依据是宽依赖（这个后面我会细说），也就是根据任务的拓扑结构进行划分，保证了窄依赖的RDD会在一起，减少了shuffle的操作过程，极大的减少了时间开销。

但是如果说spark取代了Hadoop，我认为不能这么说，还是要看业务场景，Hadoop适合大吞吐量的静态数据，spark适合实时数据流，说实在，如果spark跑MR作业，其时间不一定比Hadoop快，因为spark太吃内存了。下面就说下我理解的spark的架构（我用到的调度器是yarn）：

架构中的主要构件（其中yarn部分不再介绍，具体可以参考博客http://blog.csdn.net/hanlaipeng11/article/details/74923086）：

RDD：这是spark中的一个关键的概念，RDD我们可以理解为spark的每个阶段的产物，正是一个阶段一个阶段的产物构成了spark的整个拓扑结构。所以每一个RDD之间都会有直接或间接的关系，直接的关系，也就是说如果RDD1是由RDD2直接生成的，那么这就是窄依赖，因为这样数据不需要shuffle过程，极大的减少了时间的开销，但是如果RDD1是由多个不同的RDD生成的，那么这就是宽依赖，也就是需要一个shuffle的过程，这也就是为什么DAGScheduler会按照宽依赖来划分stages。有了依赖关系，这样就保证了容错性，当中间的某个数据丢失的时候，它就会根据其依赖关系重新生成，并不需要将整个任务重新执行。

DAGScheduler：任务划分器，将spark任务划分成有向无环图的结构，根据的是是否需要shuffle，也就是RDD的宽依赖，找到最佳的调度方法，这样就可以合理的利用资源，提高任务的执行效率。

TaskScheduler（图中的YarnClusterScheduler）：主要负责任务的调度，资源的申请，监控任务的执行。

Excutor：任务执行的单元，执行TaskSet中的作业，并向Driver传输心跳。

具体流程为：我们先将任务提交给ResourceManager，他会立刻在一个节点上启动一个ApplicationMaster来管理这个任务，而这个ApplicationMaster中主要做的事情为：SparkContext获取到任务，然后其中的DAGScheduler会根据任务的拓扑情况进行划分，划分成一个个的stages，划分的主要依据是基于RDD的宽依赖，这样任务通过划分变成了一个任务集合也就是TaskSet，然后将这个TaskSet交给TaskScheduler来进行管理（也就是图中的YarnClusterScheduler），他会向ResourceManager申请资源，然后ResourceManager会根据集群中资源的情况分配container，里面就是一个个的任务执行单元Excutor，然后TaskScheduler还负责监控作业的执行情况，最后注销任务。

spark 的架构了解了，我们就来说一下这个shuffler，为什么划分任务要根据shuffler？

shuffler阶段主要是对并行操作的数据结果进行sort、hash的一个过程，由于要读取多个RDD的结果，并对所有结果进行整体操作，所以会带来比较大的IO消耗，可能还要有磁盘的读取等操作，这一步是很关键，并且很耗时的。当然了，这也是spark的瓶颈之一，最开始的spark的shuffler过程是基于Hash实现的，他会将中间的数据文件都打开，然后磁盘读取，读取文件，但是当小文件数量巨大的时候它会很消耗内存，并且磁盘的读取也是很耗时的，所以spark又实现了基于排序的shuffle，这个是将所有文件读在一个文件中丙进行排序操作，但是在分片的时候，它采用的策略是建立一个index，reduce根据index来读取数据，这要减少了内存的开销，但是照成的结果是所有的数据都需要进行排序。各有利弊，我们可以根据实际的需求来进行策略的选择。

以上均为个人看法，如有错误，还请各位大神指正，谢谢。