一、物理存储

一张表在行的方向上可以切分为多个Region，也就是说一个Region就是若干行数据的集合，初始阶段只有一个Region；

每行都有一个rowkey且按rowkey的字典序排序；

Region是分布式存储（但不是存储的最小单元）和负载均衡的最小单元，也就是说一个RegionServer上可以有多个Region，但是一个Region只能在一个RegionServer上；

一个Region中包含一个或多个Store，一个Store对应一个列族；

每个Store有一个memStore和若干个StoreFile组成以及rowkey索引（记录每个StoreFile中rowkey的范围，方便get数据），写一行数据时，Hbase不会直接写到磁盘，而是先写到内存memStrore中，当memStore达到阈值后才刷写到磁盘，此时的写入是按rowkey+版本+列名顺序写入的，所以StoreFile中的数据是有序的（但是StoreFile之间没有顺序），当StoreFile文件数量达到阈值后，会触发合并，将多个小的StoreFile合并为大的StoreFile

StoreFile是以HFile的形式存储在HDFS中的，HFile的结构如下：

其中KeyType有两种类型，1：Put，2Delete

WAL log

每个Region Server维护一个Hlog,而不是每个Region一个。这样不同region(来自不同table)的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其它region server上进行恢复。

二、系统架构

Client

包含访问Hbase的接口及一些cache信息，如Region的位置信息；

Zookeeper

保证任何时候，集群中只有一个master；

存贮所有Region的寻址入口；

实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master；

存储Hbase的schema,包括有哪些table，每个table有哪些column family；

HMaster

为Region server分配region，负责region server的负载均衡；

管理用户对Table的增、删、改、查操作；

发现失效的region server并重新分配其上的region；

GFS上的垃圾文件回收；

在HRegionServer停机后，负责失效HRegionServer 上的Regions迁移；

三、分析通过rowkey获得一条数据的过程

1、确定region位置

HBase有两张系统表META和ROOT，结构如下：

可以通过startKey和endKey确定某个rowkey所在的Region，但是有个问题当数据量特别大的时候，META表也是分布在多个Region上的，如何找到全部的META表中的数据进行匹配呢？

Hbase的做法是再创建一张表ROOT，在其中记录所有的META数据所在的Region，然后把ROOT所在的Region放到Zookeeper中，这样我们就可以通过rowkey找到数据在哪个Region中了。

2、确定在哪些StoreFile中；

一个Region中有若干个Store，一个Store钟又有多个SoteFile，数据是存放到StoreFile中的，那么我们如何找到StoreFile呢？

首先Region中的Store是和列族对应的（所以应该尽量将经常要查询的列放到一个列族中，避免在多个Store中查找数据），所以定位Store很简单。接下来是定位StoreFile，StoreFile内部是有序的，在Store中做一个StoreFile的索引也是比较方便的，所以可以通过这个索引获取到rowkey在哪些StoreFile中，为什么会在多个StoreFile中？因为Hbase的增、删、改操作本质上都是增，只是做了一些标记而已。在StoreFile合并前，一个rowkey确实可能分散在多个StoreFile中（个人理解即使合并也未必能把一个rowkey合并到一起）。找到了StoreFiles之后接下来应该就是多线程并发去筛选了，最终合并结果返回。

四、增、删、改分析

五、思考

1、列存储体现在哪里？