在之前的版本 备份或者克隆表的唯一方式就是使用MapReduce扫描&复制表
这样对所有Online RegionServer都会造成影响。
相比之下HBase快照不拷贝数据直接克隆一张表，这对Region Server产生影响最小。
将快照导出至其他集群不会直接影响到任何域服务器；导出只是带有一些额外逻辑的群间数据同步。
快照就是一份元信息的合集，允许管理员恢复到表的先前状态。
快照不是表的复制而是一个文件名称列表，因而不会复制数据。
完全快照恢复是指恢复到之前的“表结构”以及当时的数据，快照之后发生的数据不会恢复。
HBase的主要设计原则之一就是一旦文件写入就不再修改。
文件不可变意味着快照只需保持对快照产生时存在的文件追踪。
并且在压缩时负责提示系统该文件不应删除而是应当归档保存。同样的原则也适用于克隆和恢复操作。
因为文件是不变的，新建一个表只需要通过快照“链接”到文件引用即可。
导出快照是唯一需要复制数据的操作，因为其他集群没有数据文件。
可以对HBase快照做如下操作：
生成快照：尝试对指定表生成快照。如果集群在执行数据均衡、分隔或合并等操作时，可能会引起操作失败。
克隆快照：使用与指定快照相同的结构数据构建一张新表。
操作结果会生成一张有完整功能的表，对该表的任意修改不会对原表或快照产生影响。
还原快照：将表结构和数据恢复到生成快照时的状态。
删除快照：将系统中的快照删除，释放未共享的磁盘空间，而且不会影响其他克隆或快照。
导出快照：将快照数据和元数据复制到其他集群。
操作只会涉及HDFS，不会与Master或Region Server产生任何联系，HBase集群可以关闭。
hbase-site.xml中的hbase.snapshot.enabled是否设置为true确认打开了快照。
使用ExportSnapshot工具将现有快照导出至其他集群。
hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot SnapshotName -copy-to uriHBase表包含一系列元数据信息和键值对集合。
表信息：一份描述配置的文件，如列族，压缩类型与编码，bloom filter等。
Region：每个Region都通过定义起始键和终止键来负责管理一份连续的键值集合。
WAL/MemStore：在数据写入磁盘之前，put会先写到WAL然后保存在内存中，直到触发flush。
HFile就是HBase存储键值对的文件格式，HFile是不变的。但是当合并或域删除时可以被删除掉。
快照就是一系列元数据信息集合，能够允许管理员将表恢复至生成快照时的状态。
快照不是表的复制。最简单的方式就是把它想象成为了追踪元数据和数据一系列操作的集合。
在生成快照操作中没有执行任何复制数据的动作。
离线快照：讨论快照的最简单的场景就是当一张表被关闭了。
关闭一张表意味着所有的数据都写入了磁盘，而且不允许任何读写操作。
在这种情况下，生成快照仅仅就是获取表元数据并且与磁盘中的HFiles保持关联。
主节点执行操作需要的时间，主要取决于HDFS的namenode提供文件列表需要的时间。
在线快照：在大部分情况下，表都是开启的，而且每个域服务器都不断的处理put和get请求。
主节点接收到快照请求并要求每个Region Server都为其负责的域生成一份快照。
Master和Region Server之间通信是通过Apache ZooKeeper，使用了类似两阶段提交事务。
主节点建立一个“准备快照”的znode。
每个Region Server会处理请求，并且为指定的表在其负责范围内的域准备快照。
一旦准备完成，就会在准备请求的znode下建立一个子节点，意味着“准备完成”。
一旦所有Region Server都报告了他们的状态，主节点就建立另一个znode表示“提交快照”；
每个Region Server会完成快照并在加入节点前报告状态。
一旦所有Region Server都回报完成，主节点会完成快照并标记操作完成。
若某个Region Server报告失败，主节点会新建znode来广播放弃信息。
当Region Server继续处理新请求是，不同的用例情况下可能需要不同的一致性模型。
例如有人可能对不包含内存中最新数据的不完全的快照感兴趣，而有的人希望锁定写操作来获得一份完全保证一致性的快照以及其他可能性。
因此在域服务器上生成快照的程序是可拔插的。
现在唯一的实现是“Flush Snapshot”，就是在生成快照之前进行写入操作来保证列一致性。
其他的使用不同的一致性策略的程序可能会在未来实现。
在线生成快照需要的时间取决于实施快照操作并且将成功状态回报给主节点最慢的域服务器。这样的操作差不多在数秒之内完成。
HFiles是不可变的。
这样使得我们避免了在快照或克隆操作中复制数据，但在合并过程中文件被删除或者被合并后的版本替代。
在这样情况下，如果有快照或者克隆表指向其中某些文件，可以将他们转移到一个“归档”位置而不是删除。
如果你删除了快照且该文件不存在其他的引用，则该文件会被删除。
当快照被用于在用户或程序异常后恢复/还原表时，可以看做是一个备份方案，但实际上快照特性的用处远远超过简单的备份还原。
当从快照中克隆表后，你可以写一个MapReduce job或者简单应用来有选择性的合并差异，或者其他你认为重要的内容写入产品环境。
另外一个场景就是你能够测试结构变化或者更新数据，而不用为复制表等待数小时并且最后硬盘中也不会存在大量重复数据。
当执行克隆操作时，按快照中的表结构建立了新表并按快照域信息中的开始/结束键分割。
一旦元数据建立，能够像快照使用的方式一样而不用拷入数据。
因为HFiles是不可变的只是对建立的源文件的引用，这样就避免了数据拷贝并允许克隆能够修改而不影响源表或镜像。克隆操作是由主节点执行的。
恢复操作与克隆操作相似。
可以把它想象成时删除表之后再从快照中克隆出来。
恢复操作会恢复快照中的老数据并删除快照中不存在的数据，表结构也会恢复到与快照相同。
在底层，恢复操作时通过比较表状态与快照间不同来实现的，移除快照中不存在的文件并加上快照中有而当前表状态中没有的文件关联。
同样的表结构也被修改至快照生成时刻的状态。
恢复操作是由主节点执行并且表要处于关闭状态。
扫一扫
4969
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
