1 本章目录

1. 负载均衡
2. 快照
3. 拆分
4. 数据存储
5. 合并
6. 刷写
7. 读数据流程
8. 写数据流程
9. 热点问题
10. row设计
11. 批量导入
12. 协处理器

1 负载均衡

由Master的LoadBalancer线程周期性的在各个RegionServer间移动region维护负载均衡。

1 经常被并发查询的数据不要存储在同一个RegionServer中 , 避免热点读取问题 .

2 当一个机器上经过大量的插入或者删除数据以后 ,region合并或者分裂 ,那么机器上的region的数量会相差很大 .

3 当新增了节点以后 , 应该去分配一些其他机器上的region数据

4 当某个RegionServer宕机以后 , 这台机器上数据的分配

region的执行

Hbase中负载均衡的开关balanceSwitch默认是开启的 .

hbase.balancer.period是设定负载均衡的参数，默认为每5分钟（300000毫秒）运行一次，参数配置通过hbase-site.xml文件。具体的设置格式如下：

 <property>  <name>hbase.balancer.period</name>  <value>300000</value>  </property>

1.1 自动负载均衡流程

）两个有效参数：MIN = floor(average)（表示下限）和MAX=ceil（average）（表示上限）。

2）循环过载机器，将Region卸载到MAX数量，在小于等于MAX时停止排序Region（按时间新旧）。

3）遍历最轻负载机器，分配Region直到Server达到MIN值。在大于等于MIN时停止。这些Region都是之前卸载的。可能没有足够地卸载Region让轻负载的机器达到MIN值，如果这样，在Region数等于neededRegions（轻负载机器的数量）时停止。可能我们分配了卸载的Region到轻负载机器，但是仍然有Region没有分配出去，这种情况下，本步骤完成，在下面步骤中再做处理。

4）如果neededRegions是非零的值，遍历负载最重的机器，从每台机器上卸载一个Region，使得它们的值从MAX到MIN。

5）现在有很多Region等待分配，遍历最轻的负载机器（多台），分配Region到MIN。

6）如果仍然有Region没有分配，遍历最轻的负载机器（多台），这次分配Region到MAX。

7）所有Server的Region数量时MAX或者MIN，另外，所有大于等于MAX的Server保证在均衡完成后都是MAX个Region。从而保证Region移动的最小数量。

其中，轻负载指的是Region数量小于等于AVG，过载指大于等于AVG，所有的RegionServer都按照负载从大到小排序，存放在TreeMap中（保证先遍历过载Server）。

1.2 强制执行负载均衡

) kill 掉不是Hmaster节点的 regionserver(slave2)

2) hbase 16010 查看regionserver在slave2节点

3) 在master节点启动 regionserver(slave2)

    master $>hbase-daemons.sh start regionserver

4) hbase 16010 查看regionserver负载不均衡 (多刷新  0  6)

     balance负载均衡指令，需使用开关模式，原因负载均衡比较耗费资源：      hbase(main):005:0> balance_switch true    //开启负载均衡      hbase(main):005:0> balancer                      //执行负载均衡      hbase(main):005:0> balance_switch false   //关闭负载均衡      hbase(main):005:0> balancer "force"           //强制负载均衡

1.3 人为的移动

当发生经常性的查询热点问题时, 您的请求总是请求到一个服务节点上 ,我们可以把这个机器中的数据理解成热数据 ,可以任务的拆分以后手动的移动到不同的机器上 实现查询热点的负载均衡 

使用命令

 1 切分  Examples:     split 'tableName'     split 'namespace:tableName'     split 'regionName' # format: 'tableName,startKey,id'     split 'tableName', 'splitKey'     split 'regionName', 'splitKey'  页面查看region情况 ,或者使用list_regions "tb_name"  2 移动  将某个region移动到某个机器上  move  "a84afc7eb10797188c0af1534e143eb9" , "linux03,16020,1591844369905"

2 快照

2.1 快照原理(基于HDFS的快照)

    Hdfs的快照（snapshot）是在某一时间点对指定文件系统拷贝，快照采用只读模式，可以对重要数据进行恢复、防止用户错误性的操作。

      快照分两种：一种是建立文件系统的索引，每次更新文件不会真正的改变文件，而是新开辟一个空间用来保存更改的文件，一种是拷贝所有的文件系统。Hdfs属于前者。

Hdfs的快照的特征如下：

1. 快照的创建是瞬间的，代价为O(1)，取决于子节点扫描文件目录的时间。
2. 当且仅当做快照的文件目录下有文件更新时才会占用小部分内存，占用内存的大小为O(M)，其中M为更改文件或者目录的数量；
3. 新建快照的时候，Datanode中的block不会被复制，快照中只是记录了文件块的列表和大小信息。
4. 快照不会影响正常的hdfs的操作。对做快照之后的数据进行的更改将会按照时间顺序逆序的记录下来，用户访问的还是当前最新的数据，快照里的内容为快照创建的时间点时文件的内容减去当前文件的内容。

2.2 基本演示

 1 snapshot  "tb_spl2" , "spl_info"  拍摄快照    参数一表  参数二 快照名  2 hbase(main):019:0>  list_snapshots   列举出所有的快照 SNAPSHOT                              TABLE + CREATION TIME                                                                                              spl_info                             tb_spl2 (2020-06-13 11:22:52 +0800)      3 restore_snapshot  "spl_info"  恢复快照

3 拆分

3.1 为什么拆分??

HBase是以表的形式存储数据的。一张表被划分为多个regions，regions分布在多个Region Server上，单个region只能分布在一个Region Server节点上，不能跨Region Server存放。

Region的两个重要属性：StartKey和EndKey，分别表示这个region所维护的rowkey范围。当做读/写请求时，寻址到该数据的rowkey落在某个start-end key范围内，那么就会定位到该范围内的region所在的Region Server上进行数据读/写。

   随着数据的插入region中管理的数据越来越多 ,出现热点问题的概率大大增加 , 并且一个regionserver的负载过重,将region拆分 均衡到不同的节点上!

3.2 怎么拆分 ??

3.2.1 手动拆分 

 Examples:     split 'tableName'     split 'namespace:tableName'     split 'regionName' # format: 'tableName,startKey,id'     split 'tableName', 'splitKey'     split 'regionName', 'splitKey'

3.2.2 自动拆分

3.2.2.1 默认按照大小

 

当region的大小达到一定大小的时候会被拆分

IncreasingToUpperBoundRegionSplitPolicy

 

split策略实现类

<property>

<name>hbase.regionserver.region.split.policy</name>
<value>
org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy
</value>

</property>

当hbase表在regionserver上的region,如果region的大小到达一个阈值，这个region将会分为两个。

计算公式为：
Min{

1^3*2*128M    256M

2^3*2*128M    2G

3^3*2*128M    6.75G

 10G          10G

 

 

(表在一个regionserver上region的数量的立方) *2（the region memstore flush size),

hbase.hregion.max.filesize(默认是10GB）

}

如果默认值情况下，一个表在一个regionserver上split的阈值是:
256MB(第一次split)，2GB（第二次），6.75GB（第三次），10GB（第四次），10GB… 10GB

<property>

<name>hbase.hregion.max.filesize</name>
<value>10737418240</value>
</property>
<property>
<name>hbase.regionserver.regionSplitLimit</name>
<value>1000</value>
</property>

3.2.2.2  keyPrefixRegionSplitPolicy(自定义) key的前缀

这种拆分是在原来的拆分基础上 ,增加了拆分点(splitPoint,拆分点就是Region被拆分时候的rowkey)的定义,保证有相同前缀的rowkey不会被拆分到不同的Region上

参数是 keyPrefixRegionSplitPolicy.prefix_length   rowkey:前缀长度

问题是 : 可能相同主题的数据会被分到不同的regionserver中 ,查询数据来源于不同的regionserver

3.2.2.3  DelimitedKeyPrefixRegionSplitPolicy key的分隔符

和上一种查分策略一致 , 上一种是按照key的固定长度拆分的 , 这种按照的是分割符

DelimitedKeyPrefixRegionSplitPolicy.delimiter参分割符

指定一个分隔符 能保证相同的主题数据在一个regionserver中

3.2.3 建表时指定预分region

shell客户端

   hbase> create 'ns1:t1', 'f1', SPLITS => ['10', '20', '30', '40']   hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']

java客户端

     byte[][] keys = new byte[][]{"e".getBytes(), "m".getBytes(), "t".getBytes()};     // 建表    指定预分region的key(数组)     admin.createTable(tableDescriptor, keys);

4 Hbase如何实现CRUD

hbase是分布式列式存储数据库 , 其具有的基本功能就是对数据的增删改查 , 那么Hbase的数据是存储在HDFS上的,我们知道在HDFS中的数据是不允许随机修改的!这与HDFS的功能相违背!

hbase数据底层存储下HDFS系统中,一Hfile的形式存储的!在HDFS中Hfile的具体位置

查看Hfile文件中数据内容  hbase hfile -p -f 解析Hfile中的内容

其实在hbase中所有的操作都是写操作 ,在所有的操作中有对应的put delete 标记 !查询数据的时候不会显示delete标记的数据 !当Hfile合并的时候才会将删除的数据真正的删除掉!

5 合并

5.1 hfile合并

数据加载到memstore，数据越来越多直到memstore占满，再写入硬盘storefile中，每次写入形成一个单独Hfile，当Hfile达到一定的数量后，就会开始把小Hfile合并成大Hfile，因为Hadoop不擅长处理小文件，文件越大性能越好。

触发compaction的方式有三种：Memstore刷盘、后台线程周期性检查、手动触发。

1.Memstore Flush:

应该说compaction操作的源头就来自flush操作，memstore flush会产生HFile文件，文件越来越多就需要compact。因此在每次执行完Flush操作之后，都会对当前Store中的文件数进行判断，一旦文件数大于配置，就会触发compaction。需要说明的是，compaction都是以Store为单位进行的，而在Flush触发条件下，整个Region的所有Store都会执行compact，所以会在短时间内执行多次compaction。

2.后台线程周期性检查：

后台线程定期触发检查是否需要执行compaction，检查周期可配置。线程先检查文件数是否大于配置，一旦大于就会触发compaction。如果不满足，它会接着检查是否满足major compaction条件，简单来说，如果当前store中hfile的最早更新时间早于某个值mcTime，就会触发major compaction（默认7天触发一次，可配置手动触发），HBase预想通过这种机制定期删除过期数据。

3.手动触发：

一般来讲，手动触发compaction通常是为了执行major compaction，一般有这些情况需要手动触发合并

• 是因为很多业务担心自动major compaction影响读写性能，因此会选择低峰期手动触发；

• 也有可能是用户在执行完alter操作之后希望立刻生效，执行手动触发major compaction；

• 是HBase管理员发现硬盘容量不够的情况下手动触发major compaction删除大量过期数据；

在合并的过程中会做什么操作？

在合并的过程中会抛弃删除标识的行和版本过旧的行
（1）可以预先定义版本的个数，超过这个值就抛弃
（2）还可以预先定义版本的时间长短，超过这个时间就抛弃，合并完后形成更大的storefile，当达到数量再次合并，直到storefile容量超过一定阀值后会把当前的Region进行分裂为2个并由Hmaster（hbase数据库主控节点）分配到不同的HRegionServer服务器处理实现负载均衡。

如果在合并过程中恰好有涉及到有关storefile的查询发生的话，我们先是把小storefile加载到内存中进行合并此时如有用户访问可以在内存中检索相关数据返回给用户，我们可以想象在内存中做一个独立镜像备份专门提供被查询需求，另一个主体在另一块内存空间里进行合并，当合并完成后释放备份的内存空间，返回到原来的状态。

shell客户端操作命令 合并hfile

  Compact all regions in passed table or pass a region row           to compact an individual region. You can also compact a single column           family within a region.           You can also set compact type, "NORMAL" or "MOB", and default is "NORMAL"           Examples:           Compact all regions in a table:           hbase> compact 'ns1:t1'           hbase> compact 't1'           Compact an entire region:           hbase> compact 'r1'           Compact only a column family within a region:           hbase> compact 'r1', 'c1'           Compact a column family within a table:           hbase> compact 't1', 'c1'           Compact table with type "MOB"           hbase> compact 't1', nil, 'MOB'           Compact a column family using "MOB" type within a table           hbase> compact 't1', 'c1', 'MOB'

5.2 region合并

5.2.1 那为什么需要合并Region呢

这个需要从Region的Split来说。当一个Region被不断的写数据，达到Region的Split的阀值时（由属性hbase.hregion.max.filesize来决定，默认是10GB），该Region就会被Split成2个新的Region。随着业务数据量的不断增加，Region不断的执行Split，那么Region的个数也会越来越多。

一个业务表的Region越多，在进行读写操作时，或是对该表执行Compaction操作时，此时集群的压力是很大的。这里笔者做过一个线上统计，在一个业务表的Region个数达到9000+时，每次对该表进行Compaction操作时，集群的负载便会加重。而间接的也会影响应用程序的读写，一个表的Region过大，势必整个集群的Region个数也会增加，负载均衡后，每个RegionServer承担的Region个数也会增加。

因此，这种情况是很有必要的进行Region合并的。比如，当前Region进行Split的阀值设置为30GB，那么我们可以对小于等于10GB的Region进行一次合并，减少每个业务表的Region，从而降低整个集群的Region，减缓每个RegionServer上的Region压力。

那么我们如何进行Region合并呢？HBase有提供一个合并Region的命令，具体操作如下：

 # 合并相邻的两个Region hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME' # 强制合并两个Region hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME', true

5.2.2 Region合并分为两种，minor合并和major合并

3.1 Minor合并：
是把最后生成的几个小的StoreFile文件 合并一个更大的StoreFile， 默认同时合并的文件数为10, 主要控制参数如下;
hbase.hstore.compaction.min最小合并文件 数量大小， 默认为3
hbase.hstore.compaction.max 最大合并文件 数量大小， 默认为10
hbase.hstore.compaction.max.size 最大合并文件 的大小 ， 默认值 为Long.MAX_VALUE
hbase.hstore.compaction.min.size 最小合并文件 的大小， 默认值是memStore刷写的大小， 它是一个阈值， 它包含所有小于限制的文件 ，直到达到每次压缩允许的总文件数量

3.2 Major合并：
是把整个Store中所有StoreFile文件 合并成一个单独的StoreFile文件，后台定时任务定期检查， 这个检查周期是由下面这两人个参数决定
hbase.server.thread.wakefrequency * hbase.server.thread.wakefrequency.multiplier(默认值为1000)
 

6 刷写

7 读数据流程

8 写数据流程

9 热点问题

当表被创建时，HBase默认只会为该表分配一个region，那么，初始状态时所有的请求都会集中在一个Region Server上，当大量数据写入时，该节点将成为热点，甚至产生full gc。

当然，region热点不仅体现在创建表阶段。对于一张拥有很多region的大表来说，其在Region Sever上的分布往往不会十分均匀，region较多的Region Server在有大量数据写入时，它的负载也会大于其他region数少的Region Server，这也是热点。

因此，针对上述两种情况，该如何避免热点发生就是一个常见的话题。

【解决办法】

如果知道了HBase数据表的key分布情况，可以根据需要，规划要拆分成多少个region，每个region的起始key是多少，那么就可以在建表时对HBase进行region的预分区，这样就能避免热点，提高数据写入效率。

合理设计rowkey能让各个region的并发请求平均分配，使IO效率达到最高。比如，key的前几位字符串都是从0001~0010的数字，这样就可以分成10个region，使用SPLISTS，如下：

create’t1′,’f1′,{SPLITS=>[‘0001′,’0002′,’0003′,’0004′,’0005′,’0006′,’0007′,’0008′,’0009’]}

如果分区分区信息比较多，那么可以通过指定分区文件来做：

create’t1′,’f1′,{SPLITS_FILE=>’region_split_info.txt’}

region_split_info.txt文件内容如下，每行都是key取值范围的分割点。文件第一行为第一个region的endkey，每行依次类推，最后一行的0009为倒数第二个region的endkey，同时也是最后一个region的startkey。

cat region_split_info.txt

0001|

0002|

0003|

0004|

0005|

0006|

0007|

0008|

0009|

在HBase Master Web UI页面上查看，可以看到第一个region是没有startkey，最后一个region是没有endkey的。

10 row设计

11 批量导入

12 协处理器