day 49 hbase 基础

---

I know, i know
地球另一端有你陪我

一、HBase 系统架构

1、大：一个表可以有上亿行，上百万列

2、面向列：面向列族（簇）的存储和权限控制，列（簇）独立检索

3、稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。

4、无模式（no Schema）：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列

5、数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，即时间戳

6、数据类型单一：HBase中的数据都是字节数组，没有类型

1、Master

为 Region server 分配 region
（ region 类似hadoop 中的 block，hbase 中的存储单位，存储于 hdfs 中，文件格式是 Hfile）

负责 Region server 的负载均衡
（某一个 server 负载过多 region 时，会进行再分配）

发现失效的 Region server 并重新分配其上的 region

管理用户对 table 的增删改操作
（指的是表结构（列簇等）的增删改）

2、RegionServer

维护 region，处理对这些 region 的 IO 请求
（读写操作）

负责切分在运行过程中变得过大的 region
（一个 region 过大时，会自动进行切分。也能建表时预设值，进行自动切分）

3、Region

HBase 自动把表水平划分成多个区域（region），每个 region 保存一个表里某段连续的数据；
这些数据按照字典升序排列（类比 windows 的文件名升序）

每个表一开始只有一个 region，随着数据不断插入表，region 不断增大，
当增大到一个阀值的时候，region就会等分会两个新的 region（裂变）；

当 table 中的行不断增多，就会有越来越多的 region，这样一张完整的表被保存在多个Regionserver 上

4、Store、Memstore 与 Storefile

一个 region 由多个 store 组成，一个 store 对应一个列簇；

store 有两部分， memstore 位于内存，缓存，storefile 位于磁盘，写操作先写入 memstore；

当 memstore 中的数据达到阈值（一般是128MB），regionserver 会启动 flashcache 进程，
将数据写入 storefile，每次写入形成单独的一个 storefile；

当 storefile 文件的数量增长到一定阈值后，系统会进行合并（minor、major compaction），在合并过程中会进行版本合并和删除工作（majar），形成更大的 storefile；

当一个 region 所有 storefile 的大小和数量超过一定阈值后，会把当前的 region 分割为两个，并由 master 分配到相应的 regionserver 服务器，实现负载均衡；

客户端检索数据，先在 memstore 中找，其次去 storefile 查找

Region 是 Base 中分布式存储和负载均衡的最小单元；

Region 由一个或者多个 Store 组成，每个 store 保存一个列簇（columns family）；

每个 strore 又由一个 memStore 和0至多个 StoreFile 组成；

每个 regionserver 中包含一个 hlog ，类似 redis 中 aof 持久化生成的日志文件，
包括所有的操作记录；

如图：StoreFile 以 HFile 格式保存在 HDFS 上

二、组成部分

1、 RowKey

一行数据的唯一标识；按照字典升序排序；能存储 64kb 的字节数据，一般也不建议太长

2、 Column Family 、 qualifier

Base 表中的每个列都归属于某个列簇，列簇必须作为表模式（schema）预定义；

列名以列簇作为前缀，每个列簇下可以包含多个列成员，类成员可以随时按需加入；

权限控制、存储以及调优都是在列族层面进行的，因为列成员是存储在列簇文件之下；

HBase 把同一列簇里面的数据存储在同一目录下（store），由一个或几个文件保存

3、 cell 单元格

由行和列的坐标交叉决定；

单元格是有版本的（version）；

单元格的内容是未解析的字节数组；

由 {row key， column( = + )， version} 唯一确定的单元；

cell中的数据是没有类型的，全部是字节码形式存贮

4、 时间戳

Base 中每个 cell 对同一份数据有多个版本，根据唯一的时间戳区分版本之间的差异；

不同版本的数据按照时间倒序排序，最新的数据版本排在最前面；

时间戳的类型是 64 位整型（类比 long）；

时间戳可以由 Base（数据写入时自动）赋值，该时间戳是精确到毫秒的当前系统时间，
也可以由客户显式赋值，如果要避免数据版本冲突，就必须自己生成具有唯一性的时间戳

5、 HLog(WAL log)

HLog 文件就是一个普通的 Hadoop Sequence File，存储的也是 keyvalue 对象；

Key是 HLogKey 对象，记录了写入数据的归属信息（元数据），
包括 table 和 region ，序列顺序（sequence number）和写入时间（timestamp），
sequence number 的起始值为 0，或者是最近一次存入文件系统中 sequence number；

SequeceFile 的 Value 是 HBase 的 KeyValue 对象，即对应 HFile 中的 KV 对

三、Compaction操作

1、Minor Compaction：

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

2、Major Compaction：

指将所有的 StoreFile 合并成一个 StoreFile，这个过程会清理三类没有意义的数据：
被删除的数据、TTL过期数据、版本号超过设定版本号的数据

另外，一般情况下，major compaction时间会持续比较长，整个过程会消耗大量系统资源，
对上层业务有比较大的影响。因此线上业务都会将关闭自动触发major compaction功能，
改为手动在业务低峰期触发

三、Region 切分策略

1、ConstantSizeRegionSplitPolicy

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

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

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

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

2、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上
  
  

3、SteppingSplitPolicy

2.0版本默认切分策略

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

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

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

4、KeyPrefixRegionSplitPolicy

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

5、DelimitedKeyPrefixRegionSplitPolicy

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

6、BusyRegionSplitPolicy

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

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

7、DisabledRegionSplitPolicy

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

四、读写流程

（未完待续）