HBase的很强大，前提是你要会用

1、Hbase产生背景

自 1970 年以来，关系数据库用于数据存储和维护有关问题的解决方案。大数据的出现后，
好多公司实现处理大数据并从中受益，并开始选择像 Hadoop 的解决方案。Hadoop 使用分
布式文件系统，用于存储大数据，并使用 MapReduce 来处理。Hadoop 擅长于存储各种格式
的庞大的数据，任意的格式甚至非结构化的处理。

Hadoop 的限制
Hadoop 只能执行批量处理，并且只以顺序方式访问数据。这意味着必须搜索整个数据集，
即使是最简单的搜索工作。

当处理结果在另一个庞大的数据集，也是按顺序处理一个巨大的数据集。在这一点上，一个
新的解决方案，需要访问数据中的任何点 （随机访问）单元Hadoop 随机存取数据库应用程序，如 HBase，Cassandra，CouchDB，Dynamo 和 MongoDB 都是一些存储大量数据和以随机方式访问数据的数据。

总结：
（1）海量数据量存储成为瓶颈，单台机器无法 负载大量数据
（2）单台机器 IO 读写请求成为海量数据存储时候 高并发大规模请求的瓶颈
（3）随着数据规模越来越大，大量业务场景开始考虑数据存储 横向水平扩展，使得存储服务可以增加/删除，而目前的关系型数据库更专注于一台机器

1.1、简介

尽量只讲重点
以下五点是 HBase 这个 NoSQL 数据库的要点：
① 它介于 NoSQL 和 RDBMS 之间，仅能通过主键(rowkey)和主键的 range 来检索数据
② HBase 查询数据功能很简单，不支持 join 等复杂操作
③ 不支持复杂的事务，只支持行级事务(可通过 hive 支持来实现多表 join 等复杂操作)。
④ HBase 中支持的数据类型：byte[]（底层所有数据的存储都是字节数组）
⑤ 主要用来存储结构化和半结构化的松散数据。

HBase 中的表特点：

1. 大：一个表可以有上十亿行，上百万列
2. 面向列：面向列(族)的存储和权限控制，列(簇)独立检索。
3. 稀疏：对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。
4. 无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列

1.2、表结构逻辑视图

HBase 以表的形式存储数据。表由行和列组成。列划分为若干个列簇 (Column Family)

1.2.1、行键（RowKey）

与 NoSQL 数据库们一样，rowkey 是用来检索记录的主键。访问 HBase Table 中的行，只有三
种方式：

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

rowkey 行键可以是任意字符串( 最大长度是 64KB，实际应用中长度一般为 10-100bytes)， 最好是 16。在 HBase 内部，rowkey 保存为字节数组。HBase 会对表中的数据按照 rowkey 排序(字典顺序)

1.2.2、列簇（Column Family）

HBase 表中的每个列，都归属与某个列簇。列簇是表的 Schema 的一部分(而列不是)， 必须在使用表之前定义好，而且定义好了之后就不能更改。

列名都以列簇作为前缀。例如 courses:history，courses:math 都属于 courses 这个列簇。访问控制、磁盘和内存的使用统计等都是在列簇层面进行的。

列簇越多，在取一行数据时所要参与 IO、搜寻的文件就越多，所以，如果没有必要，不要设置太多的列簇（最好就一个列簇）。

1.2.3、时间戳（TimeStamp）

HBase 中通过 rowkey 和 columns 确定的为一个存储单元称为 cell。

每个 cell 都保存着同一份数据的多个版本。版本通过时间戳来索引。

时间戳的类型是 64 位整型。时间戳可以由hbase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。

每个 cell 中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。

为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担，hbase 提供了两种数据版

本回收方式：

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

用户可以针对每个列簇进行设置。

1.2.4、单元格（Cell）

由{rowkey, column( = + ), version} 唯一确定的单元。Cell 中的数据是没有类型的，全部是字节码形式存贮。

2、habse 内部原理

2.1、系统架构

Hbase关键词解释：

Client 职责
1、HBase 有两张特殊表：

• .meta.：记录了用户表的 Region 信息，.META.可以有多个 regoin
• -root-：记录了.META.表的 Region 信息，-ROOT-只有一个 region

2、Client 访问用户数据前需要首先访问 zookeeper，找到-root-表的 region 所在的位置，然后访问-root-表，接着访问.meta.表，最后才能找到用户数据的位置去访问，中间需要多次网络操作，不过 client 端会做 cache 缓存。

.meta.：记录了用户表的 Region 信息，.META.可以有多个 rego

-root-：记录了.META.表的 Region 信息，-ROOT-只有一个 region

region：是 hbase 中对表进行切割的单元，由 regionserver 负责管理

zookeeper：

1. ZooKeeper 为 HBase 提供 Failover 机制，选举 master，避免单点 master 单点故障问题
2. 存储所有 Region 的寻址入口：-root-表在哪台服务器上。-root-这张表的位置信息
3. 实时监控 RegionServer 的状态，将 RegionServer 的上线和下线信息实时通知给 Master
4. 存储 HBase 的 schema：包括有哪些 table，每个 table 有哪些 column family。

hamster：

1. 为 RegionServer 分配 region
2. 负责 RegionServer 的负载均衡
3. 发现失效的 RegionServer 并重新分配其上的 region
4. HDFS 上的垃圾文件（hbase）回收
5. 处理 schema 更新请求（表的创建，删除，修改，列簇的增加等等）

regionserver：hbase 中真正负责管理 region 的服务器，也就是负责为客户端进行表数据读写的服务器每一台 regionserver 会管理很多的 region，同一个 regionserver 上面管理的所有的region 不属于同一张表

RegionServer 职责

1. RegionServer 维护 Master 分配给它的 region，处理对这些 region 的 IO 请求
2. RegionServer 负责 Split 在运行过程中变得过大的 region，负责 Compact 操作

HDFS：用来存储 hbase 的系统文件，或者表的 region

总结：

• 可以看到，client 访问 hbase 上数据的过程并不需要 master 参与（寻址访问 zookeeper 和RegioneServer，数据读写访问 RegioneServer），master 仅仅维护者 table 和 region的元数据信息，负载很低。
• .meta. 存的是所有的 region 的位置信息，那么 RegioneServer 当中 region 在进行分裂之后的新产生的 region，是由 master 来决定发到哪个 RegioneServer，这就意味着，只有 master知道 new region 的位置信息，所以，由 master 来管理.meta.这个表当中的数据的 CRUD
• 所以结合以上两点表明，在没有 region 分裂的情况，master 宕机一段时间是可以忍受的。

2.2、物理存储

2.2.1、物理结构图

• 1、Table 中的所有行都按照 row key 的字典序排列。

• 2、Table 在行的方向上分割为多个 Hregion 。

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

• 4、Hregion 是 Hbase 中分布式存储和负载均衡的最小单元 。最小单元就表示不同的 Hregion可以分布在不同的 HRegionServer 上。但一个 Hregion 是不会拆分到多个 server 上的。

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

2.2.2、StoreFile 和 HFile 结构
StoreFile 以 HFile 格式保存在 HDFS 上，请看下图 HFile 的数据组织格式：

首先 HFile 文件是不定长的，长度固定的只有其中的两块：Trailer 和 FileInfo。
正如图中所示：
Trailer 中有指针指向其他数据块的起始点。
FileInfo 中记录了文件的一些 Meta 信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY,
COMPARATOR, MAX_SEQ_ID_KEY 等。

HFile 分为六个部分：
Data Block 段–保存表中的数据，这部分可以被压缩
Meta Block 段 (可选的)–保存用户自定义的 kv 对，可以被压缩。
File Info 段–Hfile 的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。
Data Block Index 段–Data Block 的索引。每条索引的 key 是被索引的 block 的第一条记录的key。
Meta Block Index 段 (可选的)–Meta Block 的索引。
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，snappy。

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 数组里面包含了很多项，并且有固定的结构。我们来看看里面的具体结构：

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

2.2.3、MemStore 和 StoreFile

一个 Hregion 由多个 Store 组成，每个 Store 包含一个列族的所有数据

Store 包括位于内存的一个 memstore 和位于硬盘的多个 storefile 组成

写操作先写入 memstore，当 memstore 中的数据量达到某个阈值，HRegionServer 启动flushcache 进程写入 storefile，每次写入形成单独一个 Hfile

当总 storefile 大小超过一定阈值后，会把当前的 region 分割成两个，并由 HMaster 分配给相应的 region 服务器（regionsever），实现负载均衡

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

2.2.4、HLog(WAL)

WAL 意为 Write ahead log(http://en.wikipedia.org/wiki/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：

1、HLog Sequence File 的 Key 是 HLogKey 对象，HLogKey 中记录了写入数据的归属信息，除了 table 和 region 名字外，同时还包括 sequence number 和 timestamp，timestamp 是”写入时间”，sequence number 的起始值为 0，或者是最

2、HLog Sequece File 的 Value 是 HBase 的 KeyValue 对象，即对应 HFile 中的 KeyValue

2.3、寻址机制

现在假设我们要从 user_info 里面寻找一条 RowKey 是 rk0001 的数据。那么我们应该遵循以
下步骤：

1. 从.META.表里面查询哪个 Region 包含这条数据。
2. 获取管理这个 Region 的 RegionServer 地址。
3. 连接这个 RegionServer，查到这条数据。

系统如何找到某个 RowKey (或者某个 RowKey range)所在的 region
bigtable 使用三层类似 B+树的结构来保存 region 位置。

• 第一层是 zookeeper 里面保存的数据，它持有 root region 的位置。
• 第二层 root region 是.META.表的第一个 region 其中保存了.META.表其它 region 的位置。通过root
  region，我们就可以访问.META.表的数据。
• 第三层是.META.，它是一个特殊的表，保存了 hbase 中所有数据表的 region 位置信息。

说明：

• 1、root region 永远不会被 split，保证了最多需要三次跳转，就能定位到任意 region。
• 2、.META.表每行保存一个 region 的位置信息，rowkey 采用表名+表的最后一行编码而成。
• 3、为了加快访问，.META.表的全部 region 都保存在内存中。
• 4、client 会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果 client 上的缓存全部失效，则需要进行最多 6 次网络来回，才能定位到正确的 region(其中三次用来发现缓存失效，另外三次用来获取位置信息)。

2.4、读写过程

• 1、客户端通过 zookeeper 以及-root-表和.meta.表找到目标数据所在的 regionserver(就是数据所在的region 的主机地址)
• 2、联系 regionserver 查询目标数据
• 3、regionserver 定位到目标数据所在的 region，发出查询请求
• 4、region 先在 memstore 中查找，命中则返回
• 5 、 如 果 在 memstore 中 找 不 到 ， 则 在 storefile 中 扫 描 （ 可 能 会 扫 描 到 很 多 的storefile----BloomFilter）

（BloomFilter，布隆过滤器：迅速判断一个元素是不是在一个庞大的集合内，但是他有一个弱点：它有一定的误判率）
（误判率：原本不存在与该集合的元素，布隆过滤器有可能会判断说它存在，但是，如果布隆过滤器，判断说某一个元素不存在该集合，那么该元素就一定不在该集合内）