传统的ACID数据库，可扩展性上受到了巨大的挑战。而HBase这类系统，兼具可扩展性的同时，也提出了类SQL的接口。

HBase架构组成

HBase采用Master/Slave架构搭建集群，它隶属于Hadoop生态系统，由一下类型节点组成：HMaster节点、HRegionServer节点、ZooKeeper集群，而在底层，它将数据存储于HDFS中，因而涉及到HDFS的NameNode、DataNode等，总体结构如下：

HBase Client通过RPC方式和HMaster、HRegionServer通信

HMaster节点

1. 协调HRegionServer
   1. 启动时HRegion的分配，以及负载均衡和修复时HRegion的重新分配。
   2. 监控集群中所有HRegionServer的状态(通过与zookeeper的Heartbeat和监听ZooKeeper中的状态，并不直接和slave相连)
2. Admin职能：创建、删除、修改Table的定义。

HRegionServer节点

1. 存放和管理本地HRegion。
2. 读写HDFS，管理Table中的数据。
3. Client直接通过HRegionServer读写数据

一个HRegionServer可以存放1000个HRegion(出自BigTable)；HBase使用RowKey将表水平切割成多个HRegion，从HMaster的角度，每个HRegion都纪录了它的StartKey和EndKey（第一个HRegion的StartKey为空，最后一个HRegion的EndKey为空），由于RowKey是排序的，因而Client可以通过HMaster快速的定位每个RowKey在哪个HRegion中。

底层Table数据存储于HDFS中，而HRegion所处理的数据尽量和数据所在的DataNode在一起，实现数据的本地化；数据本地化并不是总能实现，比如在HRegion移动(如因Split)时，需要等下一次Compact才能继续回到本地化。

ZooKeeper集群是协调系统

1. 存放整个HBase集群的元数据以及集群的状态信息(avalible/alive)。
2. 实现HMaster主从节点的failover，并在HRegionServer宕机的时候通知HMaster。

HBase的第一次读写

0.96以前的版本(参考BigTable)

HBase有两个特殊的表，ROOT表(唯一)和META表。其中，ROOT表的位置保存在ZooKeeper中，它存储了META表的RegionInfo信息。而META表 则存储了用户Table的RegionInfo信息，它可以被切分成多个HRegion。

1. 从ZooKeeper读取ROOT表位置
2. HRegionServer中根据请求的Root表和RowKey读取META表位置
3. 最后从该HRegionServer中读取META表的内容而获取此次请求需要访问的HRegion所在的位置
4. 读取内容。

• 所以需要3次读取才能获取目标HRegion的位置，然后第4次请求才能获取真正的数据。所以，一般客户端有ROOT表位置喝内容的缓存。

我们来看看为什么BigTable要选择三级索引结构，BigTable论文里面提到，一般每个HRegion大小为128M，每行META数据1KB。所以，三级索引可以索引2^34个HRegion，可以索引很大很大的数据了。但是如果只有二级索引，我们就只能索引16TB，在大数据情况下这是完全不够。

0.96后的版本

显然只构建两级索引可以大大加快查询速度，为了两级索引的情况下也能支持大数据量。我们可以加大每个HRegion的大小，如果每个HRegion大小为2GB，两级索引就可以支持4PB。同样，客户端会缓存查询后的HRegion位置信息。

hbase:meta表

meta表存储了所有用户HRegion的位置信息，它的RowKey是：tableName,regionStartKey,regionId,replicaId等，它只有info列族，这个列族包含三个列，他们分别是：

• regioninfo列是RegionInfo的proto格式：regionId,tableName,startKey,endKey,offline,split,replicaId；
• server格式：HRegionServer对应的server:port；
• serverstartcode格式是HRegionServer的启动时间戳。

meta表(root表)结构

HRegionServer详解

HRegionServer一般和DataNode在同一台机器上运行，实现数据的本地性。HRegionServer包含多个HRegion，由WAL(HLog)、BlockCache、MemStore、HFile组成。

WAL(Write Ahead Log, HLog)

所有写操作都会先保证将数据写入这个Log文件(每个HRegionServer只有一个)后，才会真正更新MemStore，最后写入HFile中。这样即使HRegionServer宕机，我们依然可以从HLog中恢复数据。

由于HDFS只允许同一时刻对一个文件只能一个客户端写入，所以对HLog只能单线程写入。这样很明显会影响性能，所以再HBase1.0以后的版本，多个WAL并行写(MultiWAL)，该实现采用HDFS的多个管道写，以单个HRegion为单位。

BlockCache

读缓存，Hbase中有两种(BlockCache为HRegionServer内存大小的20%)

1. on-heap LruBlockCache：LruBlockCache受到java gc的影响，不稳定
2. BucketCache(通常是off-heap)：一般采用这种方式，自己管理内存，更加稳定

HRegion

HRegion是一个表的一部分，表的横切的一部分

HStore

HRegion由多个Store(HStore)构成，每个HStore对应了一个Table在这个HRegion中的一个Column Family，即每个Column Family就是一个集中的存储单元，因而最好将具有相近IO特性的Column存储在一个Column Family，以实现高效读取(数据局部性原理，可以提高缓存的命中率)。

HStore是HBase中存储的核心，它实现了读写HDFS功能，一个HStore由一个MemStore 和0个或多个HFile组成。

• MemStore：所有数据的写在完成WAL日志写后，会 写入MemStore中，由MemStore根据一定的算法将数据Flush到地层HDFS文件中(HFile)，通常每个HRegion中的每个 Column Family有一个自己的MemStore。
• HFile：在HFile中的数据是按RowKey、Column Family、Column排序，对相同的Cell(即这三个值都一样)，则按timestamp倒序排列

MemStore

MemStore是一个In Memory Sorted Buffer，在每个HStore中都有一个MemStore，即它是一个HRegion的一个Column Family对应一个实例。它的排列顺序以RowKey、Column Family、Column的顺序以及Timestamp的倒序，如下所示：

每一次Put/Delete请求都是先写入到MemStore中，当MemStore满后会Flush成一个新的StoreFile(底层实现是HFile)，即一个HStore(Column Family)可以有0个或多个StoreFile(HFile)。有以下三种情况可以触发MemStore的Flush动作，需要注意的是MemStore的最小Flush单元是HRegion而不是单个MemStore。据说这是Column Family有个数限制的其中一个原因，估计是因为太多的Column Family一起Flush会引起性能问题

1. MemStore超过128M，此时当前的HRegion中所有的MemStore会Flush到HDFS中。
2. HRegionServer上所有MemStore的大小超过了机器上默认40％的内存使用量。此时当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中，Flush顺序是MemStore大小的倒序，直到低于某个阈值，默认38%
3. WAL过大，当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中，Flush使用时间顺序，最早的MemStore先Flush直到WAL的数量少于某个阈值。

在MemStore Flush过程中，还会在尾部追加一些meta数据，其中就包括Flush时最大的WAL sequence值，以告诉HBase这个StoreFile写入的最新数据的序列，那么在Recover时就直到从哪里开始。

HFile格式

HFile是MemStore在HDFS上的实体，所以写一个HFile是顺序写，速度很快。HFile一共经历了三个版本

v1

数据存放再Data块中，Data块的大小可以用户指定，大的Data块适合scan，小的Data块适合随机查找。

HFile里面的每个KeyValue对就是一个简单的byte数组。但是这个byte数组里面包含了很多项，并且有固定的结构。

Block Index：使用记录每个Data Block最大值的方案，需要将索引一次性读入内存

v2

解决了V1版本内存占用，特别是Bloom File和Block Index过大。它的解决方案是把Bloom File和Block Index打散放入Data，每次查询不用加载全部信息。对HFileV2格式具体分析，它是一个多层的类B+树索引，采用这种设计，可以实现查找不需要读取整个文件


Data Block中的Cell都是升序排列，每个block都有它自己的Leaf-Index，每个Block的最后一个Key被放入Intermediate-Index中，Root-Index指向Intermediate-Index。Bloom过滤器用于快速定位没有在DataBlock中的数据

v3

v3和v2没有太大变化，只是加了一个tag字段

理一理HRegionServer中的结构

• HRegionServer
  • WAL(Hlog，一个，HDFS中)
  • BlockCache
  • HRegion(最多1000个，表的横切，rowkey不会重叠)
    • HStore（列族，HRegion的列切， 多个）
      • MemStore(写完Hlog后，刚生成的数据)
      • HFile(多个，具体的数据，排序，HDFS中)

HRegionServer写流程

1. 客户端发起一个Put请求时，首先它从hbase:meta表中查出该Put数据最终需要去的HRegionServer。然后客户端将Put请求发送给相应的HRegionServer，在HRegionServer中它首先会将该Put操作写入WAL日志文件中
   
2. 完WAL日志文件后，HRegionServer根据Put中的TableName和RowKey找到对应的HRegion，并根据Column Family找到对应的HStore，并将Put写入到该HStore的MemStore中。写入成功，返回给客户端。
   
3. 当MemStore积累一定量的数据后，flush成HFile到HDFS上

HBase读流程

HBase写时，相同Cell(RowKey/ColumnFamily/Column相同)并不保证在一起，甚至删除一个Cell也只是写入一个新的Cell，它含有Delete标记，而不一定将一个Cell真正删除了，因而这就引起了一个问题，如何实现读的问题？

相同的cell可能存在3个不同的位置，Block Cache，MemStore，HFile中。

1. 从Block Cache中读取
2. 从MemStore中读取
3. 从多个HFile中读取，用Bloom Filter筛掉明显不存在所需数据的HFile，Index用于快速定位HFile中的数据块

Compaction

HFile过多，在数据读取的时候，会产生性能问题。所以一段时间后，HFile会进行合并。HBase中Compaction分为两种：Minor Compaction和Major Compaction。

• Minor Compaction：是指选取一些小的、相邻的HFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。(BigTable中将memtable的数据flush的一个HFile/SSTable称为一次Minor Compaction)
  
• Major Compaction：是指将所有的HFile合并成一个HFile，可以手动触发或者自动触发，但是会引起性能问题，一般安排在周末。
  

HRegion Split

最初，一个Table只有一个HRegion，随着数据写入增加，如果一个HRegion到达一定的大小，就需要Split成两个HRegion，这个大小由hbase.hregion.max.filesize指定，默认为10GB。

当split时（split时停止服务），两个新的HRegion会在同一个HRegionServer中创建，它们各自包含父HRegion一半的数据，当Split完成后，父HRegion会下线，而新的两个子HRegion会向HMaster注册上线，处于负载均衡的考虑，这两个新的HRegion可能会被HMaster分配到其他的HRegionServer中。

分裂流程

1. RegionServer在本地决定分割HRegion，并准备分割。第一步，汇报给zookeeper。
2. master获取zookeeper中的状态。
3. RegionServer在HDFS的父目录区域目录下创建一个名为“.splits”的子目录。
4. RegionServer关闭父HRegion，强制刷新缓存，并将该区域标记为本地数据结构中的脱机状态。此时，来到父区域的客户端请求将抛出NotServingRegionException异常。客户端将重试一些备用值。
5. RegionServer在.splits目录下创建Region目录，为子区域A和B创建必要的数据结构。然后，它分割存储文件，因为它在父区域中为每个存储文件创建两个引用文件。那些引用文件将指向父Region文件。
6. RegionServer在HDFS中创建实际的区域目录，并移动每个子Region的引用文件。
7. RegionServer向META表发送请求。将父HRegion设置为.META中的脱机状态，并添加关于子HRegion的信息。在这时，在META中不会为女儿分配单独的条目。客户端会看到父区域是分割的，如果他们扫描.META，但不知道子HRegion，直到他们出现在.META。
8. RegionServer并行open子HRegion接受写入。
9. RegionServer将女儿A和B添加到.META。以及它所在地区的信息。此后，客户可以发现新的地区，并向新的地区发出请求，之前的缓存失效。
10. HRegion Server向zookeeper汇报split结束的消息，master进行负载均衡。
11. 拆分后，meta表和HDFS仍将包含对父HRegion的引用。当子HRegion进行Compaction时，这些引用信息会被删除。Master也会定期检查子HRegion，如果没有父HRegion中的信息，父HRegion将被删除。

HRegion分裂后负载均衡

出于负载均衡的考虑，HMaster可能会将其中的一个甚至两个重新分配的其他的HRegionServer中。可能会产生HFile在其他节点上，直到下一次Major Compaction将数据从远端的节点移动到本地节点。

既然有拆分，但是HRegion也可以合并。HRegion调用closeAndMerge把两个HRegion合并(需要两个HRegion停止服务)

HBase中的负载均衡

负载均衡器会平衡系统中每个HRegionServer中HRegion个数。

负载均衡对系统性能影响很大，实际一般关闭，每周开启一次。

容错

HRegionServer Recovery

1. zookeeper感知，通知HMaster
2. 重新分配HRegion到其他节点
3. 为每个HRegion拆分WAL，将拆分出的WAL文件写入对应的目的HRegionServer的WAL目录中，并并写入对应的DataNode中
4. 回放WAL，重建MemStore

HMaster Recovery

依靠zookeeper进行主备切换

HBase一致性

HBase是强一致性，它表现在：

1. HRegion split时相关HRegion不可用
2. HRegion合并时相关HRegion不可用
3. HRegionServer Recovery时相关HRegion不可用