HBase

简介

HBase 是 bigtable 的开源山寨版本，是建立在 hdfs 之上，提供高可靠、高性能、列存储、可伸缩、实时读写的数据库系统。
它介于 nosql 和 RDBMS 之间，仅能通过主键（row key）或主键的 range 来检索数据，仅支持单行事务，主要用来存储非结构化或半结化数据。

Features

1. big

   一个表可以有上亿行上百万列

2. column orient

   面向列（族）的存储和权限控制，列（族）独立检索

3. 稀疏 sparse

   对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏

逻辑视图

row key

访问 HBase 中的数据只有三种方式

1. by single row key
2. range of row key
3. scan entire table

Row key 可以是任意字符串（最大长度64KB）， 在 HBase 内部 row key 保存为字节数组，存储时，数据按照 row key 的字典序（byte order）排序存储。

行的一次读写是原子操作。

列族

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

访问控制、磁盘和内存的使用统计都是在列族层面进行的。实际应用中，列族上的控制权限能帮助管理不同类型的应用。

时间戳

HBase 中通过 row key 和 column 确定的一个存储单元称为 cell，每个 cell 都保存同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是64位整型，时间戳可以由 HBase 在写入时自动生成，也可以由客户端显示赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳，每个 cell 中，不同版本的数据按照时间倒序排列，即最新的数据在最前面。为了避免过多的版本造成管理（存储和索引）负担，Hbase 提供了两种数据版本回收方式保存数据的最后N个版本、保存最近一段时间内的版本（近七天），可以针对每个列族进行设置。

cell

由 （row key，column=cf+column qualifier，version）唯一确定的单元，cell 中的数据没有数据类型，全部是字节码形式存储。

物理存储

1. HBase 中行按 row key 的字典序排列
2. Table 在行的方向上分割为多个 Hregion
3. region 按大小分割的，每个表一开始只有一个 region，随着数据不断插入表，region 不断增大，当增大到一定阈值的时候，Hregion 就会等分为两个新的Hregion，当 Table 中的行不断增多，Hregion 就会越来越多
4. Hregion 是 HBase 中分布式存储和负载均衡的最小单元，意味着 Hregion 可以分布在不同的 Hregion server 上，但一个 Hregion 是不会拆分到多个 server 上的
5. Hregion 虽然是分布式存储的最小单元，但并不是存储的最小单元，事实上，Hregion 由一个或多个 Store 组成，每个 Store 保存一个列族，每个 Store 由一个 memStore 和 0或多个 StoreFile 组成，StoreFile 以 Hfile 格式存储在 HDFS 上

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），然后 ，Data Block Index 会被读取到内存中，这样当检索某个 key 时，不需要扫描整个 Hfile，而只需从内存中找到 key 所在的 block，通过一次磁盘 IO 将整个 block 读取到内存中，再找需要的 key，Data Block Index 采用 LRU 机制淘汰。

Hfile 的 Data Block，Meta Block 通常采用压缩方式存储，压缩之后可以大大减少网络和磁盘 IO，随之而来的开销当然是需要花费 CPU 进行压缩和解压缩。

HLog （WAL log）

WAL Write-ahead logging 预写式日志，类似 MySQL 中的 binlog，用来做灾难恢复，HLog 记录数据的所有变更，一旦数据修改，就可以从 log 中恢复。

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

HLog 文件就是一个普通的 Hadoop Sequence File，Sequence File 的 key 是 HLogKey 对象，记录了写入数据的归属信息，除了 table 和 Region 名外，同时还包括 Sequence number 和 timestamp（写入时间），Sequence number 的起始值为0，或者是最近一次存入文件系统中 Sequence number，HLogSequenceFile 的 Value 是 HBase 的 KeyValue 对象。

物理架构

Client

包含访问 HBase 的接口，client 维护着一些 cache 来加快对 HBase 的访问，比如 region 的位置信息

Zookeeper

1. 保证任何时候集群中只有一个 master
2. 存储所有 region 的寻址入口
3. 实时监控 region servers 的状态，将 region server 的上线和下线信息实时通知给 master
4. 存储 HBase 的 schema，包括有哪些 table，每个 table 有哪些 column family

Master

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

Region Server

1. region server 维护 master 分配给它的 region，处理对这些 region 的 IO 请求
2. 负责切分运行过程中变得过大的 region

可以看到，client 访问 HBase 上的数据的过程并不需要 Master 的参与（寻址访问 zookeeper 和 region server，数据读写访问 region server），master 仅仅维护 table 和 region 的元信息，负载很低

关键算法/流程

读写过程

数据在更新时首先写入 HLog （WAL）和内存（memStore）中，memStore 中的数据是排序的，当 memStore 累计到一定阈值时，就会创建一个新的 memStore，并将老的添加到 flush 队列，由单独的线程 flush 到磁盘上成为一个 StoreFile，于此同时，系统会在 zookeeper 中记录一个 redo point，表示这个时刻之前的变更已经持久化了。

当系统发现意外时，可能导致内存（memStore）中的数据丢失，此时使用 HLog 来恢复 checkpoint 后的数据。

StoreFile 是只读的，一旦创建之后不可在修改，因此对 HBase 的更新操作都是不断追加的操作，当一个 Store 中的 StoreFile 达到一定量后就会进行合并（minor compact），将对同一个 key 的修改合并在一起，此时不会删除数据，major compact 会删除数据。

1. client 向 region server 提交写请求
2. region server 找到目标 region
3. region 检查数据是否于 schema 一致
4. 如果客户端未指定版本，则获取当前系统时间作为数据版本
5. 将更新写入 WAL log
6. 将更新写入 memStore
7. 判断 memStore 是否需要 flush

Region 分配

任何时刻，一个 Region 只能分配给一个 Region Server，HMaster 记录了当前有哪些 Region Server，以及当前哪些 Region 分配给了哪些 Region server，哪些 Region 还未分配，当存在未分配的 Region，并且有一个 Region Server 上有可用空间时，HMaster 就给这个 Region Server 发送一个装载请求，把 Region 分配给这个 Region Server。

Region Server 上线

HMaster 使用 zookeeper 来跟踪 Region Server 状态。当某个 Region Server 启动时，会首先在 zookeeper 上的 server 目录下建立代表自己的文件，并获得该文件的独占锁。由于 master 订阅了 server 目录上的变更消息，当 server 目录下的文件出现新增或删除操作时，master 可以得到来自 zookeeper 的实时通知。因此一旦 Region Server 上线，master 能马上得到消息。

Region Server 下线

当 Region Server 下线时，它和 zookeeper 的会话断开，zookeeper 自动释放代表这台 server 的文件上的独占锁。而 master 不断轮询 server 目录下文件的锁状态。如果 master 发现某个 Region Server 丢失了它自己的独占锁，(或者 master 连续几次和 Region Server 通信都无法成功),master 就会尝试去获取代表这个 Region Server 的读写锁，一旦获取成功，就可以确定：1、Region Server 和 zookeeper 之间的网络断开了 2、 Region Server 挂了 的其中一种情况发生了，无论哪种情况，Region Server 都无法继续为它的 region 提供服务了，此时 master 会删除 server 目录下代表这台 Region Server 的文件，并将这台 Region Server 的 region 分配给其它还活着的同志。如果网络短暂出现问题导致 Region Server 丢失了它的锁，那么 Region Server 重新连接到 zookeeper 之后，只要代表它的文件还在，它就会不断尝试获取这个文件上的锁，一旦获取到了，就可以继续提供服务。

Hmaster 上线

1. 从 zookeeper 上获取唯一一个代表 master 的锁，用来阻止其它 master 成为 master
2. 扫描 zookeeper 上的 server 目录，获得当前可用的 Region Server 列表
3. 和2中的每个 Region Server 通信，获得当前已分配的 region 和 Region Server 的对应关系
4. 扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表

Hmaster 下线

由于 master 只维护表和 region 的元数据，而不参与表数据IO的过程，master 下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行 region 的负载均衡，无法处理 region 上下线，无法进行 region 的合并，唯一例外的是 region 的 split 可以正常进行，因为只有 Region Server参与)，表的数据读写还可以正常进行。因此 master 下线短时间内对整个 HBase 集群没有影响。从上线过程可以看到，master 保存的信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来），因此，一般hbase集群中总是有一个 master 在提供服务，还有一个以上的 master 在等待时机抢占它的位置。