HBase austerity and division

HBase tightening and data management division process is an essential function, precisely because they exist as HBase has read and write performance and efficient load balancing clusters provide a guarantee, then make a few of these two processes in detail introduction.

Region Overview

HBase tightening the split occurred in the Region are conducted in, find out about HBase partners are no strangers here, and then the structure and function of the Region to make a brief introduction. HBase Region is the smallest unit in the distributed storage and load balancing, in a different region may be assigned different Region Server, Region data storage relies on the file system HDFS

Here Insert Picture Description

RegionServer : management and maintenance of Master assigned Region, store and query data processing request
HLog : be the first to write a HLog in the pre-writing data, when RegionServer abnormal case, MemStore data not brush into the disk results in the loss
Region : a table for one or more region, region stored in the data table of certain continuous
Store : Region in one or more Store, a column group corresponding to a Store
Memstore : memory-based storage unit (the latest version 128M), when writing data into the first here, when the size or time threshold is reached, will trigger flush into StoreFile (HFile), read data query priority here
StoreFile : disk space for storing data MemStore brush over to HFile file to store data. StoreFile to the size decision Compaction
HFile : a package StoreFile corresponds to the binary Hadoop, StoreFile underlying file, stored in the HDFS

Region tightening (Compaction)

Compaction Overview

Compaction is to select a file from one part HFile Store in a Region of the merger. Merger principle is to start these files to be merged in order KeyValue read data written to a new file after re-ascending order, after the newly generated file replaces the previous file merge external services.

Compaction way

HBase according to the size of the merger will Compaction divided into two categories:

Minor_compation (small tightening)
Major_compation (big crunch)

Minor_compaction

Refers to select the part of small, adjacent HFile, they will merge into a larger HFile, merge short duration of the consolidation process only the file is marked merger will not clean up deleted or expired data

Here Insert Picture Description

Major_compaction

Refers to all HFile merged into one HFile, the merger process will clean out a Store in the deleted data, TTL expired data and the version number than the version number of the set of data. Major_compaction relatively long duration, the process consumes a lot of system resources, a greater impact on upper-layer services. Thus, a large part of the amount of traffic on the data line is generally recommended to close automatically trigger Major_compaction function, when the service is triggered manually change relatively idle.

<!--低峰值执行major_compaction时间-->
<property>
    <name>hbase.hregion.majorcompact.begintime</name>
    <value>00:00:00</value>
</property>
<property>
    <name>hbase.hregion.majorcompact.endtime</name>
    <value>01:30:00</value>
</property>

<!--关闭Major_compaction-->
<property>
    <name>hbase.hregion.majorcompaction</name>
    <value>0</value>
 </property>

Here Insert Picture Description

Compaction Process

Compaction of HBase will trigger under certain conditions, once a number of conditions are met triggered after the execution of the merger in accordance with certain procedures, Compaction process will be handled by a separate thread

The basic process can be divided into the following sections:

Here Insert Picture Description

Compaction of the trigger

There are a variety of conditions Compaction triggered, the most common of three ways:
- MemStore Flush
  
  MemStore达到一定条件后会Flush产生HFile文件，执行完后会对当前Store中的文件数判断，如果Store的文件数大于hbase.hstore.compactionThreshold配置项，就会触发Compaction。整个region的多个Store同时进行flush时，就有可能在短时间内执行多次Compaction
- 定期检查触发
  
  RegionServer会在后台启动一个线程CompactionChecker，定期触发检查对应Store是都需要执行Compaction，检查周期为hbase.server.thread.wakefrequency * hbase.server.compactchecker.interval.multiplier。先检查Store中总文件数是否大于阈值hbase.hstore.compactionThreshold，大于就触发Compaction；否则，检查当前Store的HFile最早的更新时间是否大于mcTime([7-7×0.2，7+7×0.2],7为hbase.hregion.majorcompaction，0.2为hbase.hregion.majorcompaction.jitter)，默认7天左右执行一次Major_compaction
- 手动触发
  手动触发Compaction是为了执行Major_compaction
  - Major_compaction会影响读写性能，选择低峰期手动触发
  - 用户希望在alter之后立即生效
  - Hbase硬盘容量不够时，清理过期数据
选择合适的HFile文件

Compaction的核心，合并文件的大小及其当前承载的IO数直接决定了Compaction的效果以及对整个系统其他业务的影响程度
- 对Store中的多有HFile检查，排除不满足条件的文件
  - 当前正在Compaction的文件，及更新的文件
  - 过大的文件，大于hbase.hstore.compaction.max.size的文件
```
<property>
    <name>hbase.hstore.compaction.max.size</name>
    <value>2147483648</value>
</property>
```
- 候选文件是否满足条件进行Major_compaction
  - 用户强制执行Major_compaction
  - 长时间没有Major_compaction（上次Major_Compaction时间早于当前时间-hbase.hregion.majorcompaction）且候选文件数小于hbase.hstore.compaction.max
  - Store中含有reference文件，reference文件是region分裂产生的临时文件，一般必须在Compaction过程中清理
```
<property>
    <name>hbase.hstore.compaction.max</name>
    <value>200</value>
</property>
```
- 候选文件不满足Major_compaction，即为Minor_compaction
  
  Minor的文件选择策略
  - RatioBasedCompactionPolicy
    
    从老到新逐一扫描候选文件，满足条件停止
    - 当前文件大小<比当前文件新的所有文件大小总和* ratio （ratio是一个可变值，默认高峰期1.2，非高峰期5，并允许用户配置参数）
    - 当前所剩候选文件数<=hbase.store.compaction.min（默认为3）
  - ExploringCompactionPolicy
    
    从老到新逐一扫描候选文件，找到合适的文件集就停止，合适的文件集的理解为：
    
    待合并文件数最多或者待合并文件数相同的情况下文件较小，这样有利于减少Compaction带来的IO消耗。
选择合适的合并线程池

HBase实现中有一个专门的类CompactSplitThead负责接收Compaction请求和split请求,为了能够独立处理请求提高系统的处理性能，构造了多个线程池：splits线程池负责处理所有的split请求，largeCompactions用来处理大Compaction，smallCompaction负责处理小Compaction

注：Hbase定义了hbase.regionserver.thread.compaction.throttle决定是否为大小Compaction

largeCompactions线程池和smallCompactions线程池默认都只有一个线程，允许用户配置
```
<property>
    <name>hbase.regionserver.thread.compaction.large</name>
    <value>4</value>
</property>
<property>
    <name>hbase.regionserver.thread.compaction.small</name>
    <value>4</value>
</property>
```
执行HFile文件合并

合并的流程主要有以下几步：
- 读出待合并HFile文件的keyValue，归并排序后写到HDFS的./tmp目录下的临时文件中
- 将临时文件移动到合并后的Store的数据目录
- 将合并文件的输入和输出文件路径封装为KV写入HLog日志，并打上Compaction标记，强制执行sync
- 将合并后Store数据目录中的输入文件删除

Compaction作用

合并小文件，减少文件数，稳定随机读延迟

Hbase的数据存储依赖于HDFS，首先当MemStore向磁盘刷入多个小文件时，多个小文件的元数据信息会对HDFS中的NameNode的物理内存容量产生限制；其次，读数据时，访问大量的小文件会导致访问不断的从一个DataNode到另一个DataNode去检索，会消耗大量的系统资源（IO，网络）
提高数据的本地化率

在进行Compaction合并小文件的同时会读取远程DataNode上的数据写入大文件，并在当前DataNode节点上保存一个副本，提高数据的本地化率。本地化率越高，在HDFS上访问数据时延迟就越小，本地化率越低，访问数据时大概率通过网络访问，延迟必然会大
清理无效的数据，减少数据存储量
HBase中的无效数据包含：
- 执行删除的数据时，数据不会即时删除，而是会对删除数据做tombStone Marker（“墓碑标记”），但数据仍在HFile中
```
# 查看删除的数据，会被标记
scan 'hrecord',{RAW=>true,VERSION=>3}
ROW		COLUMN+CELL
001		column=info:address, timestamp=2,type=Delete
001		column=info:address, timestamp=3,value=record_id
```
- 在HBase数据管理中，会根据业务需求设置数据TTL（生存时间），它是设置一个基时间戳的临界值，内部管理自动检查超过TTL值的数据会被自动删除
```
# 建表设定
create 'hrecord',{NAME => 'f', TTL=>'86400'}
# 修改TTL，作用于列族f
alter "hrecord",NAME=>'f',TTL=>'FOREVER'
```
- HBase分裂过程中会产生reference临时文件，reference文件是region分裂产生的临时文件，一般必须在Compaction过程中清理

Region分裂（Split）

Split概述

Region分裂是HBase最核心的功能之一，是实现分布式可扩展性的基础。最初，每个Table只有一个Region，随着数据的不断写入，HBase根据一定的触发条件和一定的分裂策略将Hbase的一个region分裂成两个子region并对父region进行清除，通过HBase的balance机制，实现分裂后的region负载均衡到对应RegionServer上

Split方式

目前常见的HBase分裂方式有三种：

Per-Spliting（预分区）
Auto-Spliting
Force-Spliting

Per-Spliting

Per-Spliting指的是在HBase创建Table时，指定好Table的Region的个数，生成多个Region。这么做的好处是一方面可以避免热点数据的写入问题（只有一个region，写数据量大时其余RegionServer就是空闲的），另一方面减少Region的Split几率，同时减少消耗集群的系统资源（IO，网络），减少因Split暂停Region的上线造成对HBase读写数据的影响。

HBase默认建表时只有一个Region，此时的RowKey是没有边界的，即没有StartKey和EndKey。进行预分区时，需要配置切分点，使得HBase知道在哪个RowKey点做切分。

HBase自带了两种pre-split的算法，分别是 HexStringSplit 和 UniformSplit 。如果我们的row key是十六进制的字符串作为前缀的，就比较适合用HexStringSplit，作为pre-split的算法。我们使用HexHash(prefix)作为row key的前缀，其中Hexhash为最终得到十六进制字符串的hash算法。

Auto-Spliting

自动分裂指的是随着不断向表中写入数据，Region也会不断增大，HBase根据触发的分裂策略自动分裂Region，当前HBase已经有6中分裂触发的策略，不同版本中配置的分裂策略不同，介绍一下常用三种：

ConstantSizeRegionSplitPolicy

0.94版本之前默认的分裂策略。表示一个Region中最大Store的大小超过设置阈值（hbase.hregion.max.filesize）之后就会触发分裂。

弊端：分裂策略对于大表比较友好，小表达不到阈值永远不分裂，如果设置为对小表友好就可能产生大量的region，对集群管理、资源使用都不好

<property>
    <name>hbase.hregion.max.filesize</name>
    <value>5368709120</value>
</property>

IncreasingToUpperBoundRegionSplitPolicy

0.94~2.0版本默认分裂策略。表示一个Region中最大Store的大小超过设置阈值（hbase.hregion.max.filesize）之后就会触发分裂。但是阈值不是一个固定值，而是在一定条件下不断调整，调整后的阈值等于(#regions) *(#regions) *(#regions) * f lush size * 2，(#regions) 表示Region所属表在当前RegionServer上的Region个数，阈值最大值为用户配置的MaxRegionFileSize，这种策略自适应大小表

弊端：在大集群场景下，很多小表产生大量region分散在整个集群
SteppingSplitPolicy

2.0版本默认分裂策略。表示一个Region中最大Store的大小超过设置阈值（hbase.hregion.max.filesize）之后就会触发分裂。分裂阈值大小和待分裂Region所属表在当前RegionServer上的Region个数有关，如果Region个数为1，分裂阈值为flush size * 2，否则为MaxRegionFileSize，小表不会再产生大量的小Region
DisableSplitPolicy

禁止Region Split
KeyPrefixRegionSplitPolicy

切分策略依然依据默认切分策略，根据 Rowkey 指定长度的前缀来切分 Region，保证相同的前缀的行保存在同一个 Region 中。由 KeyPrefixRegionSplitPolicy.prefix_length 属性指定 Rowkey 前缀长度。按此长度对splitPoint进行截取。此种策略比较适合有固定前缀的 Rowkey。当没有设置前缀长度，切分效果等同与 IncreasingToUpperBoundRegionSplitPolicy。
DelimitedKeyPrefixRegionSplitPolicy

切分策略依然依据默认切分策略，同样是保证相同 RowKey 前缀的数据在一个Region中，但是是以指定分隔符前面的前缀为来切分 Region。

Forced-Spliting

客户端手动运行split命令执行分裂

 split 'forced_table', 'b' //其中forced_table 为要split的table , ‘b’ 为split 点

我们还可以通过配置hbase.regionserver.region.split.policy指定自己的split策略

<!--定时切分执行类-->
<property>
    <name>hbase.regionserver.region.split.policy</name>
    <value>org.apache.hadoop.hbase.regionserver.TimingRegionSplitPolicy</value>
</property>
<!--定时切分时间-->
<property>
     <name>hbase.regionserver.region.split.startTime</name>
     <value>02:00:00</value>
</property>
<property>
    <name>hbase.regionserver.region.split.endTime</name>
    <value>04:00:00</value>
</property>

Split过程

HBase将整个分裂过程包装成了一个事务，目的是保证分裂事务的原子性。

整个分裂事务过程分为三个阶段：prepare、execute和rollback。

prepare

在内存中初始化两个子Region，具体生成两个HRegionInfo对象，包含tableName、regionName、startkey、endkey等。同时会生成一个transaction journal，这个对象用来记录分裂的进展，具体见rollback阶段。
execute

Here Insert Picture Description

RegionServer将ZooKeeper节点上hbase/region-in-transition/parent_region_name中该Region的状态更改为SPLITING

Master通过watch节点/region-in-transition检测到Region状态改变，并修改内存中Region的状态，在Master页面RIT模块可以看到Region执行split的状态信息

在父Region的HDFS存储目录下新建临时文件夹.split，保存split后的daughter region信息

关闭父Region。父Region关闭数据写入并触发f lush操作，将写入Region的数据全部持久化到磁盘。此后短时间内客户端落在父Region上的请求都会抛出异常NotServingRegionException
在.split文件夹下新建两个子文件夹，称为daughter A、daughter B，并在文件夹中生成reference文件，分别指向父Region中对应文件。这个步骤是所有步骤中最核心的一个环节，会生成reference文件日志，可以通过reference日志文件查看指向的是哪个父Region中的哪个HFile文件，并且reference文件内容也很重要，可以通过Hadoop命令查看文件内容
# StoreOpener名在reference日志中可以查看
hdfs dfs -cat /hbase-rsgroup/data/default/music/StoreOpener名/cf/reference文件名
reference文件是一个引用文件（非Linux链接文件）文件内容不是用户数据，由两部分构成：

分裂点SplitKey

一个boolean类型的变量，true表示该reference文件引用的是父文件的上半部分（top），false表示引用的是下半部分（bottom）
父Region分裂为两个子Region后，将daughter A、daughter B拷贝到HBase根目录下，形成两个新的Region

父Region通知修改hbase:meta表后下线，不再提供服务。下线后父Region在meta表中的信息并不会马上删除，而是将split列、off line列标注为true，并记录两个子Region

开启daughter A、daughter B两个子Region。通知修改hbase:meta表，split列、off line列标注为tfalse，正式对外提供服务

rollback阶段

如果execute阶段出现异常，则执行rollback操作。为了实现回滚，整个分裂过程分为很多子阶段，回滚程序会根据当前进展到哪个子阶段清理对应的垃圾数据。

由以上分裂过程可知：

分裂后父Region的数据没有立即删除，子Region通过reference文件对数据的查询，子Region文件实际没有任何用户数据，文件中存储的仅是一些元数据信息（分裂点rowkey等）

父Region的数据什么时候迁移到子Region中的呢？

迁移发生在子Region执行Major Compaction时。

根据Compaction原理，从一系列小文件中依次由小到大读出所有数据并写入一个大文件，完成之后再将所有小文件删掉，因此Compaction本身就是一次数据迁移。分裂后的数据迁移完全可以借助Compaction实现，子Region执行Major Compaction后会将父目录中属于该子Region的所有数据读出来，并写入子Region目录数据文件中。

父Region是什么时候被删除的呢？

Master会启动一个线程定期遍历检查所有处于splitting状态的父Region，确定父Region是否可以被清理。

检测线程首先会在meta表中读出所有split列为true的Region，并加载出其分裂后生成的两个子Region（meta表中splitA列和splitB列）
检查两个子Region是否还存在引用文件，如果都不存在引用文件就可以认为该父Region对应的文件可以被删除

Split作用

说起HBase分裂的作用首先要理解分布式集群的负载均衡，实现了负载均衡，集群的扩展性才能得到有效的保证。HBase的负载均衡就是依赖Region的Split将不断写入数据增大的Region合理切分，分配给对应的RegionServer实现的。其次，HBase中Region的迁移、合并等操作也是实现负载均衡的保障机制。

在实际业务场景中，HBase的Region分裂，能够有效的避免热点数据的访问问题，提高数据的读写效率。