Hbase备份与恢复工具Snapshot的基本概念与工作原理

本文链接：https://blog.csdn.net/2401_84183545/article/details/137849664

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

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

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

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

四、在线Snapshot备份与恢复的用法

在线Snapshot备份与恢复最常用的4个工具是snapshot、restore_snapshot、clone_snapshot以及ExportSnapshot。

1，snapshot

可以为表打一个快照，但并不涉及数据移动。例如为表’sourceTable’打一个快照’snapshotName’，可以在线完成

hbase> snapshot 'sourceTable', 'snapshotName'

2，restore_snapshot

用于恢复指定快照，恢复过程会替代原有数据，将表还原到快照点，快照点之后的所有更新将会丢失

hbase> restore_snapshot 'snapshotName'

3，clone_snapshot

可以根据快照恢复出一个新表，恢复过程不涉及数据移动，可以在秒级完成

hbase> clone_snapshot 'snapshotName', 'tableName'

4，ExportSnapshot

可以将A集群的快照数据迁移到B集群。ExportSnapshot是HDFS层面的操作，需使用MapReduce进行数据的并行迁移，因此需要在开启MapReduce的机器上进行迁移。Master和RegionServer并不参与这个过程，因此不会带来额外的内存开销以及GC开销。唯一的影响是DataNode在拷贝数据的时候需要额外的带宽以及IO负载，ExportSnapshot针对这个问题设置了参数bandwidth来限制带宽的使用。

hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot \
    -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，两阶段提交基本原理

在这里插入图片描述
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

在这里插入图片描述
步骤分别对应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、引用文件名的关系。
在这里插入图片描述
依据规则，根据LinkFile的文件名定位到引用文件所在位置，${hbaseroot}/music/5e54d8620eae123761e5290e618d556b/cf/f928e045bb1e41ecbef6fc28ec2d5712。