HBase基本原理与系统架构

首先介绍HBase数据模型，包括表、行、列簇、分区、RowKey等，然后介绍HBase的系统架构，最后介绍HBase的核心流程，包括读写流程、读合并、读放大、小合并、大合并等。

一、HBase基本原理：

数据模型

命名空间namespace对一组表进行逻辑分组，类似schema，方便表的划分。
HBase也有表、行、列的概念，跟传统关系型数据库的最主要的区别我认为是Rowkey和列簇的概念。

RowKey

HBase是分布式的数据库，当数据量过大时，可以按照行的RowKey进行分区。
RowKey 可以水平分区，需要进行设计，会影响排序

Column Family

HBase支持超宽的列，列的数量可以很大，null值不占空间（跟关系数据库不同），可以设计的很稀疏。并且可以进行版本管理（时间戳）
HBase数据都是字节码存储，没有数据类型，比如整型或字符串型等等。
多个列可以构成一个列簇Column Family，用来表达语义边界。

二、HBase系统架构

HMaster管理多个HRegionServer，客户端通过Zookeeper获取集群信息。

客户端数据写入Hlog里，然后进入MemStore缓存（一个列簇进入一个MemStore），再进入HFile。最后通过DFSClient 写入HDFS。

HMaster

HMaster负责管理Region Server，并负责表的创建、修改和删除接口（DDL管理）

RegionServer

一个RegionServer里有多个Region分区，每个Region默认大小为256M。
WAL是WriteAheadLog的缩写。类似MySQL中的BinLog。主要存储还未被持久化的新数据，用于数据恢复。
经常被访问的数据放入块缓存（Block Cache）。存储但是还未被提交的数据放入写缓存（MemStore）。针对每个列簇有一个MemStore。当MemStore中的数据超过一定大小之后提交到HFile。

Zookeeper

除了分布式协调和心跳机制，还维护了元数据表（META Table）的路径用来查找Region。

三、HBase核心流程

读取流程

客户端从Zookeeper中读取元数据路径RegionServer的信息。将元数据缓存在本地，确定Rowkey所在的RegionServer信息，并向其发送读请求。

Read Merge

读取会依次在三个地方查找：Block Cache、MemStore、HFile。HBase有时需要将三个地方的数据进行合并返回，称为读合并。

Read Amplification

当MemStore增加到一定大小后会写入HFile，称为Region Flush。一个MemStore有可能flush到不同的HFile，因此需要读取多个HFile来获取数据，称为读放大，会影响HBase的性能。

写入流程

写入顺序：WAL->MemStore->HFile

Minor Compaction

HBase自动的将较小的HFile合并为较大的HFile，称为小合并。合并是MergeSort按顺序的。

Major Compaction

HBase会合并重写Region中的所有HFile，每个列簇写入一个HFile。称为大合并，由于重写会造成IO和带宽消耗，可以放在夜间执行。由于R egion分裂，造成Region中的HFile，有可能不在本地，直到大合并本地化。

Region Split

随着表的增大，一个Region(256M)难以容纳会Split为两个Region。
当表容量大于hbase.hregion.max.filesize时会进行分裂。

HFile索引

HFile索引存在BlockCache中，读取时会加载到内存中，提高查找性能。

HBase数据恢复

RegionServer宕机后，Zookeeper失去心跳，会通知HMaster。
HMaster重新分配失效RegionServer中的Region给其他RegionServer。
MemStore中的数据将由WAL来恢复重建。[
参考资料：
http://hbase.apache.org
https://ai.google/research/pubs/pub27898