Hbase运维手册

Hbase运维手册 1. region情况

需要检查

1. region的数量（总数和每台regionserver上的region数） 2. region的大小

如果发现异常可以通过手动merge region和手动分配region来调整 从CDH前台和master前台以及regionServer的前台都可以看到region数量，如master前台：

在region server前台可以看到storeFile大小：

2. 缓存命中率

缓存命中率对hbase的读有很大的影响，可以观察这个指标来调整blockcache的大小。

从regionserver web页面可以看到block cache的情况：

注意：

HBase上Regionserver的内存分为两个部分，一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读。

写请求会先写入Memstore，Regionserver会给每个region提供列族数提供一定数量的Memstore，当Memstore满64MB以后，会启动 flush刷新到磁盘。当Memstore的总大小超过限制时（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），会强行启动flush进程，从最大的Memstore开始flush直到低于限制。 ? 读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把读的结果放入BlockCache。由于BlockCache采用的是LRU策略，因此BlockCache达到上限(heapsize * hfile.block.cache.size * 0.85)后，会启动淘汰机制，淘汰掉最老的一批数据。

?

一个Regionserver上有一个BlockCache和N个Memstore，它们的大小之和不能大于等于heapsize * 0.8，否则HBase不能正常启动。

默认配置下，BlockCache为0.2，而Memstore为0.4。在注重读响应时间的应用场景下，可以将 BlockCache设置大些，Memstore设置小些，以加大缓存的命中率。

HBase RegionServer包含三个级别的Block优先级队列：

? ?

Single：如果一个Block第一次被访问，则放在这一优先级队列中； Multi：如果一个Block被多次访问，则从Single队列移到Multi队列中；

InMemory：如果一个Block是inMemory的，则放到这个队列中。 以上将Cache分级思想的好处在于：

?

首先，通过inMemory类型Cache，可以有选择地将in-memory的column families放到RegionServer内存中，例如Meta元数据信息； ? 通过区分Single和Multi类型Cache，可以防止由于Scan操作带来的Cache频繁颠簸，将最少使用的Block加入到淘汰算法中。

?

默认配置下，对于整个BlockCache的内存，又按照以下百分比分配给Single、Multi、InMemory使用：0.25、0.50和0.25。

注意，其中InMemory队列用于保存HBase Meta表元数据信息，因此如果将数据量很大的用户表设置为InMemory的话，可能会导致Meta表缓存失效，进而对整个集群的性能产生影响。

3. 读写请求数

通过读写请求数可以大概看出每台regionServer的压力，如果压力分布不均匀，应该检查regionServer上的region以及其它指标

4. 压缩队列

压缩队列存放的是正在压缩的storefile，compact操作对hbase的读写影响较大

通过cdh的hbase图表库可以看到集群总的压缩队列大小：

可以通过CDH的hbase主页查询compact日志：

点击“压缩”进入：

5. 刷新队列

单个region的memstore写满(128M)或regionServer上所有region的memstore大小总合达到门限时会进行flush操作,flush操作会产生新的storeFile

同样可以通过CDH的hbase前台查看flush日志：

6. rpc调用队列

没有及时处理的rpc操作会放入rpc操作队列，从rpc队列可以看出服务器处理请求的情况

7. 文件块保存在本地的百分比

datanode和regionserver一般都部署在同一台机器上，所以region server管理的region会优先存储在本地，以节省网络开销。如果block locality较低有可能是刚做过balance或刚重启，经过compact之后region的数据都会写到当前机器的datanode，block locality也会慢慢达到接近100：

8. 内存使用情况

重启每一台机 子，对于hbase regionserver重启，不要直接kill进程，这样会造成在zookeeper.session.timeout这个时间长的中断，也不要通过 bin/hbase-daemon.sh stop regionserver去重启，如果运气不太好，-ROOT-或者.META.表在上面的话，所有的 请求会全部失败 regionserver关闭下线

bin/graceful_stop.sh nodename

进行操作前先将balancer关闭，操作完成后再打开balancer 和上面一样，系统会在关闭之前迁移所有region，然后stop进程。 flush表

所有memstore刷新到hdfs，通常如果发现regionserver的内存使用过大，造成该机的 regionserver很多线程block，可以执行一下flush操作，这个操作会造成hbase的storefile数量剧增，应尽量避免这个操 作，还有一种情况，在hbase进行迁移的时候，如果选择拷贝文件方式，可以先停写入，然后flush所有表，拷贝文件

强制split

Hbase 允许客户端强制执行split,在hbase shell中执行以下命令：

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

region splits 执行过程：

region server处理写请求的时候，会先写入memstore，当memstore 达到一定大小的时候，会写入磁盘成为一个store file。这个过程叫做 memstore flush。当store files 堆积到一定大小的时候，region server 会 执行‘compact’操作，把他们合成一个大的文件。 当每次执行完flush 或者compact操作，都会判断是否需要split。当发生split的时候，会生成两个region A 和 region B但是parent region数据file并不会发生复制等操作，而是region A 和region B 会有这些file的引用。这些引用文件会在下次发生compact操作的时候清理掉，并且当region中有引用文件的时候是不会再进行split操作的。

这个地方需要注意一下:

(大量的写入会刷大量的HFile，一个region就会对这大量的hfile进行compact操作。如果这时候触发了split操作，这个region会成为父region，而两个子region会保留父region的引用文件。而在这其间，子region会继续写入数据。那么又可能触发子region的compact，这里的关键点来了——子region如果做compact的文件都是新写入的文件，而迟迟不去compact父region 引用的文件，会导致一个问题——就是这个子region无法被split掉了（因为含有父region引用的region是不能被split的）。那么子region越来越大，由于写入文件数量急剧增长，父region的ref文件总也得不到机会compact，就形成了大

region的恶性循环情况——由于region太大，compact无法完成，但是由于compact无法完成导致region无法split，无法分摊compact的压力给其他regionserver。)

虽然split region操作是region server单独确定的，但是split过程必须和很多其他部件合作。region server 在split开始前和结束前通知master,并且需要更新.META.表，这样，客户端就能知道有新的region。在hdfs中重新排列目录结构和数据文件。split是一个复杂的操作。在split region的时候会记录当前执行的状态，当出错的时候，会根据状态进行回滚。下图表示split中，执行的过程。（红色线表示region server 或者master的操作，绿色线表示client的操作。）

1.region server 决定split region，第一步，region server在zookeeper中创建在

/hbase/region-in-transition/region-name 目录下，创建一个znode，状态为SPLITTING.

2.因为master有对 region-in-transition 的znode做监听，所以，mater的得知parent region需要split

3.region server 在hdfs的parent region的目录下创建一个名为“.splits”的子目录

4.region server 关闭parent region。强制flush缓存，并且在本地数据结构中标记region为下线状态。如果这个时候客户端刚好请求到parent region，会抛出NotServingRegionException。这时客户端会进行补偿性重试。

5.region server在.split 目录下分别为两个daughter region创建目录和必要的数据结构。然后创建两个引用文件指向parent regions的文件。

6.region server 在HDFS中，创建真正的region目录，并且把引用文件移到对应的目录下。

7.region server 发送一个put的请求到.META.表中，并且在.META.表中设置parent region为下线状态，并且在parent region对应的row中两个daughter region的信息。但是这个时候在.META.表中daughter region 还不是独立的row。这个时候如果client scan .META.表，会发现parent region正在split，但是client还看不到daughter region的信息。当这个put 成功之后，parent region split会被正在的执行。如果在 RPC 成功之前 region server 就失败了，master和下次打开parent region的region server 会清除关于这次split

的脏状态。但是当RPC返回结果给到parent region ，即.META.成功更新之后，，region split的流程还会继续进行下去。相当于是个补偿机制，下次在打开这个parent region的时候会进行相应的清理操作。

8.region server 打开两个daughter region接受写操作。

9.region server 在.META.表中增加daughters A 和 B region的相关信息，在这以后，client就能发现这两个新的regions并且能发送请求到这两个新的region了。client本地具体有.META.表的缓存，当他们访问到parent region的时候，发现parent region下线了，就会重新访问.META.表获取最新的信息，并且更新本地缓存。

10.region server 更新 znode 的状态为SPLIT。master就能知道状态更新了，master的平衡机制会判断是否需要把daughter regions 分配到其他region server 中。

11.在split之后，meta和HDFS依然会有引用指向parent region. 当compact 操作发生在daughter regions中，会重写数据file，这个时候引用就会被逐渐的去掉。垃圾回收任务会定时检测daughter regions是否还有引用指向parent files，如果没有引用指向parent files的话，parent region 就会被删除。

0.96版本中去掉了root表，因为觉的目的是根据root表获取meta地址，过程是通过zookeeper获取root表地址，在根据root表记录meta表地址进行访问，还不如和zookeeper通讯一次。meta表信息存放在zookeeper的

/hbase/meta-region-server文件中。新版本中还添加了hbase:namespace 命名空间表，系统表放在hbase空间下，用户表如果没有指定命名空间则放在default空间下。

重新生成META表：

./hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair

宽表好处： 行数变少，bolck index索引减少。布隆过滤器meta index索引减少。 减少空间占用和内存占用。

宽表劣处： hbase的split是基于行的，会影响split机制 ：

HBase的split操作只会在行的边界上发生，所以更倾向于长窄表：

宽表情况下， 单独一行大小超过hbase.hregion.max.filesize值， 也不会做分割

相同rowkey下插入很多不同版本的记录，即使大小超过hbase.hregion.max.filesize值，也不会做分割

窄表好处：将列放入rowkey查询更加灵活方便。利于split机制 窄表劣处：索引空间占用比宽表要大。

MR统计行数：

$HBASE_HOME/bin/hbase org.apache.hadoop.hbase.mapreduce.RowCounter ‘tablename’

本文来源：https://www.bwwdw.com/article/rkp7.html