HBase数据模型和读写原理

心已赠人 2022-04-25 02:16 322阅读 0赞

Hbase的数据模型和读写原理：

HBase是一个开源可伸缩的分布式数据库,他根据Google Bigtable数据模型构建在hadoop的hdfs存储系统之上。

HBase是一个稀疏、多维度、排序的映射表。表的索引是行键、列族、列限定符和时间戳，一个列族中可以包含任意多个列，同一个列族里面数据存储在一起。同一张表的每行数据的列的值都可以为空，所以说HBase是稀疏的。

Hbase在执行执行更新操作的时候，旧版本的数据不会被删除，新的版本的数据与旧版本的数据的区分以时间戳为准，数据在存储的时候，会按照时间戳排序，客户端可以根据时间戳排序。客户端可以根据时间戳获取不同时间的数据，如果在查询的时候不提供时间戳，那么会发挥距离现在最近的那一个版本的数据。HBase提供了两种数据版本回收方式：1.保留数据的最后n个版本，2.保存近7天的版本。

## 数据模型 ##

HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳每个值是一个未经解释的字符串。

表(Table)：一个HBase表由行和列组成，列划分为若干个 列族。

行(Row)：在表里面，每一行代表着一个数据对象，每一行都是以一个行键(Row Key)来进行唯一标识，行键可以是任意字符串，在HBase内部，行键保存为字符数组，数据存储时，按照行键的字典序排列。

列族(Column Family)：列族支持动态扩展，可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储，用户需要自行进行数据类型地转换。一个HBase表被分组成为许多“列族”的集合，它是基本的访问控制单元。

列标识(Column Qualifier)：列族中的数据通过列标识符来进行定位，列标识也没有特定的数据类型，以二进制字节来存储。

单元格(Cell)：每一个行键，列族和列标识符共同确定一个单元，存储在单元里的数据称为单元数据，单元和单元数据也没有的挺的数据类型，以二进制字节来存储。

时间戳(Timestap)：默认每一个单元中的数据插入时都会用时间戳来进行版本标识。读取单元数据时，如果时间戳没有被指定，则默认返回最新你的数据，写入新的单元格数据时，如果没有设置时间戳，默认用当前时间，每一个列族的单元数据的版本数量都被HBase单独维护默认情况下HBase保留3个版本数据。

## 逻辑模型 ##

时候，你也可以把HBase看成一个多维度的Map模型去理解它的数据模型。正如下图，一个行键映射一个列族数组，列族数组中的每个列族又映射一个列标识数组，列标识数组中的每一个列标识(Column Qualifier)又映射到一个时间戳数组，里面是不同时间戳映射下不同版本的值，但是默认取最近时间的值，所以可以看成是列标识(Column Qualifier)和它所对应的值的映射。用户也可以通过HBase的API去同时获取到多个版本的单元数据的值。Row Key在HBase中也就相当于关系型数据库的主键，并且Row Key在创建表的时候就已经设置好，用户无法指定某个列作为Row Key。

![Fbm0nx.png][]

又有的时候，你也可以把HBase看成是一个类似Redis那样的Key-Value数据库。如下图，当你要查询某一行的所有数据时，Row Key就相当于Key，而Value就是单元中的数据(列族，列族里的列和列中时间戳所对应的不同版本的值)；当深入到HBase底层的存储机制时，用户要查询指定行里某一条单元数据时，HBase会去读取一个数据块，里面除了有要查询的单元数据，可能同时也会获取到其它单元数据，因为这个数据块还包含着这个Row Key所对应的其它列族或其它的列信息，这些信息实际也代表着另一个单元数据，这也是HBase的API内部实际的工作原理。

![FbmBB6.png][]

## 物理模型 ##

逻辑数据模型中空白cell在物理上是不存储的，因此若一个请求为要获取t8时间的contents:html，他的结果就是空。相似的，若请求为获取t9时间的anchor:my.look.ca，结果也是空。但是，如果不指明时间，将会返回最新时间的行，每个最新的都会返回。

在一个HBase中，存储了很多HBase表，当表中包含的行数量非常庞大，无法在一台机器上存储时，需要分布存储到多台机器上，需要根据行键的值对表中进行分区，每个行分区被称为“Region”。

Master主服务器把不同的Region分配到不同的Region服务器上，同一个Region不会拆分到多个Region服务器上，每个Region服务器负责管理一个Region集合，通常每个Region服务器上会放置10~1000个Region。

![FbnTqx.png][]

## 复合键设计 ##

Hbase由两种基本的键结构：行键和列键，行键存储本身的内容，行键存储键的排序顺序，列键包含了列族和特定的列限定符，磁盘上一个列族下的所有单元格的内容都存储在文件中，不同同列族的单元格不会出现在同一个存储文件中。不同列族的单元格不会出现在同一个存储文件中。实际上，每个单元格在存储时，同时保存了列键、行键和时间戳，羁绊存了在表中的位置信息。

在设计HBase表时，行键是最重要的，行键决定了访问HBase表可以得到的性能，这个结论根植于两个实时：region基于行键为一个区间的行提供忘，并负责区间的每一行；HFile在硬盘上存储有序的行，当Region刷写到内存里的行生成HFile。这些行已经排过序，也会有序地刷写到硬盘上。

优秀地行键设计可以保证良好地HBase性能：

1.行键存储在HBase中地每个单元格中，如果行键越长，用于存储单元格地I/O开销会越大。

2.对于组合行每个组件地排序顺序取决于访问模式。

主机名 事件类型 时间戳：适合访问模式使用主机名和事件类型地查询日志方式。

事件类型 时间戳 主机名：适合访问模式用于时间类型和时间戳查询日志地方式。

事件类型 反转时间戳 主机名 ：反转时间戳的值是Long.MAX\_VALUE减去时间戳；这样可以确保最近发生的事件排在前面，适用于按照事件发生顺序及逆行处理的场合。

倒叙时间戳作为键的一部分可以快速的找到数据库中数据的最近版本。由于HBase的键是排序的，该键排在任何比它老的行键的前面，所以最近的版本必然是第一个。

**注意： 行键不能发改变，唯一可以“改变”的方式是删除然后再插入。这是一个网上常问的问题，所以需要开始就要让行键正确。**

## 数据结构 ##

### RowKey ###

与nosql数据库们一样,RowKey是用来检索记录的主键。访问HBASE table中的行，只有三种方式：

1.通过单个RowKey访问

2.通过RowKey的range（正则）

3.全表扫描

RowKey行键 (RowKey)可以是任意字符串(最大长度是64KB，实际应用中长度一般为 10-100bytes)，在HBASE内部，RowKey保存为字节数组。存储时，数据按照RowKey的字典序(byte order)排序存储。设计RowKey时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)

### Column Family ###

列族：HBASE表中的每个列，都归属于某个列族。列族是表的schema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如 courses:history，courses:math都属于courses这个列族。

### Cell ###

由\{rowkey, column Family:columu, version\} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。

关键字：无类型、字节码

### Time Stamp ###

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

为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担，HBASE提供了两种数据版本回收方式。一是保存数据的最后n个版本，二是保存最近一段时间内的版本（比如最近七天）。用户可以针对每个列族进行设置。

### 命名空间 ###

![FhsWfx.png][]

**Table**：表，所有的表都是命名空间的成员，即表必属于某个命名空间，如果没有指定，则在default默认的命名空间中。

**RegionServer group：**一个命名空间包含了默认的RegionServer Group。

**Permission：**权限，命名空间能够让我们来定义访问控制列表ACL（Access Control List）。例如，创建表，读取表，删除，更新等等操作。

**Quota：**限额，可以强制一个命名空间可包含的region的数量。

## Hbase原理 ##

### HBase读流程 ###

![Fh4vIU.png][]

1.  Client先访问zookeeper，从meta表读取region的位置，然后读取meta表中的数据。meta中又存储了用户表的region信息；
2.  根据namespace、表名和rowkey在meta表中找到对应的region信息；
3.  找到这个region对应的regionserver；
4.  查找对应的region；
5.  先从MemStore找数据，如果没有，再到BlockCache里面读；
6.  BlockCache还没有，再到StoreFile上读(为了读取的效率)；
7.  如果是从StoreFile里面读取的数据，不是直接返回给客户端，而是先写入BlockCache，再返回给客户端。

### HBase写流程 ###

![Fh5pRJ.png][]

1.  Client向HregionServer发送写请求；
2.  HregionServer将数据写到HLog（write ahead log）。为了数据的持久化和恢复；
3.  HregionServer将数据写到内存（MemStore）；
4.  反馈Client写成功。

### 数据flush过程 ###

1.  当MemStore数据达到阈值（默认是128M，老版本是64M），将数据刷到硬盘，将内存中的数据删除，同时删除HLog中的历史数据；
2.  并将数据存储到HDFS中；

### 数据合并过程 ###

1.  当数据块达到4块，**Hmaster**将数据块加载到本地，进行合并；
2.  当合并的数据超过256M，进行拆分，将拆分后的Region分配给不同的HregionServer管理；
3.  当HregionServer宕机后，将HregionServer上的hlog拆分，然后分配给不同的HregionServer加载，修改.META.；
4.  **注意：HLog会同步到HDFS。**

[Fbm0nx.png]: /images/20220210/97df019857e44301bddf7cbbb216b39f.png
[FbmBB6.png]: /images/20220210/22a3a5348afe4172b97fa316f83150b5.png
[FbnTqx.png]: /images/20220210/d3935ac9df5e4630ab0fd41d2da2a786.png
[FhsWfx.png]: /images/20220210/0a81a9cce187493a9b9d3d94572ac1bc.png
[Fh4vIU.png]: /images/20220210/00b9ae0c93bc48f4a81ed80e7b5ee8fa.png
[Fh5pRJ.png]: /images/20220210/d152ec9ea6a94b0ba6a6da832c17cf22.png