Hbase备份与恢复工具Snapshot的基本概念与工作原理_hbase 快照恢复(1)

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

-snapshot MySnapshot -copy-from hdfs:// srv2:8082/hbase \    
-copy-to hdfs:// srv1:50070/hbase -mappers 16 -bandwidth  1024

## 五、在线Snapshot的分布式架构——两阶段提交


HBase为指定表执行Snapshot操作，实际上真正执行Snapshot的是对应表的所有Region。这些Region分布在多个RegionServer上，因此需要一种机制来保证所有参与执行Snapshot的Region要么全部完成，要么都没有开始做，不能出现中间状态，比如某些Region完成了，而某些Region未完成。


### 1， 两阶段提交基本原理


![在这里插入图片描述](https://img-blog.csdnimg.cn/0006a8e7cc9a402793aa12cf59fdcea4.png)  
 HBase使用两阶段提交（Two-Phase Commit，2PC）协议来保证Snapshot的分布式原子性。2PC一般由一个协调者和多个参与者组成，整个事务提交分为两个阶段：prepare阶段和commit阶段（或abort阶段）。


整个过程：  
 （1）prepare阶段协调者会向所有参与者发送prepare命令。  
 （2）所有参与者接收到命令，获取相应资源（比如锁资源），执行prepare操作确认可以执行成功。一般情况下，核心工作都是在prepare操作中完成。  
 （3）返回给协调者prepared应答。  
 （4）协调者接收到所有参与者返回的prepared应答（表明所有参与者都已经准备好提交），在本地持久化committed状态。  
 （5）持久化完成之后进入commit阶段，协调者会向所有参与者发送commit命令。  
 （6）参与者接收到commit命令，执行commit操作并释放资源，通常commit操作都非常简单。  
 （7）返回给协调者。


### 2，Snapshot两阶段提交实现


HBase使用2PC协议来构建Snapshot架构。


### 1，prepare阶段


（1）Master在ZooKeeper创建一个/acquired-snapshotname节点，并在此节点上写入Snapshot相关信息（Snapshot表信息）。  
 （2）所有RegionServer监测到这个节点，根据/acquired-snapshotname节点携带的Snapshot表信息查看当前RegionServer上是否存在目标表，如果不存在，就忽略该命令。如果存在，遍历目标表中的所有Region，针对每个Region分别执行Snapshot操作，注意此处Snapshot操作的结果并没有写入最终文件夹，而是写入临时文件夹。  
 （3）RegionServer执行完成之后会在/acquired-snapshotname节点下新建一个子节点/acquired-snapshotname/nodex，表示nodex节点完成了该RegionServer上所有相关Region的Snapshot准备工作。


### 2，commit阶段


（1）一旦所有RegionServer都完成了Snapshot的prepared工作，即都在/acquired-snapshotname节点下新建了对应子节点，Master就认为Snapshot的准备工作完全完成。Master会新建一个新的节点/reached-snapshotname，表示发送一个commit命令给参与的RegionServer。  
 （2）所有RegionServer监测到/reached-snapshotname节点之后，执行commit操作。commit操作非常简单，只需要将prepare阶段生成的结果从临时文件夹移动到最终文件夹即可。  
 （3）在/reached-snapshotname节点下新建子节点/reached-snapshotname/nodex，表示节点nodex完成Snapshot工作。


### 3，abort阶段


如果在一定时间内/acquired-snapshotname节点个数没有满足条件（还有RegionServer的准备工作没有完成），Master认为Snapshot的准备工作超时。Master会新建另一新节点/abort-snapshotname，所有RegionServer监听到这个命令之后会清理Snapshot在临时文件夹中生成的结果。  
 可以看到，在这个系统中Master充当了协调者的角色，RegionServer充当了参与者的角色。Master和RegionServer之间的通信通过ZooKeeper来完成，同时，事务状态也记录在ZooKeeper的节点上。Master高可用情况下主Master发生宕机，从Master切换成主后，会根据ZooKeeper上的状态决定事务是否继续提交或者回滚。


## 六、Snapshot核心实现


### 1，Region实现Snapshot


![在这里插入图片描述](https://img-blog.csdnimg.cn/cf67bd97c45d45ce87a803e5372c31bf.png)  
 步骤分别对应debug日志中如下片段：

Snapshot.FlushSnapshotSubprocedure: Flush Snapshotting region yixin:yunxin,user1359,1502949275629.77f4ac61c4db0be9075669726f3b72e6. started…
snapshot.SnapshotManifest: Storing ‘yixin:yunxin,user1359,1502949275629.77f4ac61c4db0be9075669726f3b72e6.’ region-info for snapshot.
snapshot.SnapshotManifest: Creating references for hfiles
snapshot.SnapshotManifest: Adding snapshot references for [] hfiles

Region生成的Snapshot文件是临时文件，在/hbase/.hbase-snapshot/.tmp目录下，因为Snapshot过程通常特别快，所以很难看到单个Region生成的Snapshot文件。


### 2，Master汇总所有Region Snapshot的结果


Master会在所有Region完成Snapshot之后执行一个汇总操作（consolidate），将所有region snapshot manifest汇总成一个单独manifest，汇总后的Snapshot文件可以在HDFS目录下看到的，路径为：/hbase/.hbase-snapshot/snapshotname/data.manifest。


Snapshot目录下有3个文件：

hadoop@hbase19:~/cluster-data/hbase/logs$ ./hdfs dfs -ls /hbase/.hbase-snapshot/music_snapsho
Found 3 items

-rw-r–r-- 3 hadoop hadoop 0 2017-08-18 17:47 /hbase/.hbase-snapshot/music_snapshot/.inprogress
-rw-r–r-- 3 hadoop hadoop 34 2017-08-18 17:47 /hbase/.hbase-snapshot/music_snapshot/.snapshotinfo
-rw-r–r-- 3 hadoop hadoop 34 2017-08-18 17:47 /hbase/.hbase-snapshot/music_snapshot/data.manifest

其中.snapshotinfo为Snapshot基本信息，包含待Snapshot的表名称以及Snapshot名。data.manifest为Snapshot执行后生成的元数据信息，即Snapshot结果信息。可以使用hadoop dfs-cat/hbase/.hbase-snapshot/snapshotname/data.manifest查看具体的元数据信息。


## 七、Snapshot恢复


Snapshot可以实现很多功能，比如restore\_snapshot可以将当前表恢复到备份的时间点，clone\_snapshot可以使用快照恢复出一个新表，ExportSnapshot可以将备份导出到另一个集群实现数据迁移等。


clone\_snapshot可以概括为如下六步：  
 （1）预检查。确认当前目标表没有执行snapshot以及restore等操作，否则直接返回错误。  
 （2）在tmp文件夹下新建目标表目录并在表目录下新建.tabledesc文件，在该文件中写入表schema信息。  
 （3）新建region目录。根据snapshot manifest中的信息新建Region相关目录以及HFile文件。  
 （4）将表目录从tmp文件夹下移到HBase Root Location。  
 （5）修改hbase：meta表，将克隆表的Region信息添加到hbase：meta表中，注意克隆表的Region名称和原数据表的Region名称并不相同（Region名称与table名称相关，table名不同，Region名则肯定不同）。  
 （6）将这些Region通过round-robin方式均匀分配到整个集群中，并在ZooKeeper上将克隆表的状态设置为enabled，正式对外提供服务。


在实现中HBase借鉴了类似于Linux系统中软链接的概念，使用一种名为LinkFile的文件指向了原文件。LinkFile文件本身没有任何内容，它的所有核心信息都包含在它的文件名中。LinkFile的命名方式为’table=region-origin\_hfile’，通过这种方式就可以很容易定位到原始文件的具体路径：/${hbase-root}/table/region/origin\_hfile。所有针对新表的读取操作都会转发到原始表执行，因此就不需要移动数据了。


示例：

hadoop@hbase19:~/hbase-current/bin ./hdfs dfs
-ls /hbase/data/default/music/fec3584ec3ea8766ffda5cb8ed0d7/cf
Found 1 items
-rw-r-r-r- - 3 hadoop hadoop 0 2017-08-23 07:27 /hbase/data/default/music/fec3584ec3ea8766ffda5cb8ed0d7/cf/music=5e54d8620eae123761e5290e618d556b-f928e045bb1e41ecbef6fc28ec2d571

其中，LinkFile文件名为music=5e54d8620eae123761e5290e618d556b-f928e045bb1e41ecbef6fc28ec2d5712，根据定义可以知道，music为原始文件的表名，与引用文件所在的Region、引用文件名的关系。  
 ![在这里插入图片描述](https://img-blog.csdnimg.cn/32ccb2f881f744fe8178141b536914e1.png)  
 依据规则，根据LinkFile的文件名定位到引用文件所在位置，${hbaseroot}/music/5e54d8620eae123761e5290e618d556b/cf/f928e045bb1e41ecbef6fc28ec2d5712。


## 九、Snapshot进阶-在线Snapshot原理深入解析


Snapshot实际上是一系列原始表的元数据，主要包括表schema信息、原始表所有Region的region info信息、Region包含的列簇信息，以及Region下所有的HFile文件名、文件大小等。  
 HBase的实现方案比较简单，在原始表发生Compaction操作前会将原始表数据复制到archive目录下再执行compact（对于表删除操作，正常情况也会将删除表数据移动到archive目录下），这样Snapshot对应的元数据就不会失去意义，只不过原始数据不再存在于数据目录下，而是移动到了archive目录下。


示例：  
 1）使用Snapshot工具给一张表做快照：snapshot’test’，‘test\_snapshot’。  
 2）查看archive目录，确认不存在这个目录：hbase-root-dir/archive/data/default/test。  
 3）对表test执行major\_compact操作：major\_compact’test’。  
 4）再次查看archive目录，就会发现test原始表移动到了该目录，/hbase-root-dir/archive/data/default/test存在。  
 同理，如果对原始表执行delete操作，比如delete’test’，也会在archive目录下找到该目录。这里需要注意的是，和普通表删除的情况不同，普通表一旦删除，刚开始是可以在archive中看到删除表的数据文件，但是等待一段时间后archive中的数据就会被彻底删除，再也无法找回。这是因为Master上会启动一个定期清理archive中垃圾文件的线程（HFileCleaner），定期对这些被删除的垃圾文件进行清理。但是Snapshot原始表被删除之后进入archive，并不可以被定期清理掉，上节说过clone出来的新表并没有clone真正的文件，而是生成了指向原始文件的链接，这类文件称为LinkFile，很显然，只要LinkFile还指向这些原始文件，它们就不可以被删除。


注意有两个问题：  
 （1）什么时候LinkFile会变成真实的数据文件？HBase会在新表执行compact的时候将合并后的文件写到新目录并将相关的LinkFile删除，理论上讲是借着compact顺便做了这件事。  
 （2）系统在删除archive中原始表文件的时候怎么知道这些文件还被LinkFile引用着？HBase使用back-reference机制完成这件事情。HBase会在archive目录下生成一种新的back-reference文件，来帮助原始表文件找到引用文件。


back-reference文件：  
 （1）原始文件：/hbase/data/table-x/region-x/cf/file-x。  
 （2）clone生成的LinkFile：/hbase/data/table-cloned/region-y/cf/{table-x}={region-x}-{file-x}。  
 （3）back-reference文件：/hbase/archive/data/table-x/region-x/cf/.links-{file-x}/{region-y}.{table-cloned}。  
 back-reference文件路径前半部分是原文件信息，后半部分是新文件信息.  
 ![在这里插入图片描述](https://img-blog.csdnimg.cn/183e61cba182496bbc15fcbce130227e.png)  
 back-reference文件第一部分表示该文件所在目录为{hbase-root}/archive/data。第二部分表示原文件路径，其中非常重要的子目录是.links-{file-x}，用来标识该路径下的文件为back-reference文件。这部分路径实际上只需要将原始文件路径（/table-x/region-x/cf/file-x）中的文件名file-x改为.link-file-x。第三部分表示新文件路径，新文件的文件名可以根据原文件得到，因此只需要得到新文件所在的表和Region即可，可以用{region-y}.{table-cloned}表征。  
 可见，在删除原文件的时候，只需要简单地拼接就可以得到back-reference目录，查看该目录下是否有文件就可以判断原文件是否还被LinkFile引用，进一步决定是否可以删除。



> 
> 文章来源：《HBase原理与实践》 作者：胡争；范欣欣
> 
> 
> 



> 
> 文章内容仅供学习交流，如有侵犯，联系删除哦！
> 
> 
> 








![img](https://img-blog.csdnimg.cn/img_convert/cc5699d611405d73ef8c4f40b1a8ab26.png)
![img](https://img-blog.csdnimg.cn/img_convert/5ea1fbfcad252fec9a61edc232f10fa2.png)
![img](https://img-blog.csdnimg.cn/img_convert/41c4c9af960d7a5f94e5b0bc567bdb4c.png)

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！**

**由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

**[需要这份系统化资料的朋友，可以戳这里获取](https://bbs.csdn.net/topics/618545628)**

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！**

**由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

**[需要这份系统化资料的朋友，可以戳这里获取](https://bbs.csdn.net/topics/618545628)**