Spark 检查点(checkpoint)

这篇具有很好参考价值的文章主要介绍了Spark 检查点(checkpoint)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Spark 检查点(checkpoint)

什么是Checkpointing

Checkpointing可以将RDD从其依赖关系中抽出来,保存到可靠的存储系统(例如HDFS,S3等), 即它可以将数据和元数据保存到检查指向目录中。 因此,在程序发生崩溃的时候,Spark可以恢复此数据,并从停止的任何地方开始。

Checkpointing分为两类:

  • 高可用checkpointing,容错性优先。这种类型的检查点可确保数据永久存储,如存储在HDFS或其他分布式文件系统上。 这也意味着数据通常会在网络中复制,这会降低检查点的运行速度。
  • 本地checkpointing,性能优先。 RDD持久保存到执行程序中的本地文件系统。 因此,数据写得更快,但本地文件系统也不是完全可靠的,一旦数据丢失,工作将无法恢复。一般用于需要定期截取且拥有较长的lineage关系的RDD,例如,GraphX。

开发人员可以是来RDD.checkpoint()方法来设置检查点。在使用检查点之前,必须使用SparkContext.setCheckpointDir(directory: String)方法设置检查点目录。

所以其实我们的checkpoint主要用于Spark Streaming任务

为什么使用Checkpointing

RDD的检查点机制就好比Hadoop将中间计算值存储到磁盘,即使计算中出现了故障,我们也可以轻松地从中恢复。通过对 RDD 启动检查点机制可以实现容错和高可用。

  • 在Spark Streaming程序中,如果某些数据已经在队列中等待处理,由于某些原因我们的应用程序崩溃,当我们再次启动时,则无需再次读取这些数据,并且数据不会丢失。
  • 如果我们的应用程序正在使用任何有状态操作,那么检查点是必需的,否则一旦应用程序崩溃,所有状态都将丢失。

哪些RDD需要使用Checkpointing

  • 计算需要很长时间的
  • 计算链太长的
  • 依赖于太多的父RDD

Cache、Persist和Checkpoint的区别

cache()与persist()的区别

会被重复使用的但是不能太大的RDD需要cache。cache()调用了persist(),区别在于cache只有一个默认的缓存级别MEMORY_ONLY,而persist可以根据情况设置其它的缓存级别,StorageLevel类中有12种缓存级别。

cache机制是每计算出一个要cache的partition就直接将其cache到内存了。但checkpoint没有使用这种第一次计算得到就存储的方法,而是等到job结束后另外启动专门的job去完成checkpoint ,也就是说需要checkpoint的RDD会被计算两次。因此在使用rdd.checkpoint()的时候建议加上rdd.cache(),这样第二次运行的 job 就不用再去计算该rdd了,直接读取cache写磁盘。

persist()与checkpoint()的区别

rdd.persist(StorageLevel.DISK_ONLY) 与 checkpoint 也有区别。前者虽然可以将RDD的partition持久化到磁盘,但该partition由blockManager管理。一旦driver program执行结束,也就是executor所在进程CoarseGrainedExecutorBackend结束了,blockManager也会相应退出,被 cache 到磁盘上的 RDD 也会被清空,整个blockManager使用的local文件夹被删除。

而checkpoint将RDD持久化到HDFS或本地文件夹,如果不被手动remove掉,是一直存在的,也就是说可以被下一个driver program使用,而cached RDD不能被其他dirver program使用。

建立CheckPointing示例

用sparkContext设置hdfs的checkpoint的目录。

scala> sc.setCheckpointDir("hdfs:/tmp/checkpoint")

利用上面代码建立好检查点目录后,hdfs的会出现类似下面的目录。

[dev@test06 ~]$ hdfs dfs -ls /tmp/checkpoint
Found 1 items
drwxr-xr-x   - hadoop supergroup          0 2019-04-30 10:50 /tmp/checkpoint/b4282eb3-cde8-489b-afda-4f1d08b9c236

执行检查点

scala> val rdd1=sc.parallelize(1 to 1000)
rdd1: org.apache.spark.rdd.RDD[Int] = ParallelCollectionRDD[11] at parallelize at <console>:24
scala> rdd1.checkpoint

这个时候在hdfs的/tmp/checkpoint/b4282eb3-cde8-489b-afda-4f1d08b9c236这个目录下是找不到任何数据的。但是通过collect后,这个目录就有数据了,说明checkpoint也是个transformation的算子。

scala> rdd1.sum
res6: Double = 500500.0

[dev@test06 ~]$ hdfs dfs -ls /tmp/checkpoint/b4282eb3-cde8-489b-afda-4f1d08b9c236
Found 1 items
drwxr-xr-x   - ccpgdev supergroup          0 2019-04-30 10:57 /tmp/checkpoint/b4282eb3-cde8-489b-afda-4f1d08b9c236/rdd-11

像上面说的,由于对RDD设置检查点的时候,需要对RDD进行两次计算,所以建议在设置checkpointing之前,先对rdd调用cache()进行缓存起来,避免重复计算同一个rdd。文章来源地址https://www.toymoban.com/news/detail-859355.html

scala> rdd1.cache()
res8: rdd1.type = ParallelCollectionRDD[11] at parallelize at <console>:24
scala> rdd1.checkpoint()
scala> rdd1.collect()
res10: Array[Int] = Array(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176,...
scala>

到了这里,关于Spark 检查点(checkpoint)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Flink】Flink 记录一个 checkpoint 检查点 越来越大的问题

    Flink SQL checkpoint越来越大咋么办,从2个G,现在4个G了,增量同步的,窗口是1小时,watermark是6小时,按道理来说,数据量不应该越来越大啊? 在窗口内执行了count(distinct )这些操作。设置了状态的ttl。后端状态存储用的rocksdb。 状态如下 设置了增量的检查点 代码设置不一定有

    2024年02月10日
    浏览(47)
  • Flink任务失败,检查点失效:Exceeded checkpoint tolerable failure threshold.

    最近实时平台flink任务频繁失败,报检查点方面的错误,最近集群的hdfs也经常报警:运行状况不良,不知道是否和该情况有关,我的状态后端位置是hdfs,废话不多说,干货搞起来~ 日志中报错如下: 在报 Exceeded checkpoint tolerable failure threshold. 错误的之前,是先报的是 Checkpoi

    2024年02月07日
    浏览(78)
  • Flink 检查点配置

    开启自动保存快照 (默认:关闭) : 间隔调整 : 对性能的影响更小,就调大间隔时间 为了更好的容错性,就以调小间隔时间 检查点存储 (CheckpointStorage) : 持久化存储位置 JobManager 的堆内存 (JobManagerCheckpointStorage) : 默认 文件系统 (FileSystemCheckpointStorage) : 常用 , (HDFS , S3) Rocksdb 状

    2024年02月10日
    浏览(54)
  • loadrunner入门教程(14)--检查点

    检查点函数原理:回放脚本时搜索特定的文本或者字符串,从而验证服务器相应的正确性;验证请求是否成功,可以添加检查点。以检查从服务器返回的内容是否正确。本任务针对脚本开发–检查点进行介绍 掌握基于loadrunner性能测试脚本开发——检查点 1.单击Design→Insert

    2024年02月05日
    浏览(61)
  • 深入了解 Flink 的检查点机制

    Flink 是一个流处理框架,用于实时数据处理。检查点(checkpoint)机制是 Flink 的一个核心组件,用于保证流处理作业的可靠性和容错性。在这篇文章中,我们将深入了解 Flink 的检查点机制,涵盖其核心概念、算法原理、实例代码以及未来发展趋势。 Flink 的检查点机制是一种保存

    2024年02月20日
    浏览(35)
  • Flink状态管理与检查点机制

    本专栏案例代码和数据集链接:  https://download.csdn.net/download/shangjg03/88477960 相对于其他流计算框架,Flink 一个比较重要的特性就是其支持有状态计算。即你可以将中间的计算结果进行保存,并提供给后续的计算使用: 具体而言,Flink 又将状态 (State) 分为 Keyed State 与 O

    2024年02月07日
    浏览(44)
  • 怎么理解flink的异步检查点机制

    flink的checkpoint监控页面那里有两个指标Sync Duration 和Async Duration,一个是开始进行同步checkpoint所需的时间,一个是异步checkpoint过程所需的时间,你是否也有过疑惑,是否只是同步过程中的时间才会阻塞正常的数据处理,而异步checkpoint的时间不会影响正常的数据处理流程? 这

    2024年02月09日
    浏览(57)
  • Flink流式计算状态检查点与恢复

    Flink流式计算状态检查点与恢复 Apache Flink是一个流处理框架,用于实时数据处理和分析。Flink可以处理大规模数据流,并提供一种高效、可靠的方法来处理和分析这些数据。Flink流式计算状态检查点与恢复是流处理的关键组件,它们确保Flink应用程序在故障时能够恢复并继续处

    2024年02月19日
    浏览(41)
  • Flink系列之:背压下的检查点

    通常情况下,对齐 Checkpoint 的时长主要受 Checkpointing 过程中的同步和异步两个部分的影响。 然而,当 Flink 作业正运行在严重的背压下时,Checkpoint 端到端延迟的主要影响因子将会是传递 Checkpoint Barrier 到 所有的算子/子任务的时间。这在 checkpointing process) 的概述中有说明原因

    2024年02月04日
    浏览(41)
  • 论文阅读-多级检查点重新启动MPI应用的共同设计

    论文名称: Co-Designing Multi-Level Checkpoint Restart for MPI Applications 摘要—高性能计算(HPC)系统继续通过包含更多硬件组件来支持更大的应用部署来扩展。关键是,这种扩展往往会减少故障之间的平均时间,从而使容错成为一个越来越重要的挑战。在HPC中容错的标准做法是检查点

    2024年04月09日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包