HBase 底层原理详解（深度好文，建议收藏）

HBase简介

HBase 是一个分布式的、面向列的开源数据库。创建在 HDFS 之上。Hbase的名字的来源是 Hadoop database，即 Hadoop 数据库。HBase 的计算和存储能力取决于 Hadoop 集群。

它介于 NoSql 和 RDBMS 之间，仅能经过主键(row key)和主键的 range 来检索数据，仅支持单行事务(可经过 Hive 支持来实现多表 join 等复杂操做)。

HBase中表的特色：

1. 大：一个表能够有上十亿行，上百万列
2. 面向列：面向列(族)的存储和权限控制，列(族)独立检索。
3. 稀疏：对于为空(null)的列，并不占用存储空间，所以，表能够设计的很是稀疏。

HBase底层原理

系统架构

HBase系统架构

根据这幅图，解释下HBase中各个组件

Client

1. 包含访问hbase的接口，Client维护着一些cache来加快对hbase的访问，好比regione的位置信息.

Zookeeper

HBase可使用内置的Zookeeper，也可使用外置的，在实际生产环境，为了保持统一性，通常使用外置Zookeeper。

Zookeeper在HBase中的做用：

1. 保证任什么时候候，集群中只有一个master
2. 存贮全部Region的寻址入口
3. 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master

HMaster

1. 为Region server分配region
2. 负责region server的负载均衡
3. 发现失效的region server并从新分配其上的region
4. HDFS上的垃圾文件回收
5. 处理schema更新请求

HRegion Server

1. HRegion server维护HMaster分配给它的region，处理对这些region的IO请求
2. HRegion server负责切分在运行过程当中变得过大的region
   从图中能够看到，Client访问HBase上数据的过程并不须要HMaster参与（寻址访问Zookeeper和HRegion server，数据读写访问HRegione server）

HMaster仅仅维护者table和HRegion的元数据信息，负载很低。

HBase的表数据模型

HBase的表结构

行键 Row Key

与nosql数据库同样,row key是用来检索记录的主键。访问hbase table中的行，只有三种方式：

1. 经过单个row key访问
2. 经过row key的range
3. 全表扫描

Row Key 行键能够是任意字符串(最大长度是 64KB，实际应用中长度通常为 10-100bytes)，在hbase内部，row key保存为字节数组。

Hbase会对表中的数据按照rowkey排序(字典顺序)

存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将常常一块儿读取的行存储放到一块儿。(位置相关性)。

注意：
字典序对int排序的结果是
1,10,100,11,12,13,14,15,16,17,18,19,2,20,21 … 。要保持整形的天然序，行键必须用0做左填充。

行的一次读写是原子操做 (不论一次读写多少列)。这个设计决策可以使用户很容易的理解程序在对同一个行进行并发更新操做时的行为。

列族 Column Family

HBase表中的每一个列，都归属于某个列族。列族是表的schema的一部分(而列不是)，必须在使用表以前定义。

列名都以列族做为前缀。例如 courses:history ，  courses:math 都属于 courses 这个列族。

访问控制、磁盘和内存的使用统计都是在列族层面进行的。 列族越多，在取一行数据时所要参与IO、搜寻的文件就越多，因此，若是没有必要，不要设置太多的列族。

列 Column

列族下面的具体列，属于某一个ColumnFamily，相似于在mysql当中建立的具体的列。

时间戳 Timestamp

HBase中经过row和columns肯定的为一个存贮单元称为cell。每一个 cell都保存着同一份数据的多个版本。版本经过时间戳来索引。时间戳的类型是 64位整型。时间戳能够由hbase(在数据写入时自动 )赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也能够由客户显式赋值。若是应用程序要避免数据版本冲突，就必须本身生成具备惟一性的时间戳。每一个 cell中，不一样版本的数据按照时间倒序排序，即最新的数据排在最前面。

为了不数据存在过多版本形成的的管理 (包括存贮和索引)负担，hbase提供了两种数据版本回收方式：

1. 保存数据的最后n个版本
2. 保存最近一段时间内的版本（设置数据的生命周期TTL）。

用户能够针对每一个列族进行设置。

单元 Cell

由{row key, column( =<family\> + <label\>), version} 惟一肯定的单元。
cell中的数据是没有类型的，所有是字节码形式存贮。

版本号 VersionNum

数据的版本号，每条数据能够有多个版本号，默认值为系统时间戳，类型为Long。

物理存储

1. 总体结构

HBase 总体结构

1. Table 中的全部行都按照 Row Key 的字典序排列。

2. Table 在行的方向上分割为多个 HRegion。

3. HRegion按大小分割的(默认10G)，每一个表一开始只有一 个HRegion，随着数据不断插入表，HRegion不断增大，当增大到一个阀值的时候，HRegion就会等分会两个新的HRegion。当Table 中的行不断增多，就会有愈来愈多的 HRegion。

4. HRegion 是 HBase 中分布式存储和负载均衡的最小单元。最小单元就表示不一样的 HRegion 能够分布在不一样的 HRegion Server 上。但一个 HRegion 是不会拆分到多个 Server 上的。

5. HRegion 虽然是负载均衡的最小单元，但并非物理存储的最小单元。
   事实上，HRegion 由一个或者多个 Store 组成，每一个 Store 保存一个 Column Family。
   每一个 Strore 又由一个 MemStore 和0至多个 StoreFile 组成。如上图。

2. StoreFile 和 HFile 结构

StoreFile以HFile格式保存在HDFS上。

HFile的格式为：

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数组里面包含了不少项，而且有固定的结构。咱们来看看里面的具体结构：

HFile 具体结构

开始是两个固定长度的数值，分别表示Key的长度和Value的长度。紧接着是Key，开始是固定长度的数值，表示RowKey的长度，紧接着是 RowKey，而后是固定长度的数值，表示Family的长度，而后是Family，接着是Qualifier，而后是两个固定长度的数值，表示Time Stamp和Key Type（Put/Delete）。Value部分没有这么复杂的结构，就是纯粹的二进制数据了。

HFile分为六个部分：

1. Data Block 段–保存表中的数据，这部分能够被压缩.

2. Meta Block 段 (可选的)–保存用户自定义的kv对，能够被压缩。

3. File Info 段–Hfile的元信息，不被压缩，用户也能够在这一部分添加本身的元信息。

4. Data Block Index 段–Data Block的索引。每条索引的key是被索引的block的第一条记录的key。

5. Meta Block Index段 (可选的)–Meta Block的索引。

6. Trailer–这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保存了每一个段的起始位置(段的Magic Number用来作安全check)，而后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不须要扫描整个HFile，而只需从内存中找到key所在的block，经过一次磁盘io将整个 block读取到内存中，再找到须要的key。DataBlock Index采用LRU机制淘汰。

HFile的Data Block，Meta Block一般采用压缩方式存储，压缩以后能够大大减小网络IO和磁盘IO，随之而来的开销固然是须要花费cpu进行压缩和解压缩。
目前HFile的压缩支持两种方式：Gzip，Lzo。

3. Memstore与StoreFile

一个 HRegion 由多个 Store 组成，每一个 Store 包含一个列族的全部数据 Store 包括位于内存的 Memstore 和位于硬盘的 StoreFile。

写操做先写入 Memstore，当 Memstore 中的数据量达到某个阈值，HRegionServer 启动 FlashCache 进程写入 StoreFile，每次写入造成单独一个 StoreFile

当 StoreFile 大小超过必定阈值后，会把当前的 HRegion 分割成两个，并由 HMaster 分配给相应的 HRegion 服务器，实现负载均衡

客户端检索数据时，先在memstore找，找不到再找storefile。

4. HLog(WAL log)

WAL 意为Write ahead log，相似 mysql 中的 binlog,用来 作灾难恢复时用，Hlog记录数据的全部变动,一旦数据修改，就能够从log中进行恢复。

每一个Region Server维护一个Hlog,而不是每一个Region一个。这样不一样region(来自不一样table)的日志会混在一块儿，这样作的目的是不断追加单个文件相对于同时写多个文件而言，能够减小磁盘寻址次数，所以能够提升对table的写性能。带来的麻烦是，若是一台region server下线，为了恢复其上的region，须要将region server上的log进行拆分，而后分发到其它region server上进行恢复。

HLog文件就是一个普通的Hadoop Sequence File：

1. HLog Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是”写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。
2. HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue，可参见上文描述。

读写过程

1. 读请求过程：

HRegionServer保存着meta表以及表数据，要访问表数据，首先Client先去访问zookeeper，从zookeeper里面获取meta表所在的位置信息，即找到这个meta表在哪一个HRegionServer上保存着。

接着Client经过刚才获取到的HRegionServer的IP来访问Meta表所在的HRegionServer，从而读取到Meta，进而获取到Meta表中存放的元数据。

Client经过元数据中存储的信息，访问对应的HRegionServer，而后扫描所在HRegionServer的Memstore和Storefile来查询数据。

最后HRegionServer把查询到的数据响应给Client。

查看meta表信息

hbase(main):011:0> scan 'hbase:meta'

2. 写请求过程：

Client也是先访问zookeeper，找到Meta表，并获取Meta表元数据。

肯定当前将要写入的数据所对应的HRegion和HRegionServer服务器。

Client向该HRegionServer服务器发起写入数据请求，而后HRegionServer收到请求并响应。

Client先把数据写入到HLog，以防止数据丢失。

而后将数据写入到Memstore。

若是HLog和Memstore均写入成功，则这条数据写入成功

若是Memstore达到阈值，会把Memstore中的数据flush到Storefile中。

当Storefile愈来愈多，会触发Compact合并操做，把过多的Storefile合并成一个大的Storefile。

当Storefile愈来愈大，Region也会愈来愈大，达到阈值后，会触发Split操做，将Region一分为二。

细节描述：

HBase使用MemStore和StoreFile存储对表的更新。
数据在更新时首先写入Log(WAL log)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到必定阈值时，就会建立一个新的MemStore，而且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在zookeeper中记录一个redo point，表示这个时刻以前的变动已经持久化了。
当系统出现意外时，可能致使内存(MemStore)中的数据丢失，此时使用Log(WAL log)来恢复checkpoint以后的数据。

StoreFile是只读的，一旦建立后就不能够再修改。所以HBase的更新实际上是不断追加的操做。当一个Store中的StoreFile达到必定的阈值后，就会进行一次合并(minor_compact, major_compact),将对同一个key的修改合并到一块儿，造成一个大的StoreFile，当StoreFile的大小达到必定阈值后，又会对 StoreFile进行split，等分为两个StoreFile。

因为对表的更新是不断追加的，compact时，须要访问Store中所有的 StoreFile和MemStore，将他们按row key进行合并，因为StoreFile和MemStore都是通过排序的，而且StoreFile带有内存中索引，合并的过程仍是比较快。

HRegion管理

HRegion分配

任什么时候刻，一个HRegion只能分配给一个HRegion Server。HMaster记录了当前有哪些可用的HRegion Server。以及当前哪些HRegion分配给了哪些HRegion Server，哪些HRegion尚未分配。当须要分配的新的HRegion，而且有一个HRegion Server上有可用空间时，HMaster就给这个HRegion Server发送一个装载请求，把HRegion分配给这个HRegion Server。HRegion Server获得请求后，就开始对此HRegion提供服务。

HRegion Server上线

HMaster使用zookeeper来跟踪HRegion Server状态。当某个HRegion Server启动时，会首先在zookeeper上的server目录下创建表明本身的znode。因为HMaster订阅了server目录上的变动消息，当server目录下的文件出现新增或删除操做时，HMaster能够获得来自zookeeper的实时通知。所以一旦HRegion Server上线，HMaster能立刻获得消息。

HRegion Server下线

当HRegion Server下线时，它和zookeeper的会话断开，zookeeper而自动释放表明这台server的文件上的独占锁。HMaster就能够肯定：

1. HRegion Server和zookeeper之间的网络断开了。
2. HRegion Server挂了。

不管哪一种状况，HRegion Server都没法继续为它的HRegion提供服务了，此时HMaster会删除server目录下表明这台HRegion Server的znode数据，并将这台HRegion Server的HRegion分配给其它还活着的节点。

HMaster工做机制

master上线

master启动进行如下步骤:

1. 从zookeeper上获取惟一一个表明active master的锁，用来阻止其它HMaster成为master。
2. 扫描zookeeper上的server父节点，得到当前可用的HRegion Server列表。
3. 和每一个HRegion Server通讯，得到当前已分配的HRegion和HRegion Server的对应关系。
4. 扫描.META.region的集合，计算获得当前还未分配的HRegion，将他们放入待分配HRegion列表。

master下线

因为HMaster只维护表和region的元数据，而不参与表数据IO的过程，HMaster下线仅致使全部元数据的修改被冻结(没法建立删除表，没法修改表的schema，没法进行HRegion的负载均衡，没法处理HRegion 上下线，没法进行HRegion的合并，惟一例外的是HRegion的split能够正常进行，由于只有HRegion Server参与)，表的数据读写还能够正常进行。所以HMaster下线短期内对整个HBase集群没有影响。

从上线过程能够看到，HMaster保存的信息全是能够冗余信息（均可以从系统其它地方收集到或者计算出来）

所以，通常HBase集群中老是有一个HMaster在提供服务，还有一个以上的‘HMaster’在等待时机抢占它的位置。

HBase三个重要机制

1. flush机制

1.（hbase.regionserver.global.memstore.size）默认;堆大小的40%
regionServer的全局memstore的大小，超过该大小会触发flush到磁盘的操做,默认是堆大小的40%,并且regionserver级别的flush会阻塞客户端读写

2.（hbase.hregion.memstore.flush.size）默认：128M
单个region里memstore的缓存大小，超过那么整个HRegion就会flush,

3.（hbase.regionserver.optionalcacheflushinterval）默认：1h
内存中的文件在自动刷新以前可以存活的最长时间

4.（hbase.regionserver.global.memstore.size.lower.limit）默认：堆大小 * 0.4 * 0.95
有时候集群的“写负载”很是高，写入量一直超过flush的量，这时，咱们就但愿memstore不要超过必定的安全设置。在这种状况下，写操做就要被阻塞一直到memstore恢复到一个“可管理”的大小, 这个大小就是默认值是堆大小 * 0.4 * 0.95，也就是当regionserver级别的flush操做发送后,会阻塞客户端写,一直阻塞到整个regionserver级别的memstore的大小为 堆大小 * 0.4 *0.95为止

5.（hbase.hregion.preclose.flush.size）默认为：5M
当一个 region 中的 memstore 的大小大于这个值的时候，咱们又触发了region的 close时，会先运行“pre-flush”操做，清理这个须要关闭的memstore，而后 将这个 region 下线。当一个 region 下线了，咱们没法再进行任何写操做。 若是一个 memstore 很大的时候，flush  操做会消耗不少时间。"pre-flush" 操做意味着在 region 下线以前，会先把 memstore 清空。这样在最终执行 close 操做的时候，flush 操做会很快。

6.（hbase.hstore.compactionThreshold）默认：超过3个
一个store里面容许存的hfile的个数，超过这个个数会被写到新的一个hfile里面 也便是每一个region的每一个列族对应的memstore在flush为hfile的时候，默认状况下当超过3个hfile的时候就会对这些文件进行合并重写为一个新文件，设置个数越大能够减小触发合并的时间，可是每次合并的时间就会越长

2. compact机制

把小的storeFile文件合并成大的HFile文件。
清理过时的数据，包括删除的数据
将数据的版本号保存为1个。

split机制

当HRegion达到阈值，会把过大的HRegion一分为二。
默认一个HFile达到10Gb的时候就会进行切分。

搜索公众号“五分钟学大数据”，深刻钻研大数据技术