HBase存储架构

上图是HBase的存储架构图。

由上图可以知道，客户端是通过Zookeeper找到HMaster，然后再与具体的Hregionserver进行沟通读写数据的。

具体到物理实现，细节包括以下这些：

首先要清楚HBase在hdfs中的存储路径，以及各个目录的作用。在hbase-site.xml 文件中，配置项 <name>hbase.rootdir</name>默认 “/hbase”，就是hbase在hdfs中的存储根路径。以下是hbase0.96版本的个路径作用。1.0以后的版本请参考这里: https://blog.bcmeng.com/post/hbase-hdfs.html

1、 /hbase/.archive

HBase 在做 Split或者 compact *** 作完成之后，会将 HFile 移到.archive 目录中，然后将之前的 hfile 删除掉，该目录由 HMaster 上的一个定时任务定期去清理。

2、 /hbase/.corrupt

存储HBase损坏的日志文件，一般都是为空的。

3、 /hbase/.hbck

HBase 运维过程中偶尔会遇到元数据不一致的情况，这时候会用到提供的 hbck 工具去修复，修复过程中会使用该目录作为临时过度缓冲。

4、 /hbase/logs

HBase 是支持 WAL（Write Ahead Log） 的，HBase 会在第一次启动之初会给每一台 RegionServer 在.log 下创建一个目录，若客户端如果开启WAL 模式，会先将数据写入一份到.log 下，当 RegionServer crash 或者目录达到一定大小，会开启 replay 模式，类似 MySQL 的 binlog。

5、 /hbase/oldlogs

当.logs 文件夹中的 HLog 没用之后会 move 到.oldlogs 中，HMaster 会定期去清理。

6、 /hbase/.snapshot

hbase若开启了 snapshot 功能之后，对某一个用户表建立一个 snapshot 之后，snapshot 都存储在该目录下，如对表test 做了一个 名为sp_test 的snapshot，就会在/hbase/.snapshot/目录下创建一个sp_test 文件夹，snapshot 之后的所有写入都是记录在这个 snapshot 之上。

7、 /hbase/.tmp

当对表做创建或者删除 *** 作的时候，会将表move 到该 tmp 目录下，然后再去做处理 *** 作。

8、 /hbase/hbase.id

它是一个文件，存储集群唯一的 cluster id 号，是一个 uuid。

9、 /hbase/hbase.version

同样也是一个文件，存储集群的版本号，貌似是加密的，看不到，只能通过web-ui 才能正确显示出来

10、 -ROOT-

该表是一张的HBase表，只是它存储的是.META.表的信息。通过HFile文件的解析脚本 hbase org.apache.hadoop.hbase.io.hfile.HFile -e -p -f 可以查看其存储的内容，如下所示：

以上可以看出，-ROOT-表记录的.META.表的所在机器是dchbase2，与web界面看到的一致：

11、 .META.

通过以上表能找到.META.表的信息，该表也是一张hbase表，通过以上命令，解析其中一个region：

以上可以看出，adt_app_channel表的数据记录在dchbase3这台reginserver上，也与界面一致，如果有多个region，则会在表名后面加上rowkey的范围：

通过以上描述，只要找到-ROOT-表的信息，就能根据rowkey找到对应的数据，那-ROOT-在哪里找呢？从本文一开始的图中可以知道，就是在zookeeper中找的。进入zookeeper命令行界面：

可以看出-ROOT-表存储在 dchbase3 机器中，对应界面如下：

以上就是HBase客户端根据指定的rowkey从zookeeper开始找到对应的数据的过程。

那在Region下HBase是如何存储数据的呢？

以下就具体 *** 作一张表，查询对应的HFile文件，看HBase的数据存储过程。

在HBase创建一张表 test7，并插入一些数据，如下命令：

查看wal日志，通过 hbase org.apache.hadoop.hbase.regionserver.wal.HLog --dump -p 命令可以解析HLog文件，内容如下：

查看HFile文件，内容如下：

由此可见，HFile文件就是存储HBase的KV对，其中Key的各个字段包含了的信息如下：

由于hbase把cf和column都存储在HFile中，所以在设计的时候，这两个字段应该尽量短，以减少存储空间。

但删除一条记录的时候，HBase会怎么 *** 作呢？执行以下命令：

删除了rowkey为200的记录，查看hdfs，原来的HFile并没有改变，而是生成了一个新的HFile，内容如下：

所以在HBase中，删除一条记录并不是修改HFile里面的内容，而是写新的文件，待HBase做合并的时候，把这些文件合并成一个HFile，用时间比较新的文件覆盖旧的文件。HBase这样做的根本原因是，HDFS不支持修改文件。

1. 对表做预分区处理（即在建表时指定Region数量和拆分边界）；

2.配置hbase.hregion.max.filesize为50GB

以fileServer为例，在使用默认的split策略--IncreasingToUpperBoundRegionSplitPolicy 的情况下，16个预分区Region, 则单个Resion容量达到 min(32,50),即32GB时分裂。

3.修改Linux最大文件句柄数

因为hbase是以文件的形式存储数据，最大文件句柄数影响着hbase的并发量。

用root权限修改/etc/security/limits.conf文件，增加以下内容（前面的*不能忽略）：

*              soft    nproc          10240

*              hard    nproc          10240

*              soft    nofile          10240

*              hard    nofile          10240 

编辑/etc/pam.d/common-session，加入一行

session required  pam_limits.so

编辑/etc/profile，加入

ulimit -SHn 51200

重新登陆，生效

4.HRegionServer挂掉异常和解决：

is not online on......

常规解决方案：

  删除zk中hbase的缓存

  重启hbase

使用上述解决方案后本次异常依旧存在，并且HMaster和HRegionServer都不断的自动挂掉。

HMaster报错：

解决方案：

新增配置（看情况决定使用不使用，建议在HMaster不能启动时排除错误使用）（让启动hbase时只让HMaster去进行日志split，缺点是恢复数据时候速度慢）：

<property>

<name>hbase.master.distributed.log.splitting</name>

<value>false</value>

</property>

   删除WAL文件（会丢数据）：

6. RPC请求的最大线程数

hbase.regionserver.handler.count  默认是10，在服务器测试时建议设置到50（经测试在单个Region Server时无用，单个RegionServer 最多在6个线程put时保持稳定）

7.日志分割（hbase出错后恢复数据）

MemStore中大量更新丢失时，对数据进行恢复时会做日志分割

hbase.regionserver.hlog.splitlog.writer.threads 日志分割的线程数， 默认为3 ，建议设定为10

8.Region Server频繁掉线

出现Hbase Region Server频繁掉线的情况，表现为在多线程put的情况下，忽然Hbase Region Server掉线

猜测是GC或者split过程中没有及时和ZK通信，导致与ZK连接时间超时，zk返回dead region到master，当Hbase Region恢复正常后，找不到wal,产生如下报错。

zookeeper.session.timeout ：默认值是3分钟

但是 hbase regionserver和zookeeper的timeout不是单方面决定的，是取决于hbase的zookeeper.session.timeout和zookeeper的MaxSessionTimeout中的最小值

配置hbase:

zookeeper.session.timeout

600000

配置zookeeper:

tickTime=30000

9.内存及GC优化

在测试的过程中依旧出现Hbase Region Server掉线的情况，报错如下

2021-02-0318:49:14,091INFO[sync.0]wal.FSHLog: Slow sync cost:1955ms, current pipeline: []

2021-02-0318:49:14,091WARN[regionserver/botsc/192.168.0.107:16020.append-pool5-t1]wal.MetricsWAL: regionserver/botsc/192.168.0.107:16020.append-pool5-t1 took1953ms appending an edit to wal len~=109

2021-02-0318:49:14,106ERROR[sync.3]wal.FSHLog:Errorsyncing, request close of WAL

java.io .IOException:io.grpc.StatusRuntimeException: CANCELLED: Failed to stream message

    at seaweed.hdfs.SeaweedOutputStream.flushWrittenBytesToServiceInternal(SeaweedOutputStream.java:78)

    at seaweed.hdfs.SeaweedOutputStream.flushWrittenBytesToServiceAsync(SeaweedOutputStream.java:263)

    at seaweed.hdfs.SeaweedOutputStream.flushInternalAsync(SeaweedOutputStream.java:243)

    at seaweed.hdfs.SeaweedOutputStream.flush(SeaweedOutputStream.java:129)

at java.io .FilterOutputStream.flush(FilterOutputStream.java:140)

at java.io .DataOutputStream.flush(DataOutputStream.java:123)

    at org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter.sync(ProtobufLogWriter.java:170)

    at org.apache.hadoop.hbase.regionserver.wal.FSHLog$SyncRunner.run(FSHLog.java:1286)

    at java.lang.Thread.run(Thread.java:748)

修改hbase的配置文件hbase-env.sh，GC优化如下：

export HBASE_HEAPSIZE=21384

export master_heapsize=8292

export regionserver_heapsize=21384

export HBASE_OPTS="$HBASE_OPTS -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseParNewGC -XX:ParallelGCThreads=6"

export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx8g -Xms8g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"

export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx20g -Xms20g -Xmn1g -XX:+UseParNewGC

-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"

---