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 系统架构

根据这幅图，解释下 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

HRegion server 维护 HMaster 分配给它的 region，处理对这些 region 的 IO 请求

HRegion server 负责切分在运行过程中变得过大的 region

从图中可以看到，Client 访问 HBase 上数据的过程并不需要 HMaster 参与（寻址访问 Zookeeper 和 HRegion server，数据读写访问 HRegione server）

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

HBase 的表数据模型

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 整体结构

HBase 整体结构

Table 中的所有行都按照 Row Key 的字典序排列。

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

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

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

HRegion 虽然是负载均衡的最小单元，但并不是物理存储的最小单元。

事实上，HRegion 由一个或者多个 Store 组成，每个 Store 保存一个 Column Family。

每个 Strore 又由一个 MemStore 和 0 至多个 StoreFile 组成。如上图。

2. StoreFile 和 HFile 结构

StoreFile 以 HFile 格式保存在 HDFS 上。

HFile 的格式为：

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 具体结构

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 表信息

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 的时候就会进行切分。

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