1 HBase 系统架构图

架构图中的组件说明如下。

1.1 Client

　　使用HBase RPC机制与HMaster和HRegionServer进行通信 。
　　Client与HMaster进行通信进行管理类操作。
　　Client与HRegionServer进行数据读写类操作 。

1.2 Zookeeper

　　Zookeeper是HBase Master的HA解决方案。Zookeeper保证了至少有一个HBase Master 处于运行状态，避免HMaster单点问题。
Zookeeper发展到目前为止，已经成为了分布式大数据框架中容错性的标准框架。不光是HBase，几乎所有的分布式大数据相关的开源框架，都依赖于Zookeeper实现HA。
　　Zookeeper Quorum存储-ROOT-表地址、HMaster地址。
　　HRegionServer把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状况。

1.3 HMaster

　　HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master在运行 。当多个Master节点共存时，只有一个Master是提供服务的，其他的Master节点处于待命的状态。当正在工作的Master节点宕机时，其他的Master则会接管HBase的集群。
　　HBase Master用于协调多个Region Server，侦测各个RegionServer之间的状态，并平衡RegionServer之间的负载。HBase Master还有一个职责就是负责分配Region给RegionServer。

　　HMaster主要负责Table和Region的管理工作有：

1) 管理用户对表的增删改查操作。
2) 管理HRegionServer的负载均衡，调整Region分布 。
3) Region Split后，负责新Region的分布 。
4) 在HRegionServer停机后，负责失效HRegionServer上Region迁移 。

1.4 HRegionServer

　　HBase中最核心的模块，主要负责响应用户I/O请求，向HDFS文件系统中读写数据
http://www.cndba.cn/dave/article/3315

　　HRegionServer管理一些列HRegion对象；
　　每个HRegion对应Table中一个Region，HRegion由多个HStore组成；
　　每个HStore对应Table中一个Column Family的存储；

　　Column Family就是一个集中的存储单元，故将具有相同IO特性的Column放在一个Column Family会更高效。http://www.cndba.cn/dave/article/3315

　　对于一个RegionServer而言，其包括了多个Region。RegionServer的作用只是管理表格，以及实现读写操作。Client直接连接RegionServer，并通信获取HBase中的数据。
　　对于Region而言，则是真实存放HBase数据的地方，也就说Region是HBase可用性和分布式的基本单位。如果当一个表格很大，并由多个Column Family组成时，那么表的数据将存放在多个Region之间，并且在每个Region中会关联多个存储的单元（Store）。http://www.cndba.cn/dave/article/3315

1.5 HStore

　　HBase存储的核心。由MemStore和StoreFile组成。
　　MemStore是Sorted Memory Buffer。用户写入数据的流程：

　　Client写入 -> 存入MemStore，一直到MemStore满 -> Flush成一个StoreFile，直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除 -> 当StoreFiles Compact后，逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个Region，Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。

　　由此过程可知，HBase只是增加数据，所有得更新和删除操作，都是在Compact阶段做的，所以，用户写操作只需要进入到内存即可立即返回，从而保证I/O高性能。http://www.cndba.cn/dave/article/3315

1.6 HLog

　　引入HLog原因：
　　　　在分布式系统环境中，无法避免系统出错或者宕机，一旦HRegionServer意外退出，MemStore中的内存数据就会丢失，引入HLog就是防止这种情况

　　工作机制：
　　　　每个HRegionServer中都会有一个HLog对象，HLog是一个实现Write Ahead Log的类，每次用户操作写入Memstore的同时，也会写一份数据到HLog文件，HLog文件定期会滚动出新，并删除旧的文件(已持久化到StoreFile中的数据)。
　　　　当HRegionServer意外终止后，HMaster会通过Zookeeper感知，HMaster首先处理遗留的HLog文件，将不同region的log数据拆分，分别放到相应region目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。

1.7 HBase存储格式

　　HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，格式主要有两种：

1) HFile
　　HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile 。
2) HLog File
　　HBase中WAL（Write Ahead Log） 的存储格式，物理上是Hadoop的Sequence File。

1.7.1 HFile

图片解释：
　　HFile文件不定长，长度固定的块只有两个：Trailer和FileInfo 。
　　Trailer中指针指向其他数据块的起始点 。
　　File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等 。
　　Data Index和Meta Index块记录了每个Data块和Meta块的起始点 。
　　Data Block是HBase I/O的基本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制 。
　　每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询 。
　　每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字，目的是防止数据损坏。
HFile里面的每个KeyValue对就是一个简单的byte数组。这个byte数组里面包含了很多项，并且有固定的结构。http://www.cndba.cn/dave/article/3315

　　KeyLength和ValueLength：两个固定的长度，分别代表Key和Value的长度 。
　　Key部分：Row Length是固定长度的数值，表示RowKey的长度，Row 就是RowKey 。
　　Column Family Length是固定长度的数值，表示Family的长度 。
　　接着就是Column Family，再接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type（Put/Delete） 。
　　Value部分没有这么复杂的结构，就是纯粹的二进制数据。

1.7.2 HLog File

　　HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是“写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。
　　HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue。http://www.cndba.cn/dave/article/3315

2 Hbase数据模型

2.1 逻辑视图

http://www.cndba.cn/dave/article/3315http://www.cndba.cn/dave/article/3315

基本概念：

1) RowKey：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要；
2) Column Family：列族，拥有一个名称(string)，包含一个或者多个相关列；
3) Column：属于某一个columnfamily，familyName:columnName，每条记录可动态添加；
4) Version Number：类型为Long，默认值是系统时间戳，可由用户自定义；
5) Value(Cell)：Byte array。

2.2 物理模型

1) 每个column family存储在HDFS上的一个单独文件中，空值不会被保存。
2) Key 和 Version number在每个column family中均有一份；
3) HBase为每个值维护了多级索引，即： ；
4) 表在行的方向上分割为多个Region；
5) Region是Hbase中分布式存储和负载均衡的最小单元，不同Region分布到不同RegionServer上。
6) Region按大小分割的，随着数据增多，Region不断增大，当增大到一个阀值的时候，Region就会分成两个新的Region；
7) Region虽然是分布式存储的最小单元，但并不是存储的最小单元。每个Region包含着多个Store对象。每个Store包含一个MemStore或若干StoreFile，StoreFile包含一个或多个HFile。MemStore存放在内存中，StoreFile存储在HDFS上。

2.3 ROOT表和META表

　　HBase的所有Region元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。
为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。
所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，如下图所示。

　　-ROOT-表永远不会被分割，它只有一个Region，这样可以保证最多只需要三次跳转就可以定位任意一个Region。
为了加快访问速度，.META.表的所有Region全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。最后，如果前面的信息全部失效，则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的Region。

3 高可用

3.1 Write-Ahead-Log（WAL）保障数据高可用

　　HBase中的HLog机制是WAL的一种实现，WAL（预写日志）是事务机制中常见的一致性的实现方式。每个RegionServer中都会有一个HLog的实例，RegionServer会将更新操作（如 Put，Delete）先记录到 WAL中，然后将其写入到Store的MemStore，最终MemStore会将数据写入到持久化的HFile中。这样就保证了HBase的写的可靠性。
　　如果没有 WAL，当RegionServer宕掉的时候，MemStore 还没有写入到HFile，或者StoreFile还没有保存，数据就会丢失。或许有的读者会担心HFile本身会不会丢失，这是由 HDFS 来保证的。在HDFS中的数据默认会有3份。因此这里并不考虑 HFile 本身的可靠性。

3.2 组件高可用

1) Master容错：Zookeeper重新选择一个新的Master。如果无Master过程中，数据读取仍照常进行，但是，region切分、负载均衡等无法进行；
2) RegionServer容错：定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer；
3) Zookeeper容错：Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例。

4 HBase读写流程

　　HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。与此同时，系统会在Zookeeper中记录一个CheckPoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致MemStore中的数据丢失，此时使用HLog来恢复CheckPoint之后的数据。
StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定阈值后，就会进行一次合并操作,将对同一个key的修改合并到一起，形成一个大的StoreFile。当StoreFile的大小达到一定阈值后，又会对 StoreFile进行切分操作，等分为两个StoreFile。

4.1 写操作流程

1) Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据。
2) 数据被写入Region的MemStore，直到MemStore达到预设阈值。
3) MemStore中的数据被Flush成一个StoreFile。
4) 随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。
5) StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。
6) 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个新的Region。父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使得原先1个Region的压力得以分流到2个Region上。

　　可以看出HBase只有增添数据，所有的更新和删除操作都是在后续的Compact历程中举行的，使得用户的写操作只要进入内存就可以立刻返回，实现了HBase I/O的高机能。

4.2 读操作流程

1) Client访问Zookeeper，查找-ROOT-表，获取.META.表信息。
2) 从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。
3) 通过RegionServer获取需要查找的数据。
4) Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

http://www.cndba.cn/dave/article/3315

　　寻址过程：client—>Zookeeper—>-ROOT-表—>.META.表—>RegionServer—>Region—>clienthttp://www.cndba.cn/dave/article/3315