背景

    鉴于上次一篇文章——“云HBase小组成功抢救某公司自建HBase集群，挽救30+T数据”的读者反馈，对HBase的逆向工程比较感兴趣，并咨询如何使用相应工具进行运维等等。总的来说，就是想更深层理解HBase运维原理，提高运维HBase生产环境的能力，应对各种常见异常现象。不同的读者对hbase的了解程度不同，本文不打算着重编写一个工具怎么使用，而是从HBase的运维基础知识介绍开始讲解。为了能帮助大部分读者提高HBase运维能力，后续会写个“HBase运维系列” 专题系列文章，欢迎到最下方扫码关注钉钉交流。

介绍

    相信很多自建HBase的企业会经常碰到各种各样的hbase运维问题。比如使用HBase的时候，HBase写入一段时间后开始RegionServer节点开始挂掉，重启RegionServer发现启动很慢，很多region出现RTI问题，导致读写某个region的业务hang住了 。还有一些人的HBase集群多次运维尝试后，直接HBase启动不了了，meta表上线就开始报错，导致最终业务不能正常上线运行等等系列问题。本文就HBase运维的原理基础开始入手，重点讲解数据完整性，以及元数据“逆向工程”恢复数据完整性的原理方法。开启后续一系列的HBase运维知识讲解。

HBase目录结构

    本文就1.x版本进行讲解，不同版本大致相通。HBase在HDFS上会单独使用一个目录为HBase文件目录的根目录，通常为 “/hbase”。基于这个目录下，会有以下目录组织结构：

 

/hbase/archive (1)/hbase/corrupt (2) /hbase/data/default/TestTable/.tabledesc/.tableinfo.0000000001 (3)/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/info/2e58b3e274ba4d889408b05e526d4b7b (4)/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/recovered.edits/340.seqid (5)/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.regioninfo (6)/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.tmp (7)/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.splits (8)/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.merges (9)/hbase/data/hbase/acl (10)/hbase/data/hbase/meta (11)/hbase/hbase.id (12)/hbase/hbase.version (13)/hbase/MasterProcWALs (14)/hbase/oldWALs (15)/hbase/.tmp (16)/hbase/.trashtables/data (17)/hbase/WALs/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com,16020,1523502350378/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com%2C16020%2C1523502350378.default.1524538284034 (18)

 

(1) 进行snapshot或者升级的时候使用到的归档目录。compaction删除hfile的时候，也会把就的hfile归档到这里等。

 

(2) splitlog的corrupt目录，以及corrupt hfile的目录。

(3) 表的基本属性信息元文件tableinfo。

(4) 对应表下的hfile数据文件。

(5) 当splitlog发生时，一个RS的wal会按照region级别split WALs写到对应目录下的的recovered.edits目录上，使得此region再次被open的时候，回放这些recovered.edits 日志。

(6) regioninfo文件。

(7) compaction等的临时tmp目录。

(8) split时临时目录，如果上次region的split没有完成被中断了，这个region再open的时候会自动清理这个目录，一般不需要人工干预。

(9) merges时的临时目录，和split一样，如果没有正常完成的时候被中断了，那么他会在下次被open的时候自动清理。一般也不需要人工干预。

(10) acl 开启HBase权限控制时的权限记录系统表

(11) meta 元数据表，记录region相关信息

(12) hbase.id 集群启动初始化的时候，创建的集群唯一id。可以重新fix生成

(13) hbase.version hbase 软件版本文件，代码静态版本，现在都是8 (14) master执行过程程序的状态保存，用于中断恢复执行使用。

(15) oldWALs 历史wal，即wal记录的数据已经确认持久化了，那么这些wal就会被移到这里。splitlog完成的那些就日志，也会被放到这里。

(16) tmp 临时辅助目录，比如写一个hbase.id文件，在这里写成功后，rename到 /hbase/hbase.id

(17) /hbase/.trashtables/data 当truncate table或者delete table的时候，这些数据会临时放在这里，默认1小时内被清

(18) 记录着一台RegionServer上的WAL日志文件。可以看到它是regionserver名字是有时间的，即下一次启动时RS的wal目录就会使用新的目录结构存放wal，这个旧的RS wal 目录就会被splitlog过程拆分回放