Hbase 基本原理总结

电玩女神 2021-11-11 04:18 378阅读 0赞

# 一、**HBase 基本框架** #

## **1、框架结构** ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70][]

HBase是一个构建在HDFS上的分布式列存储系统；HBase是Apache Hadoop生态系统中的重要一员，主要用于海量结构化数据存储；从逻辑上讲，HBase将数据按照表、行和列进行存储。与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

## **2、Hbase表的特点** ##

（1）、大：一个表可以有数十亿行，上百万列；

（2）、无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；

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

（4）、稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；

（5）、数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；

（6）、数据类型单一：Hbase中的数据都是字符串，没有类型。

## 3、**HBase 中相关模块的作用：** ##

**（1）Master**

*  HBase Master用于协调多个Region Server，
 *  侦测各个RegionServer之间的状态，
 *  并平衡RegionServer之间的负载。
 *  HBaseMaster还有一个职责就是负责分配 Region 给RegionServer。
 *  HBase允许多个Master节点共存，但是这需要Zookeeper的帮助。不过当多个Master节点共存时，只有一个Master是提供服务的，其他的Master节点处于待命的状态。当正在工作的Master节点宕机时，其他的Master则会接管HBase的集群。

**（2）Region Server**

![20190911173721721.png][]

*  对于一个RegionServer而言，其包括了多个Region。
 *  RegionServer的作用只是***管理表格，以及实现读写操作***。
 *  ***Client 直接连接 RegionServer***，并通信获取HBase中的数据。
 *  ***对于Region而言，则是真实存放HBase数据的地方***，也就说Region是HBase可用性和分布式的基本单位。
 *  如果当一个表格很大，并由多个CF组成时，那么表的数据将存放在多个Region之间，并且在每个Region中会关联多个存储的单元（Store）。

**（3）Zookeeper**

*  对于 HBase 而言，Zookeeper的作用是至关重要的。
 *  Zookeeper是作为HBase Master的HA解决方案。也就是说，是Zookeeper保证了至少有一个HBase Master 处于运行状态。并且Zookeeper负责Region和Region Server的注册。
 *  Zookeeper发展到目前为止，已经成为了分布式大数据框架中容错性的标准框架。不光是HBase，几乎所有的分布式大数据相关的开源框架，都依赖于Zookeeper实现HA。

# 二、Hbase数据模型 #

## 1、基本概念 ##

**RowKey**：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要；

**Column Family**：列族，拥有一个名称(string)，包含一个或者多个相关列；

**Column**：属于某一个columnfamily，familyName:columnName，每条记录可动态添加；

**Version Number**：类型为Long，***默认值是系统时间戳***，可由用户自定义；

**Value(Cell)**：Byte array。

## 2、物理模型 ##

*  每个column family存储在HDFS上的一个***单独文件中，空值不会被保存。***
 *  ***Key 和 Version number在每个 column family中均有一份***；
 *  HBase 为每个值维护了***多级索引***，即：<key, column family, column name, timestamp>

### （1）、物理存储结构 ###

*  a、Table中所有行都按照**row key的字典序排列**；
 *  b、Table在**行的方向上分割为多个Region**；
 *  c、Region按大小分割的，每个表开始只有一个region，随着数据增多，region不断增大，当增大到一个阀值的时候，***region就会等分会两个新的region***，之后会有越来越多的region；
 *  d、Region是Hbase中分布式存储和负载均衡的最小单元，不同Region分布到不同RegionServer上。
 *  e、Region虽然是分布式存储的最小单元，但并不是存储的最小单元。Region由一个或者多个Store组成，每个store保存一个columns family；每个Strore又由一个memStore和0至多个StoreFile组成，StoreFile包含HFile；**memStore存储在内存中，StoreFile存储在HDFS上**。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 2][]

### （2）、**ROOT表和META表** ###

*  HBase的所有***Region元数据被存储在*.META.表**中，
 *  **随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。**
 *  **为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，**最后由Zookeeper记录-ROOT-表的位置信息。所
 *  有客户端访问用户数据前，需要***首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，***如下图所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 3][]

*  **ROOT-表永远不会被分割，它只有一个Region，这样可以保证最多只需要三次跳转就可以定位任意一个Region。**
 *  为了加快访问速度，**.META.表的所有Region全部保存在内存中。**
 *  ***客户端***会将查询过的位置信息***缓存***起来，且缓存不会主动失效。
 *  **如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。**
 *  如果前面的信息全部失效，则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的Region。

# 三、Hbase高可用 #

完整分布式的Hbase组成示意图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 4][]

## 1、 **数据高可用——Write-Ahead-Log（WAL）保障** ##

*  HBase中的HLog机制是WAL的一种实现，而***WAL（一般翻译为预写日志）是事务机制中常见的一致性的实现方式***。
 *  每个R***egionServer中都会有一个HLog的实例***，RegionServer会将更新操作（如 Put，Delete）先记录到 WAL（也就是HLog）中，然后将其写入到Store的MemStore，最终MemStore会将数据写入到持久化的HFile中（MemStore 到达配置的内存阀值）。这样就保证了HBase的写的可靠性。
 *  如果没有 WAL，当RegionServer宕掉的时候，***MemStore 还没有写入到HFile***，或者StoreFile还没有保存，数据就会丢失。或许有的读者会担心***HFile本身会不会丢失，这是由 HDFS 来保证的。***在HDFS中的数据默认会有3份。因此这里并不考虑 HFile 本身的可靠性。
 *  ***HFile由很多个数据块（Block）组成，并且有一个固定的结尾块。***其中的数据块是由一个Header和多个Key-Value的键值对组成。在结尾的数据块中包含了数据相关的索引信息，系统也是通过结尾的索引信息找到HFile中的数据。

## 2、组件高可用 ##

*  **Master容错**：Zookeeper重新选择一个新的Master。如果无Master过程中，数据读取仍照常进行，但是，region切分、负载均衡等无法进行；
 *  **RegionServer容错**：定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer；
 *  **Zookeeper容错**：Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例。

# 四、Hbase读写流程 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 5][]

上图是RegionServer数据存储关系图。

*  三中提到，HBase使用MemStore和StoreFile存储对表的更新。***数据在更新时首先写入HLog和MemStore。***MemStore中的数据是排序的，***当MemStore累计到一定阈值时，就会创建一个新的MemStore，***并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。
 *  与此同时，系统会在Z***ookeeper中记录一个CheckPoint，***表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致MemStore中的数据丢失，此时使用HLog来恢复CheckPoint之后的数据。
 *  ***StoreFile是只读的，***一旦创建后就不可以再修改。因此Hbase的更新其实是***不断追加***的操作。
 *  当一个Store中的StoreFile达到一定阈值后，就会进行一次合并操作,将对同一个key的修改合并到一起，形成一个大的StoreFile。当StoreFile的大小达到一定阈值后，又会对 StoreFile进行切分操作，等分为两个StoreFile。

## 1、Hbase写操作 ##

(1) 、Client通过Zookeeper的调度，***向RegionServer发出写数据请求，在Region中写数据。***

(2) 、数据被写入Region的MemStore，直到MemStore达到预设阈值。

(3***)、 MemStore中的数据被Flush成一个StoreFile。***

(4)、 随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发 Compact 合并操作，***将多个StoreFile合并成一个StoreFile，***同时进行版本合并和数据删除。

(5) 、StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。

(6) 、***单个StoreFile大小超过一定阈值后，触发 Split 操作***，把当前 Region Split成 2 个新的 Region。父 Region 会下线，新Split 出的 2 个子 Region 会被 HMaster 分配到相应的 RegionServer 上，使得原先1个Region的压力得以分流到2个Region 上。

***注意：可以看出HBase只有增添数据，所有的更新和删除操作都是在后续的Compact历程中举行的，使得用户的写操作只要进入内存就可以立刻返回，实现了HBase I/O的高机能。***

## 2、Hbase读操作 ##

(1)、 Client访问Zookeeper，***查找-ROOT-表***，***获取.META.表信息***。

(2)、 从.META.表查找，获取存放目标数据的 Region 信息，从而找到对应的RegionServer。

(3) 、通过 RegionServer 获取需要查找的数据。

(4)、Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。**读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。**

***注意：寻址过程：client-->Zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client***

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70]: /images/20211109/5c25087a518f407592297075d533f7e3.png
[20190911173721721.png]: /images/20211109/b380fde6e5da41cb9888679309cdf30d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 1]: /images/20211109/87cd796cbcc14f53ac95db0e532c35d9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 2]: /images/20211109/6b4c55d686d94e40bd113b701bb00a69.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 3]: /images/20211109/3280c3c3fe2d40c59db21698dcef2f8c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 4]: /images/20211109/ab8721e4417b4413b4a99be8fab09ab3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3MyOTQ4NzgzMDQ_size_16_color_FFFFFF_t_70 5]: /images/20211109/5fb798fd953649d389dfff53e2f34e2e.png