SparkStreming:使用Checkpoint创建StreamingContext修改executor-cores、executor-memory等资源信息不生效。

简介: 在使用SparkStreaming时,使用StreamingContext.getOrCreate(checkpointDirectory, functionToCreateContext _)创建StreamingContext。

在使用SparkStreaming时,使用StreamingContext.getOrCreate(checkpointDirectory, functionToCreateContext _)创建StreamingContext。代码示例如下:

// Function to create and setup a new StreamingContext
    def functionToCreateContext(): StreamingContext = {

      val conf = new SparkConf().setAppName("UserBrowse")
      val ssc = new StreamingContext(conf, batchInterval)

      //通过LogHubCursorPosition.BEGIN_CURSOR指定消费Cursor的模式。
      val loghubStream = LoghubUtils.createStream(...)

      loghubStream.checkpoint(batchInterval * 5).foreachRDD { rdd =>

      val spark = SparkSession.builder.config(rdd.sparkContext.getConf)
          .config("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
          .getOrCreate()
      }

      ssc.checkpoint(checkpointDirectory) // set checkpoint directory
      ssc
    }
    // Get StreamingContext from checkpoint data or create a new one
    val context = StreamingContext.getOrCreate(checkpointDirectory, functionToCreateContext _)

此时通过控制台提交Spark任务命令如下:

--class com.test.StreamingText
--jars /spark-it/loghub-spark-0.6.13_2.4.3-1.0.4.jar,/spark-it/loghub-client-lib-0.6.13.jar
--driver-memory 1G 
--driver-cores 1
--executor-cores 3 
--executor-memory 3G
--num-executors 1
--name spark_on_loghub
/spark-it/sparkstreaming-0.0.1-SNAPSHOT.jar
/tmp/checkpoint_location_test 

其中/tmp/checkpoint_location_test 为StreamingContext的checkpoint路径。
运行一段时间后,用户期望修改executor-cores为4,executor-memory 为12G,num-executors为3。那如何修改呢?
由于SparkStreming的运行机制是长久运行,以及checkpoint的设置是为了任务异常能从checkpoint恢复数据。
首次提交任务后,StremingContext会把Spark的配置信息写入到Checkpoint中,包括:executor-cores、num-executors、executor-memory等配置信息。
当任务异常或者重启后,StremingContext会从Checkpoint中读取Spark的配置信息。所以这时如果在控制台修改executor-cores、executor-memory等配置信息,StremingContext不会读取的。
如果需要修改executor-cores、executor-memory等配置信息需要清除Checkpoint路径,或者重新指定一个新的Checkpoint路径。

相关文章
|
存储 缓存 分布式计算
Spark修炼之道(进阶篇)——Spark入门到精通:第十四节 Spark Streaming 缓存、Checkpoint机制
作者:周志湖 微信号:zhouzhihubeyond 主要内容 本节内容基于官方文档:http://spark.apache.org/docs/latest/streaming-programming-guide.html Spark Stream 缓存 Checkpoint 案例 1. Spark Stream 缓存 通过前面一系列的课程介绍,我们知道DS
4967 0
|
7月前
|
人工智能 分布式计算 大数据
大数据≠大样本:基于Spark的特征降维实战(提升10倍训练效率)
本文探讨了大数据场景下降维的核心问题与解决方案,重点分析了“维度灾难”对模型性能的影响及特征冗余的陷阱。通过数学证明与实际案例,揭示高维空间中样本稀疏性问题,并提出基于Spark的分布式降维技术选型与优化策略。文章详细展示了PCA在亿级用户画像中的应用,包括数据准备、核心实现与效果评估,同时深入探讨了协方差矩阵计算与特征值分解的并行优化方法。此外,还介绍了动态维度调整、非线性特征处理及降维与其他AI技术的协同效应,为生产环境提供了最佳实践指南。最终总结出降维的本质与工程实践原则,展望未来发展方向。
392 0
|
分布式计算 大数据 Apache
ClickHouse与大数据生态集成:Spark & Flink 实战
【10月更文挑战第26天】在当今这个数据爆炸的时代,能够高效地处理和分析海量数据成为了企业和组织提升竞争力的关键。作为一款高性能的列式数据库系统,ClickHouse 在大数据分析领域展现出了卓越的能力。然而,为了充分利用ClickHouse的优势,将其与现有的大数据处理框架(如Apache Spark和Apache Flink)进行集成变得尤为重要。本文将从我个人的角度出发,探讨如何通过这些技术的结合,实现对大规模数据的实时处理和分析。
993 2
ClickHouse与大数据生态集成:Spark & Flink 实战
|
10月前
|
存储 分布式计算 Hadoop
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
511 79
|
存储 分布式计算 算法
大数据-106 Spark Graph X 计算学习 案例:1图的基本计算、2连通图算法、3寻找相同的用户
大数据-106 Spark Graph X 计算学习 案例:1图的基本计算、2连通图算法、3寻找相同的用户
274 0
|
消息中间件 分布式计算 NoSQL
大数据-104 Spark Streaming Kafka Offset Scala实现Redis管理Offset并更新
大数据-104 Spark Streaming Kafka Offset Scala实现Redis管理Offset并更新
272 0
|
消息中间件 存储 分布式计算
大数据-103 Spark Streaming Kafka Offset管理详解 Scala自定义Offset
大数据-103 Spark Streaming Kafka Offset管理详解 Scala自定义Offset
317 0
|
SQL 机器学习/深度学习 分布式计算
Spark快速上手:揭秘大数据处理的高效秘密,让你轻松应对海量数据
【10月更文挑战第25天】本文全面介绍了大数据处理框架 Spark,涵盖其基本概念、安装配置、编程模型及实际应用。Spark 是一个高效的分布式计算平台,支持批处理、实时流处理、SQL 查询和机器学习等任务。通过详细的技术综述和示例代码,帮助读者快速掌握 Spark 的核心技能。
585 6
|
存储 分布式计算 Hadoop
数据湖技术:Hadoop与Spark在大数据处理中的协同作用
【10月更文挑战第27天】在大数据时代,数据湖技术凭借其灵活性和成本效益成为企业存储和分析大规模异构数据的首选。Hadoop和Spark作为数据湖技术的核心组件,通过HDFS存储数据和Spark进行高效计算,实现了数据处理的优化。本文探讨了Hadoop与Spark的最佳实践,包括数据存储、处理、安全和可视化等方面,展示了它们在实际应用中的协同效应。
591 2
|
存储 分布式计算 Hadoop
数据湖技术:Hadoop与Spark在大数据处理中的协同作用
【10月更文挑战第26天】本文详细探讨了Hadoop与Spark在大数据处理中的协同作用,通过具体案例展示了两者的最佳实践。Hadoop的HDFS和MapReduce负责数据存储和预处理,确保高可靠性和容错性;Spark则凭借其高性能和丰富的API,进行深度分析和机器学习,实现高效的批处理和实时处理。
495 1