HBASE数据架构

1、数据结构

关系数据库一般用B+树，HBASE用的是LSM树。MYSQL所用类B+树一般深度不超过3层，数据单独存放，在B+树的叶节点存储指向实际数据的指针，叶节点之间也相互关联，类似双向链表。这种结构的特点是数据更新或写入导致数据页表分散，不利于顺序访问。LSM存储中，各个文件的结构类似于B+树，但是分多个存在内存或磁盘中，更新和写入变成了磁盘的顺序写，只在合并时去掉重复或过时的数据。也就是说，LSM树将B+树种的随机写变成顺序写，从而提高写吞吐量。

2、存储

存储对象：HregionServer对应多个HRegion，Region的每个列族对应一个Store，每个Store对应多个StoreFile，以及一个memstore。当然，数据刷写时，一个Region只要有一个列族的memStore需要刷写磁盘，则该region的所有列族的memstore都会刷写磁盘。

数据访问流程：客户端联系zookeeper集群查找-ROOT-表所在Region服务器，通过-ROOT- Region服务器查找.Meta.表中含有数据region的服务器，然后在.META.表中定位到实际数据对应region的服务器，最后连接这个服务器读写数据。

写路径：客户端发起put等请求，交给HRegion实例来处理。HRegion根据put设置决定是否要预写日志，日志写完后数据被写入memstore中。若memstore已满，则数据被刷写到磁盘，同时在文件中保存最后写入的序列号（跟Hlog中的序列号一样，用于决定日志重做起始位置）。

hbase在hadoop上的文件：分为根级文件和表级文件。第一组是WAL文件，对应/hbase/.logs/目录，每个region服务器在该目录下对应一个子目录，里面包含多个日志文件（日志滚动产生：hbase.regionserver.logroll.period）。当日志对应的所有修改被刷写到磁盘，则该日志文件会被转到/hbase/.oldlogs/目录中，再过一段时间（对应配置hbase.master.logcleaner.interval）会被master删除。另外，/hbase/hbase.id和/hbase/hbase.version分别对应集群的唯一ID和文件格式的版本信息。此外，/hbase/splitlog/和/hbase/.corrupt/分别对应存储日志拆分过程中产生的中间拆分文件和损坏的日志。

表级文件，每张表对应/hbase/tableName/目录，该目录包含.tableinfo文件，用来存储HTableDescriptor的序列化信息。

表级目录下每个region对应一个子目录，目录中包含一个.regioninfo文件，对应HRegionInfo的序列化信息。日志拆分完成后会在对应Region目录下创建recovered.edits目录，用来存放需要恢复的日志。当region被打开时，region服务器会看到需要回复的文件并重做。region拆分时，关闭该region，在该region目录下创建spits目录，包括新的region目录和引用文件，然后将两个目录移到表目录下，.META.表中父region被更新，增加splitA列和splitB列以标志该region正被更新。之后同时打开两个子region，更新.META.表，增加子region的条目。最后在region目录下的.tmp目录拷贝父region的文件数据。

合并：合并分为minor和并和major和并。minor合并的文件最小数量控制：hbase.hstore.compaction.min或hbase.htore.compactionThreshold，最大数量控制：hbase.hstore.compaction.max，被合并文件最大尺寸控制：hbase.hstore.compaction.max.size，最小尺寸：hbase.hstore.compaction.min.size表示所有小于该值的文件都将参与合并，直到达到合并文件最大数量限制。major合并检查的触发条件：memstore被刷写，shell执行compact或major_compact，或相应API调用。除非执行major_compact或majorCompact API，否则不会绕过检查阶段的。

HFILE：HFile由块组成包括数据块，FileInfo块和Trailer块。值得注意的块的大小，太小会增加块间索引空间，太大会导致每次get操作读入内存的数据量过大，影响IO性能。顺序读多的情况下设置块较大，随机读多的情况下减小块配置，建议8k-1M。对于带压缩的表，每块实际大小会比设置的块大小要小。

3、WAL

实现WAL的类叫Hlog，如果是在大批量导入数据的mapreduce，建议关闭写日志。Hlog维护一个序列号，要么从零开始，要么从每一个数据文件storefile中取出序列号，取其最大值，最中数据文件中的序列号和日志中的序列号完全对应，以便日志重做。一个region服务器上所有region共享一个hlog实例，意味着所有日志顺序写入日志文件，在日志重做时会产生日志拆分带来的额外开销。WAL用hadoop的SequenceFile存日志，其中key对应类HLogKey包含（表名和region）。客户端的每个修改被封装为一个WALEdit实例。LogSyncer提供了日志延迟刷写的特性，通过hbase.regionserver.optionallogflushinterval设置刷写间隔。

普通的hadoop文件是一读多写，在写入过程中其他用户不可见这个文件。但如果在写日志过程中服务器崩溃，是不是会出问题呢？幸好hadoop新版本添加了append属性，用户可以读到上次崩溃的日志位置。

4、读路径

get即scan：hbase中没有索引文件，hFile中最小的单元是块，所以regionserver和底层的Store必须定位到块后把块载入内存然后遍历这个块，才能确定所需数据。这就是scan做的事情，get也必须这么做。

查询数据时，首先是用时间戳或布隆过滤器去掉那些绝对不包含keyvalue的文件。然后加载剩余所有文件的可能数据块。最终还要把keyvalue排序，取得合适的数目的版本数据，以及判断是否有墓碑标记覆盖的过时记录。

5、region查找

一般情况是3次网络往返定位到特定region：请求zookeeper查找-ROOT-表，请求-ROOT-表所在region服务器查找.META.表对应的region，再从上一步结果对应的region服务器查找正真的数据region。但是当缓存的region位置信息过期，或者region服务器发生了拆分、合并、移动或负载均衡等操作，最坏情况下定位region服务器需要6次网络往返请求。这是因为客户端采用的是回退迭代的思路，即第一次直接访问发现region不在了，接着会去用缓存的-ROOT-信息定位.META.表位置，发现.META.数据失效，从zookeeper请求-ROOT-表信息，则回到3次网络请求的步骤。

6、zookeeper

zookeeper用来跟踪region服务器，保存-ROOT-表地址等。加入zookeeper后，region服务器发送给master的心跳信息交给了zookeeper。hbase集群的跟节点:/hbase，由属性zookeeper.znode.parent参数控制。

/hbase/hbaseid：集群ID

/hbase/master：master的服务器名和端口

/hbase/replication：副本信息

/hbase/root-region-server：包含-ROOT-表所在region服务器的机器名。

/hbase/rs：region服务器的根节点，集群用来跟踪服务器异常。每个region服务器有一个以region服务器名为名称的znode临时节点。