5-HBase存储

• 文件

  HBase 使用一个 HDFS 中可配置的根目录.

  <name>hbase.rootdir</name>    <value>hdfs://localhost:9000/user/hbase</value>  

  文件可以被分为两类， 一个类位于 HBase 根目录下， 另一类位于根目录中的表目录下。

  1. 根级目录

     

     1. 第一组文件是被 HLog 实例管理的 WAL 文件，这些日志文件被创建在 HBase 的根目录下的一个WALS 目录中

     2. 对于每个HRegionServer, 日志目录中都包含一个对应的子目录。 在每个子目录中有多个 HLog 文件（因为日志滚动）。一个 region 服务器的所有 region 共享一组 HLog 文件。

     3. 当所有包含的修改都被持久化到存储文件中，从而不再需要日志文件时，它们会被放到 HBase 根目录下的 oldWALS 目录中。当条件满足配置上的阀值会触发日志的滚动。在10分钟后， 旧的日志文件将被master 删除， 这是通过 hbase.master.logcleaner.ttl 属性设置的。

     4. hbase.id 和 hbase.version 文件包含集群的唯一 ID 和文件格式版本信息。

     5. corrupt 文件夹分别被用来存储日志拆分过程中产生的中间拆分文件和损坏的日志。

  2. 表级目录

     

     在 HBase 中，每张表都有自己的目录， 其位于文件系统中 HBase 根目录下。

     每张表都包括一个名为.tableinfo 的顶级文件，该文件存储表对应序列化后的 HTableDescriptor 。 其中包括表和列族的定义，同时其内容也可以被读取

     .tmp 目录中包含一些临时数据，例如，当更新 .tableinfo 文件时生成的临时数据都会被存放到该目录中。

  3. region级文件：

     

     在每张表的目录里面， 表模式中每个列族都有一个单独的目录。目录的名字是列族名。

     region目录中也有一个 .regioninfo 文件， 这个文件包含了对应 region 的HRegionInfo 实例序列化后的信息。与 .tableinfo 文件类似， 他能被外部工具用来查看 region 的相关信息。

     可选的 .tmp 目录是按需求创建的，他被用来存放临时文件，例如， 一次合并的重写文件。

     在 WAL 回放时， 任何被提交的修改都会被写入到每个 region 的一个单独的文件中。然后如果日志拆分过程已经成功完成， 这些文件将被自动移动到临时的 recovered.edits 目录中。 当 region 被打开时， region 服务器将会看到需要恢复的文件， 并且回放其中相应的条目。

     一旦 region 超过了配置中 region 大小的最大值， region 就需要拆分，其会创建一个对应的 splits 目录， 它被用来临时存放两个子 region 相关的数据。如果拆分过程成功，之后它们会被移动到表目录中，并形成两个新的 region， 每个region 代表原始 region 的一部分。

  4. region 拆分

     当一个 region 里的存储文件增长到大于配置的 hbase.hregion.max.filesize 的大小或者在列族层面配置的大小时， region 会被一分为二。

     这个过程非常迅速，因为系统只是为新 region 创建两个对应的文件，每个 region 是原始 region 的一半。

     region 服务器通过在父 region 中创建 splits 目录来完成这个过程。 接下来关闭该 region ，此后这个 region 不再接受任何请求。

     然后 region 服务器通过在 splits 目录中设立必须的文件结构来准备新的 子 region(使用多线程)，包括新 region 目录和参考文件。如果这个过程成功完成，他将把两个新 region 目录移动到表目录中。

     .META. 表中父region 的状态会被更新， 以表示其现在拆分的节点和子节点是什么。以上过程可以避免父 region 被意外重新打开。

     两个子 region 都准备好之后， 将会被同一个服务器并行打开。 打开的过程包括更新 .META. 表， 这样可以把两个 region 像其他 region 一样作为可用的 region 列出来。 之后这两个 region 会上线并开始服务请求。

     同时也会初始化两个 region 并对 region 的内容执行合并， 合并过程在替换引用之前会把父region 的存储文件异步重写到两个子 region 中。以上过程会在子 region 的 .tmp 目录中执行。 一旦生成了重写之后的文件， 它们将自动取代引用文件。

     最终父 region 都会被清理掉， 这意味着它在磁盘上所有的文件都会被删除。
     最后， master 被告知关于拆分的情况， 并且可以由于负载均衡而把新 region 移动到其他的 region 服务器上。

  5. 合并

     存储文件会被后台的管理进程仔细地监控起来以确保它们处于控制之下。 随着 memstore 的刷写会生成很多磁盘文件。

     如果文件的数目达到阈值，合并过程将把它们合并成数量更少的的体积更大的文件。这个过程持续到这些文件中最大的文件超过配置的最大存储存储文件大小，此时会触发一个 region 拆分。

     压缩合并有两种， 即 minor 和 major 。 minor 合并负责重写最后生成的几个文件到一个更大的文件中。文件数量是由 hbase.hstore.compaction.min属性设置的。 他的默认值是 3 ， 并且最小值需要大于或等于 2. 过大的数字将会延迟 minor 合并的执行， 同时也会增加执行时消耗的资源或执行的时间。

     minor 合并可以处理的最大文件数量默认为 10 ， 用户可以通过 hbase.hstore.compaction.max 来配置。 hbase.hstore.compaction.min.size 和 hbase.hstore.compaction.max.size 配置项属性进一步减少了需要合并的文件列表。任何比最大合并大小大的文件都会被排除在外。 最小合并大小的功能稍有不同：他是一个阈值， 而不是每个文件的限制。 它包括所有小于限制的文件，直到达到每次压缩允许的总文件数量。

     HBase 的另一种合并是 major 合并： 它们把所有文件压缩成一个单独的文件。在执行压缩检查时， 系统自动决定运行哪种合并。在memstore被刷写到磁盘后会触发检查，或在 Shell 命令 compact,major_compact之后触发检查，或是相应 API 在被调用后触发检查， 以后是被一个异步的后台进程触发后。