深入解析Spark集群的架构

Spark集群中的Spark Application（Spark应用）的运行架构由两部分组成（如图5-1所示）：包含SparkContext的Driver Program（驱动程序）和在Executor中执行计算的程序。Spark Application一般都是在集群上以独立的进程集合运行。Spark有多种运行模式，比如Spark Standalone（Spark自身单独的集群资源管理器）、Yarn、Mesos，这些集群资源管理器给Spark Applicaiton提供了计算资源的分配和对这些资源的管理，这些资源既可以给Executor运行，也可以给Driver Program运行。根据Spark Application的Driver program是否在集群资源中运行，Spark Application的运行方式又可以分为Cluster模式和Client模式，如果是Cluster模式，Spark会把Application代码（以JAR或者Python定义的文件并传送到Worker结点上的SparkContext）发送到Executor，然后Driver发送Task任务让Executor中的线程池运行。

图5-1 Spark运行架构图

每个Application获取专属的Executor进程，该进程在Application运行的过程中一直在内存中驻留，并以多线程方式运行Tasks。这种Application隔离机制无论是从调度角度看（每个Driver调度它自己的任务），还是从运行角度看（来自不同Application的Task运行在不同的JVM中）都很有优势。当然，这也意味着Spark Application不能跨应用程序共享数据，除非将数据写入到外部存储系统。(www.xing528.com)

对于潜在的集群资源管理器来说，Spark是不可知的，也就是说Spark与集群资源管理器无关，只要能够获取Executor进程，并能保持相互之间的通信就可以了，即使是在支持其他Application的集群资源管理器（例如，Mesos/Yarn）上运行也相对简单。

提交Spark Application的Client应该靠近Worker结点（运行Executor的结点），最好是在同一个Rack（局域网）里，因为Spark Application运行过程中Driver和Executor之间有大量的信息交换；如果想在远程集群中运行，最好使用RPC（Remote Procedure Call Protocol，即远程过程调用协议）将Spark Application提交给集群，不要远离Worker运行Spark Application。

每个Driver Program有一个WebUI监控器，一般是在4040端口，可以看到有关Spark Application运行的任务、程序和存储空间大小等信息。在浏览器中输入网址来访问：ht-tp：//＜drivernode＞：4040。通过WebUI监控器可以方便我们监控Spark Application在集群中的运行状况。