前言

经过前面的学习了解，我们可以明确HBase是为了适应大容量数据交互和多类型数据存储而产生的列式存储数据库，数据类型为key-value，所有的数据属性都表现在列族上，可以说列族是HBase表中的最关键数据模型。

一般在完全分布式集群中，集群中的slave服务器一般为HBase存储数据的RegionServer，每一个RegionServer可以有多个Region，Region中存储多行的数据，（master与RegionServer间的管理调用通过ZooKeeper集群管理器进行）数据最终存储在HDFS中。

在HBase中，基本的数据模型是表table，行键rowkey，列族columnfamily，列columnqualifier，单元格cell，时间戳timestamp，版本号version（一般不特别说明的话，version为数据存储的时间，如果特别指定version，则为当前数据的版本号。在HDFS中单元格的数据是按照version排序的，而version是以字典顺序为依据进行排序，也即version1在version1和version2间；行键同理，row11在row1和row2之间）

存储数据机制

此处参考《HBase不睡觉书》，按照数据存储的过程来讲解HBase存储数据的架构机制。

1.宏观架构

如上图所示，HBase中的最重要的就是Master和RegionServer，其中一半Master为1-2个（2个一般是使用HA模式，一个作为候补机），多个RegionServer，一般一个slave为一个RegionServer，一个RegionServer上一般有多个Region，Region中存储一行行的数据，而数据最终存储在HDFS中。

HBase中有自带的ZooKeeper，目的在于管理master和regionserver间的任务调度，当需要进行表操作时，master在zookeeper中注册生成一个session，zookeeper检查regionserver中健康的空闲的选择master表操作的对象，同时监控表操作的整个过程。当任务结束或者任务宕机生成的session会自动被删除，进行下一步操作（zookeeper等待下一次注册/重新选择健康的regionserver并重复原过程）。

在客户端和服务端的交互中，客户端发出数据操作请求，请求发送给zookeeper，zookeeper根据情况处理任务。

需要注意的是，和一般的产品不同，HBase集群中，master宕机并不会造成巨大的损失，因为regionserver依旧可以工作，因为master主要是表删除新建数据需要，普通的数据查询更新是直接在regionserver上进行的。这点设计也是为hbase高效工作和宕机处理提供很好的缓冲时间。但如果将zookeeper关掉，就不能读数据了，因为读取数据所需要的元数据表hbase:meta存储在zookeeper上。

2. RegionServer

在RegionServer中很重要的也是设计的特别棒的一个产品就是WAL。Write-Ahead-Log，预写日志，顾名思义。当数据到达RegionServer时，先写入WAL，之后会先存于Region中的MetaStore进行排序，此处为内存存储，当内存容量到达一个阀值时，会根据LSM算法刷写（flush）到HFile中。在这个过程中，如果服务器宕机或者其他事件，数据丢失了，可以及时从WAL日志中找回并继续进行写操作从而恢复数据，WAL是一个保险机制。更细一步讲，WAL是一个环状的滚动日志结构，写入效率很高，并且可保证空间不会持续变大。

在Region中，都有起始rowkey和终止rowkey，代表其存储的row范围，可存储多个列族，这也体现了HBase数据表示行分散的，row间没啥联系，而一般一个store存储一个列族。

WAL是存储在HDFS上的，MemStore是存储在内存中的，HFile是存储在HDFS上的。之所以最终存储HDFS上的数据是从MemStore中来的，而非一开始写入的WAL，是因为HDFS只支持创建、追加和删除，不支持修改，而对于一个数据库而言，顺序存储是一件非常重要的事，所以就提前在进入HDFS之前在MemStore中排完序生成LSM树（Log Structured Merge Tree，可以提高写性能，适用于写多读少的场景），每次刷写生成一个新的HFile，存储在HDFS上，实现HDFS中表数据按rowkey有序存储。由此也可以知道MemStore存在的意义是维持数据按照rowkey顺序排列，而不是做一个缓存。

在读取的过程中，如果直接读内存的话过于低效率，所以又设计了一个缓冲区BlockCache，先在BlockStore中找，找不到去MemStore，再找不到去存于磁盘的HDFS上寻找。特别需要注意的是，一个RegionServer只有一个BlockCache

3. HFile

HFile是数据存储的实际载体，我们创建的表、列等数据都最终存储在HFile中，HFile是有一个个的块组成的，一个块的默认大小为64KB，是在列族上BLOCKSIZE属性定义的。

Data为数据块，每个HFile中有多个Data块，存储HBase表中的数据。

Meta为元数据块，只有在HFile文件关闭的时候才会写入，存储了该HFile文件的元数据信息。

FileInfo是文件信息，只有在HFile文件关闭时写入，存储文件的信息例如最后一个Key等信息。

DataIndex存储Data索引信息，也即Data块的偏移值offset，有Data才会有DataIndex

MetaIndex存储Meta索引信息，有Meta才会有MetaIndex

Trailer存储了FileInfo、DataIndex、MetaIndex块的偏移值，是HFile中必需的

4. Data

Data块中先有的是块类型BlockType，后面存储很多的KeyValue键值对，也即Hbase数据表中的单元格的实现类，需要了解的是，Cell是一个接口，KeyValue是其实现类。

对于Data中存储的是一个列族中某一行的某一单元格的数据，BlockType为单元格数据的属性，每一个Cell为一个version的数据。所以HFile中的Data为一个或多个row的所有单元格的数据。

5. Key-Value

KeyValue中是存储数据的Value，是一个Cell下表示一个Verison的Value值，其余块是这个Value相关的信息，例如列族信息（长度、名字），列信息（名字），行信息（行长度、行名字），key信息（类型、长度），时间戳等。

至此，HBase的存储结构由宏观到不可再分割的KeyValue结束，完美~\(≧▽≦)/~

6.数据写入过程

在总结完HBase数据存储结构后，来写一个数据写入过程具体体会HBase惊艳的存储结构。

需要注意的是，存于WAL的数据是不能直接读取和使用的。HFile是真正数据最终存储的位置，是持久化写入磁盘中的，即使宕机也不会丢失数据的。

7.数据读出过程

在前面也提到过，读取数据会先从BlockCache中查询，如果查不到，会在MemStore和HFile中扫描查询。HBase支持Scan操作，在Scan扫描时会创建StoreScanner实例，会将MemStore和HFile结合起来扫描，的那个StoreScanner打开时会先定位于一个STARTROW上，然后按row顺序扫描直到找到目标数据。Scan会把所有符合条件的StoreScanner扫描之后会把目标数据返回给Client，同时将Block块缓存到BlockCache中去。

拓展补充

HBase不支持表间关联，不支持Windows系统，支持ACID（Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性）。在HBase中，表命名空间Namespace主要是为了把多个属于相同业务领域的表分成一个组，创建使用create 'mytable:table1', 'mycf1' 需要注意的是在HBase中创建新表，至少需要跟一个列族

如果之前接触过数据库表的设计的话，我们会有一个好的认知，数据不需要的时候不会直接删除，而是借用某一个boolean数据的属性值将其禁止掉即可，以避免因为表间紧密的关联删除数据引起不可估计的蝴蝶效应。那么在HBase中也是有这样的机制的，表现在数据的删除和修改，一般来讲新增一个数据那在HDFS上对应新增一个数据无可反驳。Hbase在数据修改和删除也是在HDFS上新增一条数据，修改时新增的数据只是版本号比修改前的大而已，删除时HDFS还是新增一个数据，只是没有Value，类型为DELETE，这样的数据也被称为Tombstone墓碑标记。真正删除在于HBase每隔一段时间的合并操作Compaction，在合并中将有用的数据重新记录，剩下的真正删除掉，这也印证了HDFS上只能新增更新修改，不能删除。

总结

学习当循序渐进，学会总结，相信水滴石穿，加油↖(^ω^)↗