HBase HDFS目录树

一、0.94-cdh4.2.1版本
系统级别的一级目录如下，用户自定义的均在这个/hbase 下的一级子目录下
/hbase/-ROOT-
/hbase/.META.
/hbase/.archive
/hbase/.corrupt
/hbase/.hbck
/hbase/.logs
/hbase/.oldlogs
/hbase/.snapshot
/hbase/.tmp
/hbase/hbase.id
/hbase/hbase.version

1、/hbase/-ROOT-
hbase读写数据的时候采用三级寻址方式，首先找到从 zk 中找到ROOT 表所在位置，通过 ROOT 表找到 META 表所在位置，然后再从 META 表定位到你要读写数据Region 所在的Regionserver。所以-ROOT-目录对应 HBase 中的系统表ROOT，就不多做解释了。
2、/hbase/.META.
就是存储1中介绍的 META 表的存储路径。
3、/hbase/.archive
HBase 在做 Split或者 compact 操作完成之后，会将 HFile 移到.archive 目录中，然后将之前的 hfile 删除掉，该目录由 HMaster 上的一个定时任务定期去清理。
4、/hbase/.corrupt
存储HBase做损坏的日志文件，一般都是为空的。
5、/hbase/.hbck
HBase 运维过程中偶尔会遇到元数据不一致的情况，这时候会用到提供的 hbck 工具去修复，修复过程中会使用该目录作为临时过度缓冲。
6、/hbase/.logs
大家都知道 HBase 是支持 WAL（Write Ahead Log） 的，HBase 会在第一次启动之初会给每一台 RegionServer 在.log 下创建一个目录，若客户端如果开启WAL 模式，会先将数据写入一份到.log 下，当 RegionServer crash 或者目录达到一定大小，会开启 replay 模式，类似 MySQL 的 binlog。
7、/hbase/.oldlogs
当.logs 文件夹中的 HLog 没用之后会 move 到.oldlogs 中，HMaster 会定期去清理。
8、/hbase/.snapshot
hbase若开启了 snapshot 功能之后，对某一个用户表建立一个 snapshot 之后，snapshot 都存储在该目录下，如对表test 做了一个 名为sp_test 的snapshot，就会在/hbase/.snapshot/目录下创建一个sp_test 文件夹，snapshot 之后的所有写入都是记录在这个 snapshot 之上。
9、/hbase/.tmp
当对表做创建或者删除操作的时候，会将表move 到该 tmp 目录下，然后再去做处理操作。
10、/hbase/hbase.id
它是一个文件，存储集群唯一的 cluster id 号，是一个 uuid。
11、/hbase/hbase.version
同样也是一个文件，存储集群的版本号，貌似是加密的，看不到，只能通过web-ui 才能正确显示出来。

二、0.98.8版本
自0.96版本之后，hbase 源码结构上做了很大的优化，目录结构也发生了变化，做了精简和优化，这里以0.98.8为例介绍，目录如下：
/hbase/.tmp
/hbase/WALs
/hbase/archive
/hbase/corrupt
/hbase/data
/hbase/hbase.id
/hbase/hbase.version
/hbase/oldWALs
1、/hbase/.tmp
这个目录不变还是原来的tmp目录，作用是一样的。
2、/hbase/WALs
这里对应0.94的.logs 目录，取名为 WALs 更加见名知意了，点个赞！
3、/hbase/archive
和0.94一样，只是去掉了.而已，估计是作者不想把它作为一个隐藏文件夹了吧
4、/hbase/corrupt
和0.94一样，去了.
5、/hbase/data
这个才是 hbase 的核心目录，0.98版本里支持 namespace 的概念模型，系统会预置两个 namespace 即：hbase和default
5.1 /hbase/data/default
这个默认的namespace即没有指定namespace 的表都将会flush 到该目录下面。
5.2 /hbase/data/hbase
这个namespace 下面存储了 HBase 的 namespace、meta 和acl 三个表，这里的 meta 表跟0.94版本的.META.是一样的，自0.96之后就已经将 ROOT 表去掉了，直接从Zookeeper 中找到meta 表的位置，然后通过 meta 表定位到 region。 namespace 中存储了 HBase 中的所有 namespace 信息，包括预置的hbase 和 default。acl 则是表的用户权限控制。
如果自定义一些 namespace 的话，就会再/hbase/data 目录下新建一个 namespace 文件夹，该 namespace 下的表都将 flush 到该目录下。
6、/hbase/hbase.id
它是一个文件，存储集群唯一的 cluster id 号，是一个 uuid。
7、/hbase/hbase.version
同样也是一个文件，存储集群的版本号，貌似是加密的，看不到，只能通过web-ui 才能正确显示出来。
8、/hbase/oldWALs
这里对应0.94的.oldlogs 目录

第一部分文件是被Hlog处理的write-ahead日志文件，这些日志文件被保存在http://www.aliyun.com/zixun/aggregation/13713.html">HBase根目录下的.logs文件夹。.logs目录下面为每一个HRegionServer单独创建一个文件夹，每一个文件夹下有几个HLog文件（因为log rotation)。每一个HRegionServer的所有region都共享一个HLog文件。
　　当一个日志文件不再需要时（因为其包含的“编辑信息”都已经持久化保存到store files)，该日志文件会被保存到数据库根目录下.oldlogs文件夹。.oldlogs目录下的文件在10分钟后会被master删除（该时间可以由hbase.master.logcleaner.ttl参数设置）。Master会每隔一分钟（该时间可以由hbase.master.cleaner.interval参数设置）检查这些旧日志文件。
　　第二部分文件是hbase.id和hbase.version文件，hbase.id记录了集群的唯一标识；hbase.version记录了文件格式的版本号。
　　第三部分，随着时间的增长，在根目录下 还会产生一些其他目录。split和.corrupt目录在日志 分裂过程中使用，以便保存一些中间结果和损坏的日志。
　　表级文件(Table-level files)
　　HBase的每一张表在根目录下 都有一个单独的文件夹（在这里我们称为表目录）。在表目录下有一个命名为.tableinfo的文件，该文件保存了该表所对应的已经序列化的HTableDescriptor。HTableDescriptor包含了表和column family模式。除了.tableinfo之外，还有.tmp目录。.tmp目录有很多作用，举例来说，需要在.tableinfo更新过程中被使用。
　　域级文件（Region-level files)
　　在表目录下，为该表的每一个region单独创建一个目录，目录的名字为region name的MD5哈希值。整个的目录结构 如下所示：
　　/<hbase-root-dir>/<tablename>/<encoded-regionname>/<column-family>/<filename>
　　在每一个column-family目录下保存着真正的数据文件。这些数据文件以随机数来命名，由Java内置的随机数生成器产生。HBase程序非常智能，可以发现随机数重复，以 防止命名重复；直到找到未使用的随机数为止。
　　region目录包含.regioninfo文件，该文件包含了该region所对应的HRegionInfo所对应的 经过序列化的信息。除了该文件之外，还有一个可选的目录.tmp会随着需求的出现被创建， 例如在合并过程中重写文件。