笔者今天给大家讲一下 HBase 生产环境中的实践，包括资源隔离、参数配置、性能优化等方面，部分内容参考《HBase原理与实践》（非常建议大家好好读一读，一定会大有收获），以及笔者的实战经验。
HBase 业务资源隔离
1. 读写分离场景
RegionServer 默认情况下只提供一个请求队列给所有业务使用，导致部分延迟较高的请求影响其他对延迟敏感的业务。针对这种情况，HBase 提供了读写队列隔离方案。
我们知道，HBase 有三种典型的API操作类型，分别为 get、scan 和write，其中 get 和 scan 属于 read 类型。默认场景下，HBase 只提供一个队列，所有请求都会进入该队列进行优先级排序。在一些场景下，我们要求这三种类型的访问尽可能的互相不影响，那么就需要在线上配置读写分离。
HBase 中的相关配置如下：
-
hbase.ipc.server.callqueue.read.ratio
如果将 hbase.ipc.server.callqueue.read.ratio 设置为0.5，则表示有50%的线程数处理读请求，剩余50%用于接收写请求。
-
hbase.ipc.server.callqueue.scan.ratio
如果将 hbase.ipc.server.callqueue.scan.ratio 设置为0.5，则代表在50%的读线程之中，再有50%的线程处理 scan，也就是全部线程的25%。
2. CPU/内存资源隔离
针对系统资源方面，HBase 提供了 RegionServer Group（RSGroup）方案。RSGroup 方案在HBase 1.4 以上版本才原生支持，但是之前 1.x 版本可以打社区 patch。不过如果使用 CDH 搭建的平台，比如 CDH 5.13.3，HBase 1.2 版本即可支持。
为了支持 RSGroup 功能，需要配置如下参数：
-
-
<property> -
<name>hbase.coprocessor.master.classes</name> -
<value>org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint</value> -
</property> -
<property> -
<name>hbase.master.loadbalancer.class</name> -
<value>org.apache.hadoop.hbase.rsgroup.RSGroupBasedLoadBalancer</value> -
</property>
-
生产线上，分组原则一般遵循：
-
在线业务和离线业务尽量划分到不同组
-
重要业务和边缘业务尽量划分到不同组
-
非常重要的业务尽量单独划分到独立组或者单独部署集群
使用RSGroup会自动关闭全局自动负载均衡，后续需要手工触发。
另外要隔离系统表，要么定义一个 system rsgroup 用来存储所有系统表，要么把系统表都默认放在 default rsgroup 中。所有其他用户的表都定义在非 default 的 rsgroups 中。
根据实践证明，笔者建议，针对 Dead 或有问题的节点，定义一个特殊的 rsgroup 是非常有用的。所有放在这个特殊的 rsgroup 中的节点是无法运行的，直到修复完成。
最后，使用 RSGroup 要注意几点：
-
-
(1) 迁移完表后记得做 major compact（本地化） -
hbase(main):001:0> major_compact 'tablename' -
(2) 迁移完表后做 hbase hbck 校验，防止添加迁移表的时候有部分 region 未上线的情况 -
(3) 删除 group 之前需要将 group 下的 regionserver 和 table 都移除掉 -
(4) default 组和其他的 rsgroup 不一样，default 是动态的，其他的 group 则是静态的
-
HBase HBCK
线上环境，需要定期地检测和监控 HBase 集群中 Region 的一致性和完整性，同时可以对损坏的集群进行修复。
HBase HBCK 主要工作在两种模式下：
-
一致性检测只读模式
-
多阶段修复模式
HBase 集群一致性状态
-
HBase Region 一致性
1. 集群中所有 region 都被 assign，而且被分配到唯一一个 RegionServer 节点上
2. 该 region 的状态在内存中、hbase:meta 表中以及 zookeeper 这三个地方需要保持一致
-
HBase 表的完整性
对于集群中任意一张表，每个 rowkey 都仅能存在于一个 region 区间
最好制定一个周期计划，例行地执行 hbck 命令，并在多次出现不一致的情况下发出报警信息，通知运维人员定位分析，及时解决问题。
-
-
hbase hbck -
hbase hbck -details -
# 如果集群规模大，region很多，hbck耗时很长，可以针对某些表执行： -
hbase hbck TableFoo TableBar
-
HBCK 的局部低危修复
低风险的 Region 一致性问题修复是指：
修复仅仅涉及 HBase Master 内存中 Region 状态、ZooKeeper 临时节点中 Region 状态以及 hbase:meta 元数据表中 Region 状态的修改、并不实际修改任何 HDFS 文件。
注意：hbase2.0版本之后，hbase hbck中的修复命令已经弃用，需要使用如下命令hbase hbck -j /root/hbase-operator-tools-1.0.0.1.0.0.0-618/hbase-hbck2/hbase-hbck2-1.0.0.1.0.0.0-618.jar filesystem -fix
其中hbase-hbck2/hbase-hbck2-1.0.0.1.0.0.0-618.jar这个包在我的资源中有，大家可以去下载
https://download.youkuaiyun.com/download/m0_37534613/12938763
Region一致性问题修复有两个常用选项：
-
filesystem -fix 修复 assign 相关问题，如没有 assign、assign 不正确或者同时 assign 到多个 RegionServer 节点问题的 regions。
-
fixMeta 主要修复 .regioninfo 文件和 hbase:meta 元数据表的不一致。修复的原则是以 HDFS 文件为准：如果 region 在 HDFS 上存在，但在 hbase.meta 表中不存在，就会在 hbase:meta 表中添加一条记录。反之如果在 HDFS 上不存在，而在 hbase:meta 表中存在，就会将 hbase:meta 表中对应的记录删除。
HBCK高危修复
Region 区间 overlap 相关问题的修复属于高危修复操作，因为这类修复通常需要修改 HDFS 上的文件，有时甚至需要人工介入。对于这类高危修复操作，建议先执行 hbck-details ，然后根据结果详细了解问题细节，再执行相应的修复操作。
笔者建议在 overlap 分析的基础上使用 merge 命令，强制将存在 overlap 的相关Region 合并到一起。需要注意的是，对于多个Region，需要两两合并，之后对合并后的Region 执行 Major Compaction ，再两两合并。
这里需要特别注意： -repair｜-fix 命令强烈不建议生产线上使用。
使用案例
接下来针对线上出现的一些问题，进行案例分析和提出问题解决的方案。
1. Region 没有部署到任何 RegionServer 节点
执行 hbck 命令后，确认 Region 元数据信息在 HDFS 和 hbase:meta 中都存在，但没有部署到任何一台 RegionServer 上，hbck 命令的输出如下：
-
-
ERROR:Region {meta => NEW_REGION_XXXXXXXXXX,\x001\x01,1566748778085.652f5c6d6623f060adeefc622d8ffead., hdfs => hdfs://xxxxx/default/NEW_REGION_XXXXXXXXXX/652f5c6d6623f060adeefc622d8ffead, deploy => } not deployed on any region server. -
...... -
ERROR: There is a hole in the region chain between and . You need to create a new .regioninfo and region dir in hdfs to plug the hole. -
ERROR: Found inconsistency in table NEW_REGION_XXXXXXXXXX
-
如果在 hbck 命令输出的详细的信息中看到 “not deployed on any region server”，可以使用如下命令修复：
-
-
hbase hbck -fixAssignments
-
当然，我们也可以在 hbase shell 中执行 assign 命令部署指定 Region。
需要特别注意的是，h
最低0.47元/天 解锁文章
扫一扫
278
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
