1.Spark的集群模式node
1.1 集群中的组件apache
1.1.1 driver 后端
一个Spark应用自己在集群中是做为一个独立进程运行的.它在main程序中经过SparkContext来进行协调.这个独立进程就是driver端浏览器
1.1.2 executor缓存
为了运行在集群上.driver端的SparkContext能够链接至几种集群调度器(Cluster Manager)(StandAlone,Mesos,YARN等).安全
这些集群调度器会分配资源.一旦分配成功,Spark就会获取集群中的用于执行的资源(Executor 进程).这些Executor进程能够运行计算和存储数据.服务器
接下来,SparkContext会将应用程序代码(jar,或者Python文件)发送给Executor用以执行网络
1.2 一些Spark架构上的重要点多线程
i).每一个应用获取到的executor进程,会一直持续到整个应用的生命周期结束.而且在executor的内部,会以多线程的形式运行多个任务(Task)架构
优点是每一个应用之间相互隔离,在每一个应用的driver调度它本身的Task,而不一样应用的task运行在不一样的executor(也表明不一样的JVM)上
劣势是除非将数据写在一个第三方中,不然不一样的Spark应用是不能实现数据共享的
ii).Spark应用自己不知道其集群调度器是什么只要Spark能拿到executor并最终创建链接.它不关心这个executor是Mesos或者YARN调度的
iii).由于driver的中心地位,在Spark应用的整个生命周期中.driver必须保持对全部的executor的网络寻址.以监听和接收来自executor的链接请求
iv).由于driver负责调度集群上的任务(Task),更好的方式应该是在相同的局域网中靠近 worker 的节点上运行。
若是您不喜欢发送请求到远程的集群，倒不如打开一个 RPC 至 driver 并让它就近提交操做而不是从很远的 worker 节点上运行一个 driver
1.3 Spark集群的术语
| Application | 用户构建在 Spark 上的程序。由集群上的一个 driver 程序和多个 executor 组成 |
| Application jar | 一个包含用户 Spark 应用的 Jar.(用户的 Jar 应该没有包括 Hadoop 或者 Spark 库,由于它们将在运行时添加) |
| Driver program | 该进程运行应用的 main() 方法而且建立了 SparkContext |
| Cluster manager | 一个外部的用于获取集群上资源的服务。（例如，Standlone Manager，Mesos，YARN） |
| Deploy mode | 根据 driver 程序运行的地方区别.Cluster模式:driver运行与集群以内. Client模式:driver由提交者在集群以外自行建立 |
| Worker node | 任何在集群中能够运行应用代码的节点 |
| Executor | 一个为了在 worker 节点上的应用而启动的进程，它运行 task 而且将数据保持在内存中或者硬盘存储。每一个应用有它本身的 Executor |
| Task | 任务.一个将要被发送到 Executor 中的工做单元. |
| Job | 做业.一个由多个任务组成的并行计算，而且能从 Spark action 中获取响应（例如 save, collect）; 好比action,对用户来讲可见的基本都是Job |
| Stage | 每一个 Job 被拆分红更小的被称做 stage（阶段） 的 task（任务） 组，stage 彼此之间是相互依赖的（与 MapReduce 中的 map 和 reduce stage 类似） |
2.Spark的集群调度类型
Spark目前支持如下四种集群调度类型:
Standalone
Apache Mesos
Hadoop YARN
Kubernetes
3.应用程序的提交
使用 spark-submit 脚本能够提交应用至任何类型的集群
4.监控
4.1 Web UI 监控
每一个SparkContext都会启动一个Web UI，默认端口为4040，显示有关应用程序的有用信息。这包括：
i).调度器阶段和任务的列表
ii).RDD 大小和内存使用的概要信息
iii).环境信息
iv).正在运行的执行器的信息
能够经过在Web浏览器中打开 http://<driver-node>:4040 来访问此界面.(若是多个SparkContexts在同一主机上运行,则它们将绑定到连续的端口从4040(4041，4042等)开始)
注意:
默认状况下 Web UI 中信息仅适用于运行中的应用程序
要在过后还能经过Web UI查看,请在应用程序启动以前,将spark.eventLog.enabled设置为true(详见后).
4.2 事件日志的持久化
使用file-system提供的程序类(spark.history.provider)能够对执行日志进行持久化.
当进行持久化时,基本日志记录目录必须在spark.history.fs.logDirectory配置选项中提供，而且应包含每一个表明应用程序的事件日志的子目录
Spark任务自己必须配置启用记录事件,并将其记录到相同共享的可写目录下.
例如,若是服务器配置了日志目录hdfs://namenode/shared/spark-logs,
那么客户端选项将是 spark.eventLog.enabled=true
spark.eventLog.dir=hdfs://namenode/shared/spark-logs
4.3 history server
若是在一个应用结束以后还须要查看应用的信息.能够经过Spark的历史服务器构建应用程序的UI， 只要应用程序的事件日志存在,就能够继续查询
./sbin/start-history-server.sh
默认状况,会在http://<server-url>:18080 建立一个WebUI,显示未完成,完成以及其它尝试的任务信息
4.4 history server 的一些相关配置
4.4.1 环境相关
| SPARK_DAEMON_MEMORY | history server 内存分配（默认值：1g） |
| SPARK_DAEMON_JAVA_OPTS | history server JVM选项（默认值：无） |
| SPARK_PUBLIC_DNS | history server 公共地址。若是没有设置，应用程序历史记录的连接可能会使用服务器的内部地址，致使连接断开（默认值：无） |
| SPARK_HISTORY_OPTS | spark.history.* history server 配置选项（默认值：无） |
4.4.2 Spark配置
| spark.history.provider | org.apache.spark.deploy.history.FsHistoryProvider | 执行应用程序历史后端的类的名称。 目前只有一个实现，由Spark提供，它查找存储在文件系统中的应用程序日志 |
| spark.history.fs.logDirectory | file:/tmp/spark-events | 要加载的应用程序事件日志的目录.能够是本地文件系统或任何Hadoop支持的分布式文件系统 |
| spark.history.fs.update.interval | 10s | 在日志目录中检查新的或更新的日志间隔区间. |
| spark.history.retainedApplications | 50 | 在缓存中保留UI数据的应用程序数量.若是超出此上限，则最先的应用程序将从缓存中删除(删除后从磁盘读取) |
| spark.history.ui.maxApplications | Int.MaxValue | 在历史记录摘要页面上显示的应用程序数量 |
| spark.history.ui.port | 18080 | history server 的Web界面绑定的端口 |
| spark.history.kerberos.enabled | false | 代表 history server 是否应该使用kerberos进行登陆.若是 history server 正在访问安全的Hadoop集群上的HDFS文件 |
| spark.history.kerberos.principal | (none) | 若是使用使用kerberos进行登陆,history server 的Kerberos主要名称 |
| spark.history.kerberos.keytab | (none) | 若是使用使用kerberos进行登陆,history server 的kerberos keytab文件的位置 |
| spark.history.ui.acls.enable | false | 指定是否应检查acls受权查看应用程序的用户 |
| spark.history.ui.admin.acls | empty | 经过逗号来分隔具备对history server中全部Spark应用程序的查看访问权限的用户/管理员列表 |
| spark.history.ui.admin.acls.groups | empty | 经过逗号来分隔具备对history server中全部Spark应用程序的查看访问权限的组的列表 |
| spark.history.fs.cleaner.enabled | false | 指定 History Server是否应该按期从存储中清除事件日志 |
| spark.history.fs.cleaner.interval | 1d | job history清洁程序检查要删除的文件的时间间隔 |
| spark.history.fs.cleaner.maxAge | 7d | history保留时间,超出这个时间江北清洁程序删除 |
| spark.history.fs.numReplayThreads | 25% of available cores | history server 用于处理事件日志的线程数 |
注意:
i).history server 显示完成的和未完成的Spark做业。 若是应用程序在失败后进行屡次尝试，将显示失败的尝试，以及任何持续未完成的尝试或最终成功的尝试
ii).未完成的程序只会间歇性地更新。 更新的时间间隔由更改文件的检查间隔 (spark.history.fs.update.interval) 定义。 在较大的集群上，更新间隔可能设置为较大的值。
查看正在运行的应用程序的方式其实是查看本身的Web UI
iii).没有注册完成就退出的应用程序将被列出为未完成的，即便它们再也不运行。若是应用程序崩溃，可能会发生这种状况
iv).一个用于表示完成Spark做业的一种方法是明确地中止Spark Context (sc.stop())，或者在Python中使用 with SparkContext() as sc
4.5 REST API
Spark也提供Rest方式.这为开发人员提供了一种简单的方法来为Spark建立新的可视化和监控工具
此处略,详见官网
4.6 Metrics 与 Ganglia
略,详见官网