重启每一台机 子，对于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’