CheckPoint运行原理

本文深入探讨了Spark中Checkpoint的功能和重要性,包括其在优化迭代计算任务中的作用、持久化策略以及实现机制。同时,文章详细解释了如何通过设置目录进行Checkpoint操作,并介绍了Checkpoint过程中的依赖清除和Lineage变更。

这里写图片描述
一、Checkpoint到底是什么?

1,Spark在生产环境下经常会面临Tranformations的RDD非常多(例如一个Job中包含1万个RDD)或者具体Tranformation产生的RDD本身计算特别复杂和耗时(例如计算时长超过1个小时),此时我们必须考虑对计算结果数据的持久化;

2,Spark是擅长多步骤迭代,同时擅长基于Job的复用,这个时候如果能够对曾经计算的过程产生的数据进行复用,就可以极大的提升效率;

3,如果采用persist把数据放在内存中的话,虽然是最快的但是也是最不可靠的:如果放在磁盘上也不是完全可靠的!例如磁盘会损坏,管理员可能清空磁盘等;

4,Checkpoint的产生就是为了相对而言更加可靠的持久化数据,在Checkpoint可以指定把数据放在本地并且是多副本额方式,但是在正常的生产环境下是放在HDFS,这就天然借助了HDFS高容错性的高可靠的特性来完成了最大化的可靠的持久化数据的方式;

5,Checkpoint是为了最大程度保证绝对可靠的复用RDD计算数据的Spark的高级功能,通过Checkpoint我们通过把数据持久化的HDFS来保证数据最大程度的安全性;

6,Checkpoint就是针对整个RDD计算链条中特别需要数据持久化的环节(后面会反复使用当前环节的RDD)开始基于HDFS等的数据持久化复用策略,通过对RDD启动Checkpoint机制来实现容错和高可用;

二、Checkpoint原理机制:

1,通过调用SparkContext.setCheckpointDir方法来指定进行Checkpoint操作的RDD把数据放在哪里,在生产集群中是放在HDFS上的,同时为了提高效率在进行checkpoint的使用可以指定很多目录。

/**
 * Set the directory under which RDDs are going to be checkpointed. The directory must
 * be a HDFS path if running on a cluster.
 */
def setCheckpointDir(directory: String) {

  // If we are running on a cluster, log a warning if the directory is local.
  // Otherwise, the driver may attempt to reconstruct the checkpointed RDD from
  // its own local file system, which is incorrect because the checkpoint files
  // are actually on the executor machines.
  if (!isLocal && Utils.nonLocalPaths(directory).isEmpty) {
    logWarning("Checkpoint directory must be non-local " +
      "if Spark is running on a cluster: " + directory)
  }

  checkpointDir = Option(directory).map { dir =>
    val path = new Path(dir, UUID.randomUUID().toString)
    val fs = path.getFileSystem(hadoopConfiguration)
    fs.mkdirs(path)
    fs.getFileStatus(path).getPath.toString
  }
}

2,在进行RDD的checkpoint的时候其所依赖的所有的RDD都会从计算链条中清空掉;

3,作为最佳实践,一般在进行checkpoint方法调用前一般都要进行persist来把当前RDD的数据持久化到内存或者磁盘上,这是因为checkpoint是Lazy级别,必须有Job的执行且在Job执行完成后才会从后往前回溯那个RDD进行了Checkpoint标记,然后对该标记了要进行Checkpoint的RDD新启动一个Job执行具体的Checkpoint的过程;

4,Checkpoint改变了RDD的Lineage;

5,当我们调用了Checkpoint方法要对RDD进行Checkpoint操作的话,此时框架会自动生成RDDCheckpointData,当RDD上运行过一个Job后就会立即会出RDDCheckpointData中的chckpoint方法,在其内部会调用doCkeckpoint,实际上在生产环境下会调用RDDCheckpointData的doCkeckpoint,在生产环境下会导致ReliableCheckpointRDD的writeRDDToCheckpointDirectory的调用,而在writeRDDToCheckpointDirectory方法内部会触发runJob来执行把当前的RDD中的数据写到Ckeckpoint的目录中,同时会产生ReliableCheckpointRDD实例。

### Apache Flink 中 Checkpoint实现原理 #### 一、Checkpoint 基本概念 在分布式流处理框架中,Flink 的 Checkpoint 是一种用于提供容错能力的关键特性。该机制旨在确保即使遇到节点失败或其他异常情况,也能维持数据处理的一致性和准确性[^3]。 #### 二、Checkpoint 工作流程 1. **触发条件** 当满足预设的时间间隔或特定事件时,会触发一次新的 Checkpoint 操作。这可以由用户自定义设置,也可以采用系统默认配置[^1]。 2. **屏障注入** 在接收到启动信号之后,Flink 将向数据源发送特殊的 Barrier(障碍),这些 Barrier 随着数据流动贯穿整个拓扑结构中的各个算子。每当一个算子接收到Barrier 后,它就会暂停接收来自上游的新数据项直到完成当前正在处理的数据批次,并记录下此时的状态到持久化存储位置;随后继续传递此 Barrier 给下游的任务实例。 3. **状态保存** 对于每一个涉及状态管理的操作符而言,在遭遇上述提到的 Barrier 之际,它们会被迫停止进一步消费输入元素并着手将其内部维护的信息序列化成字节数组形式写入外部介质之中——比如文件系统或者数据库等支持高可用性的组件里去。值得注意的是,为了不影响正常业务逻辑运行效率以及保障事务隔离级别,这里通常会选择异步方式进行实际磁盘 I/O 操作。 4. **确认与提交** 所有参与此次快照构建过程的相关 Operator 完成本地部分工作并向 JobManager 报告成功与否的结果后,后者负责汇总统计信息并对整体进度作出评估判断。一旦所有必要的反馈均已收集完毕,则标志着本次完整的全局一致性视图已经形成,JobManager 可以安全地标记这个 Checkpoint 成功结束并将相应元数据更新至协调中心以便后续可能发生的故障恢复操作所用。 5. **并发控制** 默认情况下仅允许有一个活跃状态下的 Checkpoint 正处于执行阶段,不过可以通过调整参数 `setMaxConcurrentCheckpoints` 来改变这一行为模式,使得多个 Checkpoint 能够同时进行而不必相互阻塞等待资源释放。 ```python # 设置最大并发 Checkpoint 数量为3 env.get_checkpoint_config().set_max_concurrent_checkpoints(3) ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值