独立运行Spark

用于程序目录都会被清空spark.worker.cleanup.interval1800 (30分)在本地机器上，worker清空老的应用程序工作目录的时间间隔spark.worker.cleanup.appDataTtl7 24 3600 (7天)每个worker中应用程序工作目录的保留时间。这个时间依赖于你可用磁盘空间的大小。应用程序日志和jar包上传到每个应用程序的工作目录。随着时间的推移，工作目录会很快的填满磁盘空间，特别是如果你运行的作业很频繁。连接一个应用程序到集群中为了在Spark集群中运行一个应用程序，简单地传递spark://IP:PORT URL到SparkContext为了在集群上运行一个交互式的Spark shell，运行一下命令：./bin/spark-shell --master spark://IP:PORT你也可以传递一个选项--total-executor-cores <numCores>去控制spark-shell的核数。启动Spark应用程序spark-submit脚本支持最直接的提交一个Spark应用程序到集群。对于独立部署的集群，Spark目前支持两种部署模式。在client模式中，driver启动进程与客户端提交应用程序所在的进程是同一个进程。然而，在cluster模式中，driver在集群的某个worker进程中启动，只有客户端进程完成了提交任务，它不会等到应用程序完成就会退出。如果你的应用程序通过Spark submit启动，你的应用程序jar包将会自动分发到所有的worker节点。对于你的应用程序依赖的其它jar包，你应该用--jars符号指定（如--jars jar1,jar2）。另外，cluster模式支持自动的重启你的应用程序（如果程序一非零的退出码退出）。为了用这个特征，当启动应用程序时，你可以传递--supervise符号到spark-submit。如果你想杀死反复失败的应用，你可以通过如下的方式：./bin/spark-class org.apache.spark.deploy.Client kill <master url> <driver ID>你可以在独立部署的Master web UI（http://:8080）中找到driver ID。资源调度独立部署的集群模式仅仅支持简单的FIFO调度器。然而，为了允许多个并行的用户，你能够控制每个应用程序能用的最大资源数。在默认情况下，它将获得集群的所有核，这只有在某一时刻只允许一个应用程序才有意义。你可以通过spark.cores.max在SparkConf中设置核数。val conf = new SparkConf() .setMaster(...) .setAppName(...) .set("spark.cores.max", "10")val sc = new SparkContext(conf)另外，你可以在集群的master进程中配置spark.deploy.defaultCores来改变默认的值。在conf/spark-env.sh添加下面的行：export SPARK_MASTER_OPTS="-Dspark.deploy.defaultCores=<value>"这在用户没有配置最大核数的共享集群中是有用的。高可用默认情况下，独立的调度集群对worker失败是有弹性的（在Spark本身的范围内是有弹性的，对丢失的工作通过转移它到另外的worker来解决）。然而，调度器通过master去执行调度决定，这会造成单点故障：如果master死了，新的应用程序就无法创建。为了避免这个，我们有两个高可用的模式。用ZooKeeper的备用master利用ZooKeeper去支持领导选举以及一些状态存储，你能够在你的集群中启动多个master，这些master连接到同一个ZooKeeper实例上。一个被选为“领导”，其它的保持备用模式。如果当前的领导死了，另一个master将会被选中，恢复老master的状态，然后恢复调度。整个的恢复过程大概需要1到2分钟。注意，这个恢复时间仅仅会影响调度新的应用程序-运行在失败master中的应用程序不受影响。配置为了开启这个恢复模式，你可以用下面的属性在spark-env中设置SPARK_DAEMON_JAVA_OPTS。System propertyMeaningspark.deploy.recoveryMode设置ZOOKEEPER去启动备用master模式（默认为none）spark.deploy.zookeeper.urlzookeeper集群url(如192.168.1.100:2181,192.168.1.101:2181)spark.deploy.zookeeper.dirzookeeper保存恢复状态的目录（默认是/spark）可能的陷阱：如果你在集群中有多个masters，但是没有用zookeeper正确的配置这些masters，这些masters不会发现彼此，会认为它们都是leaders。这将会造成一个不健康的集群状态（因为所有的master都会独立的调度）。细节zookeeper集群启动之后，开启高可用是简单的。在相同的zookeeper配置（zookeeper URL和目录）下，在不同的节点上简单地启动多个master进程。master可以随时添加和删除。为了调度新的应用程序或者添加worker到集群，它需要知道当前leader的IP地址。这可以通过简单的传递一个master列表来完成。例如，你可能启动你的SparkContext指向spark://host1:port1,host2:port2。这将造成你的SparkContext同时注册这两个master-如果host1死了，这个配置文件将一直是正确的，因为我们将找到新的leader-host2。"registering with a Master"和正常操作之间有重要的区别。当启动时，一个应用程序或者worker需要能够发现和注册当前的leader master。一旦它成功注册，它就在系统中了。如果错误发生，新的leader将会接触所有之前注册的应用程序和worker，通知他们领导关系的变化，所以它们甚至不需要事先知道新启动的leader的存在。由于这个属性的存在，新的master可以在任何时候创建。你唯一需要担心的问题是新的应用程序和workers能够发现它并将它注册进来以防它成为leader master。用本地文件系统做单节点恢复zookeeper是生产环境下最好的选择，但是如果你想在master死掉后重启它，FILESYSTEM模式可以解决。当应用程序和worker注册，它们拥有足够的状态写入提供的目录，以至于在重启master进程时它们能够恢复。配置为了开启这个恢复模式，你可以用下面的属性在spark-env中设置SPARK_DAEMON_JAVA_OPTS。System propertyMeaningspark.deploy.recoveryMode设置为FILESYSTEM开启单节点恢复模式（默认为none）spark.deploy.recoveryDirectory用来恢复状态的目录细节这个解决方案可以和监控器/管理器（如monit）相配合，或者仅仅通过重启开启手动恢复。虽然文件系统的恢复似乎比没有做任何恢复要好，但对于特定的开发或实验目的，这种模式可能是次优的。特别是，通过stop-master.sh杀掉master不会清除它的恢复状态，所以，不管你何时启动一个新的master，它都将进入恢复模式。这可能使启动时间增加到1分钟。虽然它不是官方支持的方式，你也可以创建一个NFS目录作为恢复目录。如果原始的master节点完全死掉，你可以在不同的节点启动master，它可以正确的恢复之前注册的所有应用程序和workers。未来的应用程序会发现这个新的master。