Apache Spark技术实战(一)Standalone部署模式下的临时文件清理&日志级别修改

简介: 在Standalone部署模式下,Spark运行过程中会创建哪些临时性目录及文件,这些临时目录和文件又是在什么时候被清理,本文将就这些问题做深入细致的解答;并讨论日志级别修改问题。

<一>Standalone部署模式下的临时文件清理

概要

在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进程在启动时的文件依赖如何得到满足。

1)Master进程最为简单,除了spark jar包之外,不存在第三方库依赖。
2)Driver和Executor在运行的时候都有可能存在第三方包依赖,分开来讲:
  1. Driver比较简单,spark-submit在提交的时候会指定所要依赖的jar文件从哪里读取;
  2. 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结束运行的时候呗,直觉有时不见得就是对的。

SPARK_LOCAL_DIRS下的产生的文件夹,确实会在应用程序退出的时候自动清理掉,如果观察仔细的话,还会发现在spark_local_dirs目录有有诸如*_cache和*_lock的文件,它们没有被自动清除。这是一个BUG,可以会在spark 1.3中加以更正。有关该BUG的具体描述,参考spark-4323 https://issues.apache.org/jira/browse/SPARK-4323。

$SPARK_LOCAL_DIRS下的*_cache文件是为了避免同一台机器中多个executor执行同一application时多次下载第三方依赖的问题而引进的patch,详见JIRA case spark-2713. 对就的代码见spark/util/Utils.java中的fetchFile函数。https://issues.apache.org/jira/browse/SPARK-2713。

如果已经在使用了,有什么办法来清除呢?暴力删除,不管三七二十一,过一段时间将已经存在的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。

如果Spark应用程序需要长时间运行,生成的许多shuffle output何时再清理呢?可以通过配置spark.cleaner.ttl来设置清理的时间。

实验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相关。

参考资料

  1. https://spark.apache.org/docs/1.2.0/submitting-applications.html
  2. https://spark.apache.org/docs/1.2.0/spark-standalone.html
  3. http://mail-archives.apache.org/mod_mbox/spark-commits/201410.mbox/%3C2c2ce06abc7d48d48f17f8e458a53219@git.apache.org%3E
  4. https://issues.apache.org/jira/browse/SPARK-4323
  5. https://issues.apache.org/jira/browse/SPARK-2713

<二>日志级别修改

摘要

在学习使用Spark的过程中,总是想对内部运行过程作深入的了解,其中DEBUG和TRACE级别的日志可以为我们提供详细和有用的信息,那么如何进行合理设置呢,不复杂但也绝不是将一个INFO换为TRACE那么简单。

主要问题

调整Spark日志级别的配置文件是$SPARK_HOME/conf/log4j.properties,默认级别是INFO,如果曾经将其改为DEBUG的朋友可能会有这样的经历,有用的信息还没看完,就被大量的心跳检测日志给淹没了。

解决办法

只将需要的日志级别调整为_TRACE_,而将心跳检测类的设置为_INFO_级别以上,避免干扰。

log4j.properties示范

   # Set everything to be logged to the console
   log4j.rootCategory=INFO, console
   log4j.appender.console=org.apache.log4j.ConsoleAppender
   log4j.appender.console.target=System.err
   log4j.appender.console.layout=org.apache.log4j.PatternLayout
   log4j.appender.console.layout.ConversionPattern=%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n

   # Settings to quiet third party logs that are too verbose
   log4j.logger.org.eclipse.jetty=WARN
   log4j.logger.org.eclipse.jetty.util.component.AbstractLifeCycle=ERROR
   log4j.logger.org.apache.spark.repl.SparkIMain$exprTyper=INFO
   log4j.logger.org.apache.spark.repl.SparkILoop$SparkILoopInterpreter=INFO
   log4j.logger.org.apache.spark.sql.SQLContext=TRACE
   log4j.logger.org.apache.spark.sql.catalyst.analysis.Analyzer=TRACE
   log4j.logger.org.apache.spark=TRACE
   log4j.logger.org.apache.spark.storage.BlockManagerMasterActor=WARN
   log4j.logger.org.apache.spark.HeartbeatReceiver=WARN
   log4j.logger.org.apache.spark.scheduler.local.LocalActor=WARN

小结

第一次在博客园中用markdown格式来写文章,感觉挺简单的。

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
目录
相关文章
|
存储 运维 开发工具
警惕日志采集失败的 6 大经典雷区:从本地管理反模式到 LoongCollector 标准实践
本文探讨了日志管理中的常见反模式及其潜在问题,强调科学的日志管理策略对系统可观测性的重要性。文中分析了6种反模式:copy truncate轮转导致的日志丢失或重复、NAS/OSS存储引发的采集不一致、多进程写入造成的日志混乱、创建文件空洞释放空间的风险、频繁覆盖写带来的数据完整性问题,以及使用vim编辑日志文件导致的重复采集。针对这些问题,文章提供了最佳实践建议,如使用create模式轮转日志、本地磁盘存储、单线程追加写入等方法,以降低日志采集风险,提升系统可靠性。最后总结指出,遵循这些实践可显著提高故障排查效率和系统性能。
2774 23
|
存储 运维 开发工具
警惕日志采集失败的 6 大经典雷区:从本地管理反模式到 LoongCollector 标准实践
本文总结了日志管理中的六大反模式及优化建议,涵盖日志轮转、存储选择、并发写入等常见问题,帮助提升日志采集的完整性与系统可观测性,适用于运维及开发人员优化日志管理策略。
535 5
|
分布式计算 Kubernetes Hadoop
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
1333 6
|
分布式计算 资源调度 Hadoop
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
661 2
|
SQL 数据库
【YashanDB知识库】归档日志清理
本文介绍了YashanDB中手动清理归档日志时遇到的问题及解决方法。问题源于在归档日志未备份或未同步到备机时尝试删除,导致文件仍存在。解决方案是通过调整`ARCH_CLEAN_IGNORE_MODE`参数(如设置为BOTH模式)来忽略备份和备机限制,执行归档日志清理命令(如`ALTER DATABASE DELETE ARCHIVELOG`)。同时,注意YashanDB支持自动清理功能,可通过设置上下阈值避免磁盘空间不足。相关参数可用`show parameter clean`查看。
|
SQL 分布式计算 Serverless
基于阿里云 EMR Serverless Spark 版快速搭建OSS日志分析应用
基于阿里云 EMR Serverless Spark 版快速搭建OSS日志分析应用
503 0
|
存储 Linux Docker
centos系统清理docker日志文件
通过以上方法,可以有效清理和管理CentOS系统中的Docker日志文件,防止日志文件占用过多磁盘空间。选择合适的方法取决于具体的应用场景和需求,可以结合手动清理、logrotate和调整日志驱动等多种方式,确保系统的高效运行。
1776 2
|
分布式计算 大数据 Apache
利用.NET进行大数据处理:Apache Spark与.NET for Apache Spark
【10月更文挑战第15天】随着大数据成为企业决策和技术创新的关键驱动力,Apache Spark作为高效的大数据处理引擎,广受青睐。然而,.NET开发者面临使用Spark的门槛。本文介绍.NET for Apache Spark,展示如何通过C#和F#等.NET语言,结合Spark的强大功能进行大数据处理,简化开发流程并提升效率。示例代码演示了读取CSV文件及统计分析的基本操作,突显了.NET for Apache Spark的易用性和强大功能。
627 1
|
JSON 分布式计算 大数据
大数据-85 Spark 集群 RDD创建 RDD-Action Key-Value RDD详解 RDD的文件输入输出
大数据-85 Spark 集群 RDD创建 RDD-Action Key-Value RDD详解 RDD的文件输入输出
388 1
|
存储 消息中间件 大数据
大数据-70 Kafka 高级特性 物理存储 日志存储 日志清理: 日志删除与日志压缩
大数据-70 Kafka 高级特性 物理存储 日志存储 日志清理: 日志删除与日志压缩
457 1