HBase中的快照技术-原理和实践

最新推荐文章于 2024-06-11 18:06:32 发布

九蕊梨花

最新推荐文章于 2024-06-11 18:06:32 发布

阅读量2.3k

点赞数

分类专栏： hbase

本文链接：https://blog.csdn.net/qq_41336462/article/details/82866490

版权

hbase 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

~~这都是我自己的随笔,~~有错误请指正.

用法

在hbase shell下执行

创建 snapshot 'tablename','snapshot_name'

删除 delete_snapshot 'snapshot_name'

克隆 clone_snapshot 'snapshot_name','new_tablename'

列出 list_snapshots

替换 restore_snapshot 'snapshot_name' 原表还原到快照(大概

导出(linux的shell下,没用过)

hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot snapshot_name -copy-to hdfs:///ip:端口/hbase

有啥用-------------英文版

从用户/应用程序错误中恢复
从已知的安全状态恢复/恢复。
查看以前的快照并有选择地将差异合并到生产中。
在主要应用程序升级或更改之前保存快照。
在特定时间审核和/或报告数据视图
捕获每月数据以实现合规性。
运行结束日/月/季度报告。
应用测试
测试模式或应用程序对快照中生成的数据类似的更改，然后将其丢弃。例如：拍摄快照，从快照内容（架构和数据）创建新表，并通过更改架构，添加和删除行等来操作新表。（原始表，快照和新表保持相互独立。）
卸货工作
拍摄快照，将其导出到另一个群集，然后运行MapReduce作业。由于导出快照在HDFS级别运行，因此您不会像CopyTable那样减慢主HBase群集的速度。

可能的问题

创建:在平衡,拆分(split)或合并(compaction)期间,可能失败.同一时间之内给一张表快照(A表快照中不能给A快照)

克隆:克隆得到的新表和原表可以说是两种表,互不影响,但是克隆表占用的空间很小(相比较原表)

删除:好像没遇到啥问题

导出+替换:(TODO)

官方的话

HBase 从0.95开始引入了Snapshot，可以对table进行Snapshot，也可以Restore到Snapshot。Snapshot可以在线做，也可以离线做。Snapshot的实现不涉及到table实际数据的拷贝，仅仅拷贝一些元数据，比如组成table的region info，表的descriptor，还有表对应的HFile的文件的引用。

存储原理

所以先直接看下文件夹结构,hdfs上的hbase

版本不同可能文件结构不同(应该也差不了太大)

/hbase 里面有以下三个

/.snapshot

n+1个文件夹1个 /.tmp 和n个 /snapshot_name .tmp中的文件是快照过程中生成的,最后是没有的

/archive 引用文件,表描述什么的

引用文件是本地的之外，其它文件则基本上是 export 时，来自其它集群的真实数据文件，这也是Snapshot 相关操作中唯一涉及到真实数据文件拷贝的操作。

/data 放物理表

再后面就要看看源码了,

参考地址-------看起来很美---------这个才是详细

1） Snapshot 具体是什么？它所包含文件的具体信息是什么？

Answer：Snapshot 其实是一系列文件的组合，这些文件中重要的有.snapshotinfo、.tableinfo.[xxxxxxxxxx] 、.regioninfo、 data.manifest，他们包含了对 table、region、store file 等的具体描述元信息，通过对 Snapshot 里的文件做相应的解析，可以还原备份前的 table、region、family 等信息，同时能够找到存储有实际数据信息的 store file 文件，而由于 HBase 在删除文件时，并不会真正的删除文件，而是将文件转移到 archive 目录，所以 Snapshot 始终能保证在任何时候都能还原数据。

2） Take、Clone、Restore、Delete、Export 操作的具体实现原理。

Answer：究其根本，这一系列操作其实就是对 table 以及其下面的所有数据做一个备份与还原等操作，而 Take、Clone、Restore、Delete 操作本身并不涉及到 store file 文件本身的操作，Export 因为涉及到跨集群，所以需要将数据拷贝到其它集群，而由于 HBase 基于 Hadoop 之上，文件系统基于 HDFS，而 Hadoop 实现了跨集群拷贝文件，以及其它譬如集群间通信等方法，这让 Snapshot 的这一系列操作实现变得不那么太关注底层的实现，所以相对而言其实现原理是相对容易理解的。

3）目录能改变吗？

Answer：不能！即便是 Export 操作，也只能指定其它集群的 HBase 目录位置，不能改变其内在结构。

从程序代码上讲，Snapshot 相关操作的涉及到的内部目录名称都是使用类里面的常量保存，比如

HConstants.HFILE_ARCHIVE_DIRECTORY = "archive"、HConstants.SNAPSHOT_DIR_NAME = ".hbase-snapshot" 等，所以除了改变源码，否则是没办法改变其内部目录结构的。当然，改源码使其目录结构改变是及其不理智的。

其实在做 Snapshot 分析的主要原因之一在于希望能解释 Export 为什么会将数据发送到 archive 目录，而不是直接放在 data 目录下，就这个问题来分析一下为什么不能通过改源码来改变其目录结构。

在 data 目录下的 store file 都是正在使用的，Export 只是传输过来，还没确定是否要使用啊。另外如果改成其它名称，那也没必要啊。