HBase Snapshot 相关操作原理_hbase snapshot 原理

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

2）  Take、Clone、Restore、Delete、Export 操作的具体实现原理（主要看其目录的变化情况）

3） 目录能改变吗？

注：在对 snapshot 相关操作做分析时，可能会引出新的问题，在后面会做具体分析。

3. Snapshot 相关文件与数据结构

snapshot 包含的是一些元数据，根据这些元数据可以重建表，也可以定位到具体的 HFile 文件（到这里就需要对 HBase 数据的物理存储结构有所了解了，先贴出其基本的原理图如下，具体的描述可以搜一下，到处都是）。

在上图中的 HRegion 外层是 table，可以认为 HRegion 是 table 中的数据被分割后存储到不同的 Region Server 服务器上一小块。Store 包含 MemStore 与 StoreFile，MemStore 是内存数据，这里不讨论，StoreFile 则是具体的物理文件，如果说 HFile 是具体的数据文件，而不代表 link，那么可以认为 StoreFile 其实除了包含 HFile，也包含了 link 数据文件，link 文件是对具体数据文件的引用，同时还有一种文件，reference 文件，这些在后面都会讲到。

那么，表数据在 HBase 中的目录结构大概如下：

注：

[/Hbase]

• /archive
  • /data
    • [/namespace] - 表空间
      • [/tableName] - 表名称
        • /.tabledesc
          • .tableinfo.[xxxxxxxx] - 表描述
            
        • /.tmp
        • [/region encode name] - region encode 名称
          • /.tmp
          • [/columns family] - 列族
            • [Hfiles / link files] - hfile / link 文件
          • .regioninfo - region 信息
        • [/region encode name] - region encode 名称
          • [/columns family] - 列族
            • /.links-[regionName]
              • [reference files] - 引用文件

• /data
  • [/namespace] - 表空间
    • [/tableName] - 表名称
      • /.tabledesc
        • .tableinfo.[xxxxxxxx] - 表描述
          
      • /.tmp
      • [/region encode name] - region encode 名称
        • /.tmp
        • [/columns family] - 列族
          • [HFiles / link files] - hfile / link 文件
        • .regioninfo - region 信息

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

据于此，snapshot 的基本目录结构则如下（.tmp 中的文件是快照过程中生成的文件，最后的结果中并不存在）：

[/Hbase]

• /.hbase-snapshot
  • /.tmp
    • [/snapshot] - 快照，存储相关元数据
      
      • /.tabledesc
        • .tableinfo.[xxxxxxxxxx] - 表的 HTableDescriptor 的序列化
      • /.tmp
      • [/region encode name] - region encode 名称
        • [/columns family] - 列族
          • [hfile files / link files] - hfile/ link 文件，空的文件，代表对同名文件的一个引用
        • .regioninfo - region 信息
          
      • .snapshotinfo - snapshot 的描述信息
      • region-manifest.[region encode name] - 存储 store files的具体位置等信息
      • 注：[/region encode name]目录下文件与 region-manifest.[region encode name]文件最终会合并成 data.manifest 文件，并保存到 snapshot 目录下
  • [/snapshot] - 快照，存储相关元数据
    • /.tabledesc
      • .tableinfo.[xxxxxxxxxx] - 表的 HTableDescriptor 的序列化
    • /.tmp
    • .snapshotinfo - snapshot 的描述信息
    • data.manifest

HTableDescriptor 中的信息，最后会被写入  .tableinfo.[xxxxxxxxxx] 文件，位于[/snapshot]/.tabledesc 目录， 对应[/tablePath]/ .tabledesc 目录下的同名文件。

HRegionInfo

HRegionInfo 中的信息最后以字节码的形式被存储在  .regioninfo  文件中， [/tablePath]/[encodedName] 目录下，因为所有的 store file 位置信息最后都被 consolidate（合并）到 data.manifest 中了，所以 snapshot 中并不存在此文件。

table_schema {
    table_name {
        namespace: "default"qualifier: "testRestore"
    }
    attributes {
        first: "IS_META"second: "false"
    }
    column_families {
        name: "cf"attributes {
            first: "DATA_BLOCK_ENCODING"second: "NONE"
        }
        attributes {
            first: "BLOOMFILTER"second: "ROW"
        }
        attributes {
            first: "REPLICATION_SCOPE"second: "0"
        }
        attributes {
            first: "COMPRESSION"second: "NONE"
        }
        attributes {
            first: "VERSIONS"second: "1"
        }
        attributes {
            first: "TTL"second: "2147483647"
        }
        attributes {
            first: "MIN_VERSIONS"second: "0"
        }
        attributes {
            first: "KEEP_DELETED_CELLS"second: "FALSE"
        }
        attributes {
            first: "BLOCKSIZE"second: "65536"
        }
        attributes {
            first: "IN_MEMORY"second: "false"
        }
        attributes {
            first: "BLOCKCACHE"second: "true"
        }
    }
}
region_manifests {
    region_info {
        region_id: 1468637981928 table_name {
            namespace: "default"qualifier: "testRestore"
        }
        start_key: "\000\000\000\000"end_key: "\000\000\000\001"offline: false split: false replica_id: 0
    }
    family_files {
        family_name: "cf"store_files {
            name: "617722f185be4c31a7e1dad6d697f96f"
        }
        store_files {
            name: "d1cade129d0a4663b290163774f93d1b"
        }
        store_files {
            name: "d390ebaae77b4f2d8a6a63dc0afcd16f"
        }
    }
}
region_manifests {
    region_info {
        region_id: 1468637983894 table_name {
            namespace: "default"qualifier: "testRestore"
        }
        start_key: ""end_key: ""offline: false split: false replica_id: 0
    }
    family_files {
        family_name: "cf"store_files {
            name: "0a3641d6754e4cdfbf4cd5412b2e5027.e38ba7d189fdc320ccd967bcc7e64258"
        }
        store_files {
            name: "2704e81af3284eabb170d5e86d9dab04.e38ba7d189fdc320ccd967bcc7e64258"
        }
        store_files {
            name: "be689528dfbe491db617bcc9f7b913c2.e38ba7d189fdc320ccd967bcc7e64258"
        }
    }
}

讲真，我还没有对这些参数做一个全面的了解，但是有两个参数是必须的，即“ -snapshot”和“ -copy-to ”，其命令格式如下（也是常用的命令格式）：

sudo -u hbase hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot snapshotName -copy-to hdfs://host:port/hbase

• Clone：该操作用指定 snapshot 的 schema 和数据来创建一个新表。该操作不会对原表或者该 snapshot 造成任何影响。

• Restore：该操作将一个表的 schema 和 data 回滚到创建该 snapshot 时的状态。

针对 4.2 中的疑问，在 Restore 时，并未发现 link 文件有主动转移到 archive 目录，而 link 的链接路径既然不是真实的 HFile 地址，这样难道不是错误的吗？

那么在 HBase 里，针对 link 文件有一个对应的  HFileLink 类，里面包含了 3 个路径属性，originPath 、 tempPath、archivePath，其中 archivePath 便是 originPath 路径在 archive 目录下对应的地址，而调用 HFileLink 的 open 方法以返回输入流时，会轮流的尝试打开 originPath、tempPath、archivePath 三个路径，所以如果按此方法打开 store file，就能找到 archive 目录下的 store file 文件。它最主要的一个方法 tryOpen 来自于其父类 Filelink 的内部类 FileLinkInputStream ，源码如下：

private FSDataInputStream tryOpen() throws IOException {
    // 遍历所有地址，尝试找到正确的文件
    for (Path path: fileLink.getLocations()) {
        if (path.equals(currentPath)) continue;
        try { in =fs.open(path, bufferSize);
            if (pos != 0) in .seek(pos);
            assert( in .getPos() == pos) : "Link unable to seek to the right position=" + pos;
            if (LOG.isTraceEnabled()) {
                if (currentPath == null) {
                    LOG.debug("link open path=" + path);
                } else {
                    LOG.trace("link switch from path=" + currentPath + " to path=" + path);
                }
            }
            currentPath = path;
            return ( in );
        } catch(FileNotFoundException e) {
            // Try another file location
        }
    }
    thrownew FileNotFoundException("Unable to open link: " + fileLink);
}

6. 总结

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 相关操作的涉及到的内部目录名称都是使用类里面的常量保存，比如

注：以上由于没有绘图软件，所以很难理解，并且由于各个版本可能存在差异，所以请以实际为主。