066 基于checkpoint的HA机制实现

Spark Streaming HA机制详解
本文详细介绍了Spark Streaming中高可用性的实现机制,包括基于checkpoint的数据恢复流程和注意事项。此外,还提供了一个完整的代码示例,展示了如何配置Spark Streaming应用程序以支持HA特性。

1.说明

  针对需要恢复的应用场景,提供了HA的的机制

  内部实现原理:基于checkpoint的

  当程序被kill的时候,下次恢复的时候,会从checkpoint对用的文件中进行数据的恢复

 

2.HA原理

  当job执行的时候,将数据同步到checkpoint设置的对应文件夹中
  同步的数据包括:
    类的信息(包名 + 类名)
    Job DAG执行图(在运行后,代码的DAG图不能进行任何修改,否则下次执行的时候会报错<类型不匹配>; 只要DAG图不变,其它API内部的代码执行逻辑可以随便更改)
  Job执行的源数据

 

二:程序

1.程序

 1 package com.stream.it
 2 
 3 import kafka.serializer.StringDecoder
 4 import org.apache.spark.storage.StorageLevel
 5 import org.apache.spark.streaming.kafka.KafkaUtils
 6 import org.apache.spark.streaming.{Seconds, StreamingContext}
 7 import org.apache.spark.{SparkConf, SparkContext}
 8 
 9 object HAKafkaWordcount {
10   def main(args: Array[String]): Unit = {
11     val conf=new SparkConf()
12         .setAppName("spark-streaming-wordcount")
13           .setMaster("local[*]")
14     val sc=SparkContext.getOrCreate(conf)
15     val checkpointDir = "hdfs://linux-hadoop01.ibeifeng.com:8020/beifeng/spark/streaming/chkdir02"
16 
17 
18     /**
19       * 构造StreamingContext对象
20       *
21       * @return
22       */
23     def createStreamingContextFunc(): StreamingContext = {
24       val ssc = new StreamingContext(sc, Seconds(5))
25       ssc.checkpoint(checkpointDir)
26       val kafkaParams=Map("group.id"->"stream-sparking-0",
27         "zookeeper.connect"->"linux-hadoop01.ibeifeng.com:2181/kafka",
28         "auto.offset.reset"->"smallest"
29       )
30       val topics=Map("beifeng"->1)
31       val dStream=KafkaUtils.createStream[String,String,StringDecoder,StringDecoder](
32         ssc,             //给定sparkStreaming的上下文
33         kafkaParams,     //kafka的参数信息,通过kafka HightLevelComsumerApi连接
34         topics,          //给定读取对应的topic的名称以及读取数据的线程数量
35         StorageLevel.MEMORY_AND_DISK_2     //数据接收器接收到kafka的数据后的保存级别
36       ).map(_._2)
37 
38 
39       val resultWordcount=dStream
40         .filter(line=>line.nonEmpty)
41         .flatMap(line=>line.split(" ").map((_,1)))
42         .reduceByKey(_+_)
43       resultWordcount.foreachRDD(rdd=>{
44         rdd.foreachPartition(iter=>iter.foreach(println))
45       })
46       ssc
47     }
48 
49     val ssc = StreamingContext.getOrCreate(
50       checkpointPath = checkpointDir,
51       creatingFunc = createStreamingContextFunc
52     )
53 
54     //启动
55     ssc.start()
56     //等到
57     ssc.awaitTermination()
58   }
59 }

 

2.注意点

  HA第一次执行后,以后如果代码进行改动(创建StreamingContext的代码改动),不会得到反应(会直接从checkpoint中读取数据进行StreamingContext的恢复) ===> 解决SparkStreaming和Kafka集成的时候offset偏移量管理的问题

<think>好的,我需要详细解答用户在HDFS高可用性(HA)架构下元数据的持久化过程。首先,我需要回忆一下HDFS HA的基本架构。根据引用[3],Hadoop 2.x的HDFS架构采用了主备NameNode的设计,通过JournalNodes(JNs)实现元数据的共享存储。 用户的问题是关于元数据的持久化过程,所以需要重点放在FsImage和EditLog的处理上。根据引用[4],在HA模式下,Active NameNode会将元数据的修改写入内存中的FsImage缓存,并追加EditLog到共享存储系统。这里需要明确共享存储系统是JournalNodes,如引用[5]提到的QJM(Quorum Journal Manager)。 接下来,要详细描述持久化的步骤。首先是EditLog的写入:Active NN将操作日志写入JournalNodes集群,需要满足大多数节点(比如3个中的2个)确认才能视为成功,这涉及QJM的写过程,如引用[3]和[5]所述。然后是Checkpoint过程,Standby NN定期合并FsImage和EditLog,生成新的FsImage,并上传到共享存储,确保元数据可以恢复。这部分可能需要结合引用[4]中提到的FsImage更新机制。 还需要提到主备切换时的数据同步,比如在故障转移时,如何保证EditLog的一致性,引用[5]提到类似HDFS append的recover lease过程,确保日志同步和finalized状态。 另外,用户可能关心持久化的可靠性和一致性,需要强调QJM的多数确认机制防止数据丢失,以及Standby NN的角色在Checkpoint中的作用。引用[1]中提到主备切换涉及一致性算法,但这里可能不需要深入,重点在元数据持久化流程。 最后,检查是否需要补充其他细节,比如Zookeeper在故障检测中的作用,但根据提供的引用,主要信息集中在JournalNodes和QJM,所以可能不需要扩展ZK部分。确保回答结构清晰,分步骤说明,并引用正确的来源。</think>### HDFS HA架构下元数据持久化过程详解 在HDFS HA(高可用性)架构中,元数据的持久化过程通过**主备NameNode(NN)**和**共享存储系统**(如基于QJM的JournalNodes)协同完成,确保元数据的一致性和可恢复性[^3][^5]。以下是详细步骤: --- #### **1. EditLog的写入与同步** - **Active NN的日志写入** 当客户端对HDFS进行写操作时,Active NN会将元数据修改记录为**EditLog**,并通过**QJM(Quorum Journal Manager)**将EditLog**同步写入JournalNodes集群**(通常由奇数个节点组成,如3个)。 - **写入规则**:Active NN需确保EditLog成功写入**半数以上(Quorum)**的JournalNodes(例如3个节点需至少2个确认),才视为提交成功[^3][^5]。 - **日志分段**:EditLog以**分段(Segment)**形式存储,每个分段有唯一的事务ID(Transaction ID),便于主备NN同步和恢复[^5]。 - **Standby NN的日志拉取** Standby NN会**实时从JournalNodes拉取EditLog**,并在内存中重放这些操作,保持与Active NN的元数据一致[^3][^4]。 --- #### **2. FsImage的生成与持久化** - **Checkpoint机制** - **触发条件**:当EditLog积累到一定数量或达到时间阈值(默认1小时),Standby NN会触发**Checkpoint**,将内存中的元数据(FsImage)与EditLog合并,生成新的FsImage。 - **上传FsImage**:新生成的FsImage会被上传到**共享存储**(如HDFS自身或NAS),并通知JournalNodes清理已合并的EditLog[^3][^4]。 - **主备协作** Active NN也会定期将EditLog合并到FsImage,但HA模式下主要由Standby NN承担此任务,以减少Active NN的负载[^4]。 --- #### **3. 主备切换时的数据一致性** - **故障检测与切换** 通过ZooKeeper监控Active NN状态。若Active NN故障,Standby NN会确保所有未应用的EditLog已从JournalNodes完全同步,然后提升为Active状态[^3][^5]。 - **Finalized状态同步** 切换时,JournalNodes会确保所有EditLog处于**finalized( finalized segment)**状态,避免日志文件被意外修改[^5]。 --- #### **4. 关键组件与机制** - **QJM的容错性** JournalNodes基于Paxos-like算法实现数据一致性,即使部分节点故障,仍能通过多数节点保证日志完整性[^3][^5]。 - **共享存储的高可用** FsImage和EditLog存储在共享存储(如HDFS),确保主备NN均可访问,且数据冗余可靠[^3]。 --- ### 总结流程图 ``` 客户端操作 → Active NN写入EditLog → JournalNodes同步(Quorum确认) → Standby NN拉取EditLog并重放 → 触发Checkpoint生成FsImage → FsImage上传至共享存储 → 主备切换时确保日志Finalized和一致性 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值