数据本地性
数据计算尽可能在数据所在的节点上运行，这样可以减少数据在网络上的传输，毕竟移动计算比移动数据代价小很多。进一步看，数据如果在运行节点的内存中，就能够进一步减少磁盘的I/O的传输。在spark中，数据本地性优先级从高到低为PROCESS_LOCAL>NODE_LOCAL>NO_PREF>RACK_LOACL>ANY即最好是运行在节点内存中的数据，次要是同一个NODE，再次是同机架，最后是任意位置。
PROCESS_LOCAL 进程本地化：task要计算的数据在同一个Executor中
NODE_LOCAL 节点本地化：速度比 PROCESS_LOCAL 稍慢，因为数据需要在不同进程之间传递或从文件中读取
NODE_PREF 没有最佳位置这一说，数据从哪里访问都一样快，不需要位置优先。比如说SparkSQL读取MySql中的数据
RACK_LOCAL 机架本地化，数据在同一机架的不同节点上。需要通过网络传输数据及文件 IO，比 NODE_LOCAL 慢
ANY 跨机架，数据在非同一机架的网络上，速度最慢
延迟执行
在任务分配到运行节点时，先判断任务最佳运行节点是否空闲，如果该节点没有足够的资源运行该任务，在这种情况下任务会等待一定的时间；如果在等待的时间内该节点释放出足够的资源，则任务在该节点运行，如果还是不足会找出次佳节点进行运行。通过这样的方式进行能让任务运行在更高级别的数据本地性节点，从而减少磁盘I/O和网络传输。一般情况下只对PROCESS_LOCAL和NODE_LOCAL两个数据本地性优先级进行等待，系统默认延迟时间为3S；
spark任务分配的原则是让任务运行在数据本地性优先级别更高的节点上，甚至可以为此等待一定的时间。该任务分派过程是由TaskSchedulerImpI.resourceOffers方法实现，该方法先对应用程序获取的资源进行混洗，以使任务能够更加均衡的分散在集群中运行，然后对任务集对应的TaskSetManager根据设置的调度算法进行排序，最后对TaskSetManager中的任务按照数据本地性分配任务运行节点，分配时先根据任务集的本地性从优先级高到低分配任务，在分配过程中动态判断集群中节点的运行情况，通过延迟执行等待数据本地性更高的节点运行。
High Available(HA)
Master异常
Master作为spark独立运行模式的核心，如果Master出现异常，则整个集群的运行状况和资源都无法进行管理，整个集群就处于群龙无首的状况，spark在设计的时候就考虑到了这个情况，在集群运行的时候，Master将启动一个或者多个Standy Master,当Master出现异常的时候，Standy Master将根据一定的规则确定其中一个接管Master。在独立运行模式中，spark支持如下几种策略，可以在配置文件spark-env.sh配置项spark.deploy.recoveryMode进行设置，默认为None.
①ZOOKEEPER:集群的元数据持久化到ZooKeeper中，当Master出现异常时，Zookeeper会通过选举机制选举出新的Master,新的Master接管时需要从Zookeeper获取持久化信息并根据这些信息回复集群状态
②FILESYSTMEM:集群的元数据持久化到本地文件系统中，当Master出现异常时，只要在该机器上重新启动Master,启动后新的Master获取持久化信息并根据这些信息恢复集群状态。
③CUSTOM：自定义恢复方式，对StandaloneRecoveryModeFactory抽象类进行实现并把该类配置到系统中，当Master出现异常时，会根据用户自定义方式恢复集群状态
④NONE:不持久化集群的元数据，当master出现异常时，启动新的Master不进行恢复集群状态，而是直接接管集群
如何配置spark master的HA
1.配置zookeeper，下载SPARK并解压
2.配置spark-env.sh
export JAVA_HOME=/usr/java/jdk1.8.0_101
export HADOOP_HOME=/root/hadoop/hadoop-2.7.4
export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop
export SCALA_HOME=/root/scala/scala-2.11.8
export HIVE_HOME=/root/hive/apache-hive-2.1.1
export LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export HADOOP_OPTS="-Djava.library.path=$HADOOP_HOME/lib:$LIB_NATIVE_DIR"
export SPARK_CLASSPATH=$SPARK_HOME/mysql-connector-java-5.1.39.jar
export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER -Dspark.deploy.zookeeper.url=spark1:2181,spark2:2181,spark3:2181,spark4:2181 -Dspark.deploy.zookeeper.dir=/spark"
说明： -Dspark.deploy.recoveryMode=ZOOKEEPER #说明整个集群状态是通过zookeeper来维护的，整个集群状态的恢复也是通过zookeeper来维护的。就是说用zookeeper做了spark的HA配置，Master(Active)挂掉的话，Master(standby)要想变成Master（Active）的话，Master(Standby)就要像zookeeper读取整个集群状态信息，然后进行恢复所有Worker和Driver的状态信息，和所有的Application状态信息； -Dspark.deploy.zookeeper.url=spark1:2181,spark2:2181,spark3:2181,spark4:2181#将所有配置了zookeeper，并且在这台机器上有可能做master(Active)的机器都配置进来；
-Dspark.deploy.zookeeper.dir=/spark -Dspark.deploy.zookeeper.dir是保存spark的元数据，保存了spark的作业运行状态； zookeeper会保存spark集群的所有的状态信息，包括所有的Workers信息，所有的Applactions信息，所有的Driver信息,如果集群
a.在Master切换的过程中，因为程序在运行之前，已经申请过资源了，driver和Executors通讯，不需要和master进行通讯的，所有的已经在运行的程序皆正常运行！因为Spark Application在运行前就已经通过Cluster Manager获得了计算资源，所以在运行时Job本身的调度和处理和Master是没有任何关系的！
b. 在Master的切换过程中唯一的影响是不能提交新的Job：一方面不能够提交新的应用程序给集群，因为只有Active Master才能接受新的程序的提交请求；另外一方面，已经运行的程序中也不能够因为Action操作触发新的Job的提交请求；
3.复制slaves.template成slaves,配置如下：
spark1
spark2
spark3
spark4
4.将配置好安装包分发给其他节点
5.各个节点配置环境变量，并使之生效
6.启动zookeeper
所有节点均要执行zkServer.sh start
7.启动hdfs集群
任意一个节点执行即可
8.启动spark集群
在一个节点启动start-all.sh,其他节点启动start-master.sh