HBase架构——详解

HBase架构

---

HBase的特点

1. 大：一个表可以有上亿行，上百万列。
2. 面向列：面向列簇的存储和权限控制，列簇独立检索。
3. 稀疏：对于空（null）的列，并不占用存储空间，因此，表可以设计的非常稀疏。
4. 无模式（no Schema）：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。
5. 数据多版本：每个单元格中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。
6. 数据类型单一：HBase中的数据都是字节数组，没有类型。

---

HBase架构组件

• Region Server：提供数据的读写服务，当客户端访问数据时，直接和Region Server通信。
• HBase Master：Region的分配，DDL操作（创建表，删除表）。
• Zookeeper：是HDFS的一部分，维护一个活跃的集群状态。

  Hadoop DataNode存储着Region Server管理的数据，所有HBase数据存储在HDFS文件系统中，Region Server在HDFS DataNode中是可配置的，并使数据存储靠近在它所需要的地方，就近服务，当往HBase写数据时Local，但是当一个region被移动之后，HBase的数据就不是Local的，除非做了压缩（compaction）操作。NameNode维护物理数据块的元数据信息。

---

Regions

  HBase Table 通过rowkey range 的范围被水平切分成多个Region，一个Region包含了所有的，在Region开始键和结束之内的行，Regions被分配到集群的节点上，成为Region Servers，提供数据的读写服务，一个region server 可以服务1000个Region。

Region的分裂策略

  region中存储的是一张表的数据，当region中的数据条数过多的时候，会直接影响查询效率。当region过大的时候，region会拆分为两个region，HMaster会将分裂的region分配到不同的region server上，这样可以让请求分散到不同的Region Server上，已达到负载均衡，这也是HBase的一个优点。

• ConstantSizeRegionSplitPolicy

  0.94版本前，HBase region的默认切分策略

  当region中最大的store大小超过某个阈值(hbase.hregion.max.filesize=10G)之后就会触发切分，一个region等分为2个region。

  但是在生产线上这种切分策略却有相当大的弊端（切分策略对于大表和小表没有明显的区分）：

  • 阈值(hbase.hregion.max.filesize)设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，形成热点，这对业务来说并不是什么好事。
  • 如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。

• IncreasingToUpperBoundRegionSplitPolicy

  0.94版本~2.0版本默认切分策略

  ​ 总体看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大的store大小大于设置阈值就会触发切分。
  但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系.

  region split阈值的计算公式是：

  • 设regioncount：是region所属表在当前regionserver上的region的个数

  • 阈值 = regioncount^3 * 128M * 2，当然阈值并不会无限增长，最大不超过MaxRegionFileSize（10G),当region中最大的store的大小达到该阈值的时候进行region split

  例如：

  • 第一次split阈值 = 1^3 * 256 = 256MB
  • 第二次split阈值 = 2^3 * 256 = 2048MB
  • 第三次split阈值 = 3^3 * 256 = 6912MB
  • 第四次split阈值 = 4^3 * 256 = 16384MB > 10GB，因此取较小的值10GB
  • 后面每次split的size都是10GB了

  特点

  • 相比ConstantSizeRegionSplitPolicy，可以自适应大表、小表；
  • 在集群规模比较大的情况下，对大表的表现比较优秀
  • 对小表不友好，小表可能产生大量的小region，分散在各regionserver上
  • 小表达不到多次切分条件，导致每个split都很小，所以分散在各个regionServer上

• SteppingSplitPolicy

  2.0版本默认切分策略

  ​ 相比 IncreasingToUpperBoundRegionSplitPolicy 简单了一些
  ​ region切分的阈值依然和待分裂region所属表在当前regionserver上的region个数有关系

  • 如果region个数等于1，切分阈值为flush size 128M * 2
  • 否则为MaxRegionFileSize。

  这种切分策略对于大集群中的大表、小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不会再产生大量的小region，而是适可而止。

• KeyPrefixRegionSplitPolicy

  根据rowKey的前缀对数据进行分区，这里是指定rowKey的前多少位作为前缀，比如rowKey都是16位的，指定前5位是前缀，那么前5位相同的rowKey在相同的region中。

• DelimitedKeyPrefixRegionSplitPolicy

  保证相同前缀的数据在同一个region中，例如rowKey的格式为：userid_eventtype_eventid，指定的delimiter为 _ ，则split的的时候会确保userid相同的数据在同一个region中。
  按照分隔符进行切分，而KeyPrefixRegionSplitPolicy是按照指定位数切分。

• BusyRegionSplitPolicy

  按照一定的策略判断Region是不是Busy状态，如果是即进行切分

  如果你的系统常常会出现热点Region，而你对性能有很高的追求，那么这种策略可能会比较适合你。它会通过拆分热点Region来缓解热点Region的压力，但是根据热点来拆分Region也会带来很多不确定性因素，因为你也不知道下一个被拆分的Region是哪个。

• DisabledRegionSplitPolicy

  不启用自动拆分, 需要指定手动拆分

Compaction操作

Minor Compaction：

• 指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次 Minor Compaction 的结果是更少并且更大的StoreFile。