本帖最后由 pig2 于 2015-3-9 02:43 编辑
问题导读
1.在Standalone部署模式下,Spark运行过程中会创建哪些临时性目录及文件?
2.在Standalone部署模式下分为几种模式?
3.在client模式和cluster模式下有什么不同?
概要 在Standalone部署模式下,Spark运行过程中会创建哪些临时性目录及文件,这些临时目录和文件又是在什么时候被清理,本文将就这些问题做深入细致的解答。
从资源使用的方面来看,一个进程运行期间会利用到这四个方面的资源,分别是CPU,内存,磁盘和网络。进程退出之后,CPU,内存和网络都会由操作系统负责释放掉,但是运行过程中产生临时文件如果进程自己不在退出之前有效清除,就会留下一地鸡毛,浪费有效的存储空间。
部署时的第三方依赖
再提出具体的疑问之前,先回顾一下standalone的部署模式
在standalone下又分为client模式和cluster模式,其中client模式下,driver和client运行于同一JVM中,不由worker启动,该JVM进程直到spark application计算完成返回结果后才退出。如下图所示。
而在cluster模式下,driver由worker启动,client在确认spark application成功提交给cluster后直接退出,并不等待spark application运行结果返回。如下图所示
从部署图来进行分析,每个JVM进程在启动时的文件依赖如何得到满足。
Master进程最为简单,除了spark jar包之外,不存在第三方库依赖 Driver和Executor在运行的时候都有可能存在第三方包依赖,分开来讲
Driver比较简单,spark-submit在提交的时候会指定所要依赖的jar文件从哪里读取 Executor由worker来启动,worker需要下载Executor启动时所需要的jar文件,那么从哪里下载呢。
为了解决Executor启动时依赖的Jar问题,Driver在启动的时候要启动HttpFileServer存储第三方jar包,然后由worker从HttpFileServer来获取。为此HttpFileServer需要创建相应的目录,而Worker也需要创建相应的目录。
HttpFileServer创建目录的过程详见于SparkEnv.scala中create函数。
spark会为每一个提交的application生成一个文件夹,默认位于$SPARK_HOME/work目录下,用以存放从HttpFileServer下载下来的第三方库依赖及Executor运行时生成的日志信息。
实验1 运行spark-shell,查看在/tmp目录下会新产生哪些目录。
#$SPARK_HOME/bin/spark-shell
在/tmp目录下会新增四个与spark-shell相关的文件夹
spark+随机数目录
分别用于driver本身,driver创建的tmp目录,httpfileserver创建的目录
spark-local目录
用以存放executor执行过程中生成的shuffle output和cache的内容
运行中的临时文件 Executor在运行的时候,会生成Shuffle Output,如果对RDD进行Cache的话,还有可能会将RDD的内容吐到磁盘中。这些都意味着需要有一个文件夹来容纳这些东西。
上文中提到的形如spark-local-*的目录就是用以存储executor运行时生成的临时文件。
可以通过两个简单的实验来看spark-local-*目录下内容的变化。
实验2:不进行RDD Cache
进入spark-shell之后运行
spark-shell>sc.textFile(“README.md”).flatMap(l=>l.split(“ “)).map(w=>(w,1)).reduceByKey(_ + _).foreach(println) 复制代码
上述指令会生成两个不同的Stage, 所以会有Shuffle Output,具体划分原因就不再细述了。
如果使用的是spark 1.2.x,可以看到有在spark-local-*目录下有index文件生成。
实验3: 进行RDD Cache 进入spark-shell之后运行
spark-shell>val rdd1 = sc.textFile(“README.md”).flatMap(l=>l.split(“ “)).map(w=>(w,1)).reduceByKey(_ + _)
spark-shell> rdd1.persist(MEMORY_AND_DISK_SER)
spark-shell>rdd1.foreach(println) 复制代码
上述指令执行后,不仅会有index文件还会有形如rdd*的文件生成,这些rdd打头的文件就是cache内容。
配置项 可以通过在$SPARK_HOME/conf/spark-env.sh中指定配置内容来更改默认的存储位置。
SPARK_WORK_DIR 指定work目录,默认是$SPARK_HOME/work子目录
SPARK_LOCAL_DIRS 指定executor运行生成的临时文件目录,默认是/tmp,由于/tmp目录有可能是采用了tmpfs,建议在实际部署中将其更改到其它目录
文件的清理 上述过程中生成的临时文件在什么时候会被删除掉呢?
也许第一感觉就是spark application结束运行的时候呗,直觉有时不见得就是对的。
如果已经在使用了,有什么办法来清除呢?暴力删除,不管三七二十一,过一段时间将已经存在的cache和lock全部删除。这不会有什么副作用,大不了executor再去下载一次罢了
find $SPARK_LOCAL_DIRS -max-depth 1 -type f -mtime 1 -exec rm -- {} \; 复制代码
而SPARK_WORK_DIR目录下的形如app-timestamp-seqid的文件夹默认不会自动清除。
那么可以设置哪些选项来自动清除已经停止运行的application的文件夹呢?当然有。
在spark-env.sh中加入如下内容
SPARK_WORKER_OPTS=”-Dspark.worker.cleanup.enabled=true” 复制代码
注意官方文档中说不管程序是否已经停止,都会删除文件夹,这是不准确的,只有停止掉的程序文件夹才会被删除,我已提交相应的PR.
实验4 写一个简单的WordCount,然后以Standalone Cluster模式提交运行,察看$SPARK_LOCAL_DIRS下文件内容的变化。
import org.apache.spark._
import org.apache.spark.{SparkConf, SparkContext}
import org.apache.spark.SparkContext._
import java.util.Date
object HelloApp {
def main(args: Array[String]): Unit = {
val conf = new SparkConf()
val sc = new SparkContext()
val fileName = "$SPARK_HOME/README.md"
val rdd1 = sc.textFile(fileName).flatMap(l => l.split(" ")).map(w => (w, 1))
rdd1.reduceByKey(_ + _).foreach(println)
var i: Int = 0
while ( i < 10 ) {
Thread.sleep(10000)
i = i + 1
}
}
} 复制代码
提交运行
spark-submit –class HelloApp –master spark://127.0.0.1:7077 --deploy-mode cluster HelloApp.jar 复制代码
小结 本文通过几个简单易行的实验来观测standalone模式下临时文件的产生和清除,希望有助于理解spark中磁盘资源的申请和释放过程。
Spark部署时相关的配置项比较多,如果先进行分类,然后再去配置会容易许多,分类有CPU、Memory、Network、Security、Disk及Akka相关。
相关文章
Spark技术实战之1 -- KafkaWordCount
http://www.aboutyun.com/thread-9580-1-1.html
Spark技术实战之2 -- Spark Cassandra Connector的安装和使用
http://www.aboutyun.com/thread-9582-1-1.html
Spark技术实战之3 -- 利用Spark将json文件导入Cassandra
http://www.aboutyun.com/thread-9583-1-1.html
Apache Spark技术实战之4 -- SparkR的安装及使用
http://www.aboutyun.com/thread-10082-1-1.html
Apache Spark技术实战之5 -- spark-submit常见问题及其解决
http://www.aboutyun.com/thread-10083-1-1.html
Apache Spark技术实战之6 --Standalone部署模式下的临时文件清理
http://www.aboutyun.com/thread-11862-1-1.html
http://www.tuicool.com/articles/RV3MFz