HBase的理论知识

骑猪看日落 2022-11-20 04:53 206阅读 0赞

# **Hbase** #

![20201108165738718.png][]

## **1 HBase的概念** ##

**HBase**，**基于Google Bigtable实现的开源、分布式、可伸缩的列式存储数据库，**诞生于Hadoop，也是Hadoop生态的重要一环，如今作为一个Apache顶级项目，早已经不能将其仅仅看作Hadoop的一部分，基于Storm，Spark等框架的数据处理方案中，都有它的身影，可以说它已经成为大数据工具箱中非常重要的一种数据存储工具，也因此必然会被很纳入很多人学习计划。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70][]

**Hbase的元数据放在zookeeper，真实数据放在hdfs上。**

命名空间(namespace):0.96版本开始支持，是对多个表的逻辑分组，类似于关系数据库的database。

### **1.1 HBase 这个 NoSQL 数据库的要点** ###

① 它介于 NoSQL 和 RDBMS 之间，仅能通过主键(rowkey)和主键的范围来检索数据

② HBase 查询数据功能很简单，不支持 join 等复杂操作

③ 不支持复杂的事务，只支持行级事务(可通过 hive 支持来实现多表 join 等复杂操作)。

④ HBase 中支持的数据类型：byte\[\]（底层所有数据的存储都是字节数组）

⑤ 主要用来存储结构化和半结构化的松散数据。

### **1.2 HBase 中的表特点** ###

1、**大**：一个表可以有上十亿行，上百万列

2、**面向列**：面向列(族)的存储和权限控制，列(簇)独立检索。

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 1][]

### **1.3 Rowkey的概念** ###

**Rowkey的概念和mysql中的主键是完全一样的，Hbase使用Rowkey来唯一的区分某一行的数据。**

由于Hbase只支持3中查询方式：

1、基于Rowkey的单行查询

2、基于Rowkey的范围扫描

3、全表扫描

因此，Rowkey对Hbase的性能影响非常大，Rowkey的设计就显得尤为的重要。设计的时候要兼顾基于Rowkey的单行查询也要键入Rowkey的范围扫描。具体Rowkey要如何设计后续会整理相关的文章做进一步的描述。这里大家只要有一个概念就是Rowkey的设计极为重要。

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

### **1.4 HBase写数据流程** ###

1、Client先访问zookeeper，从meta表获取相应region信息，然后找到meta表的数据

2、从namespace、表名和rowkey根据meta表的数据找到写入数据对应的region信息

3、找到对应的regionserver

4、把数据分别写到HLog和MemStore上一份

5、MemStore达到一个阈值后则把数据刷成一个StoreFile文件。（若MemStore中的数据有丢失，则可以从HLog上恢复）

6、当多个StoreFile文件达到一定的大小后，会触发Compact合并操作，合并为一个StoreFile，（这里同时进行版本的合并和数据删除。）

7、当Storefile大小超过一定阈值后，会把当前的Region分割为两个（Split），并由Hmaster分配到相应的HRegionServer，实现负载均衡

### **1.5 HBase读数据流程** ###

1、Client先访问zookeeper，从meta表读取region的位置，然后读取meta表中的数据。meta中又存储了用户表的region信息。

2、根据namespace、表名和rowkey在meta表中找到对应的region信息

3、找到这个region对应的regionserver

4、查找对应的region

5、先从MemStore找数据，如果没有，再到StoreFile上读(为了读取的效率)。

## **2 HBase的RowKey设计** ##

### **2.1 Rowkey长度原则** ###

Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议说设计在10~100个字节，不过建议是越短越好，不要超过16个字节。

原因如下：

（1）数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100\*1000万=10亿个字节，将近1G数据，这会极大影响HFile的存储效率；

（2）MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此Rowkey的字节长度越短越好。

（3）目前操作系统是都是64位系统，内存8字节对齐。控制在16个字节，8字节的整数倍利用操作系统的最佳特性。

### **2.2 Rowkey散列原则** ###

如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。

### **2.3 Rowkey唯一原则** ###

必须在设计上保证其唯一性。

** **

**问：****你们公司hbase遇到过数据倾斜****（****热点问题****）****吗？你们是怎么解决的？**

**   **答： 有，我们在md5的方式在row key上加上一个随机数，只要region所管理的start-end keys范围比较随机，**往region上写数据时就不会按照自下而上的方式写数据**，而是随机的写，这样就解决了数据热点问题。

## **3 HBase架构组成** ##

HBase采用Master/Slave架构搭建集群，它隶属于Hadoop生态系统，由以下类型节点组成：HMaster节点、HRegionServer节点、ZooKeeper集群，而在底层，它将数据存储于HDFS中，因而涉及到HDFS的NameNode、DataNode等，总体结构如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 2][]

**HMaster与HRegionServer进行心跳感知！！！**

其中

### **3.1 HMaster节点用于：   1、管理HRegionServer，实现其负载均衡。** ###

2、管理和分配HRegion，比如在HRegion split时分配新的HRegion；在HRegionServer退出时迁移其内的HRegion到其他HRegionServer上。

3、实现DDL操作（Data Definition Language，namespace和table的增删改，column familiy的增删改等）。

4、管理namespace和table的元数据（实际存储在HDFS上）。

5、权限控制（ACL）。

### **3.2 HRegionServer节点用于：** ###

1、存放和管理本地HRegion。

2、读写HDFS，管理Table中的数据。

3、Client直接通过HRegionServer读写数据（从HMaster中获取元数据，找到RowKey所在的HRegion/HRegionServer后）。

HRegionServer一般和DataNode在同一台机器上运行，实现数据的本地性。HRegionServer包含多个HRegion，由WAL(HLog)、BlockCache、MemStore、HFile组成。  
**WAL即Write Ahead Log**，在早期版本中称为HLog，它是HDFS上的一个文件，如其名字所表示的，所有写操作都会先保证将数据写入这个Log文件后，才会真正更新MemStore，最后写入HFile中。采用这种模式，可以保证HRegionServer宕机后，我们依然可以从该Log文件中读取数据，Replay所有的操作，而不至于数据丢失。这个Log文件会定期Roll出新的文件而删除旧的文件(那些已持久化到HFile中的Log可以删除)。WAL文件存储在/hbase/WALs/$\{HRegionServer\_Name\}的目录中(在0.94之前，存储在/hbase/.logs/目录中)，一般一个HRegionServer只有一个WAL实例，也就是说一个HRegionServer的所有WAL写都是串行的(就像log4j的日志写也是串行的)，这当然会引起性能问题，因而在HBase 1.0之后，通过[HBASE-5699][]实现了多个WAL并行写(MultiWAL)，该实现采用HDFS的多个管道写，以单个HRegion为单位。关于WAL可以参考Wikipedia的[Write-Ahead Logging][]。顺便吐槽一句，英文版的维基百科竟然能毫无压力的正常访问了，这是某个GFW的疏忽还是以后的常态？

**BlockCache是一个读缓存**，即“引用局部性”原理（也应用于CPU，分空间局部性和时间局部性，空间局部性是指CPU在某一时刻需要某个数据，那么有很大的概率在一下时刻它需要的数据在其附近；时间局部性是指某个数据在被访问过一次后，它有很大的概率在不久的将来会被再次的访问），将数据预读取到内存中，以提升读的性能。HBase中提供两种BlockCache的实现：默认on-heap LruBlockCache和BucketCache(通常是off-heap)。通常BucketCache的性能要差于LruBlockCache，然而由于GC的影响，LruBlockCache的延迟会变的不稳定，而BucketCache由于是自己管理BlockCache，而不需要GC，因而它的延迟通常比较稳定，这也是有些时候需要选用BucketCache的原因。这篇文章[BlockCache101][]对on-heap和off-heap的BlockCache做了详细的比较。

**HRegion是一个Table中的一个Region在一个HRegionServer中的表达**。**一个Table可以有一个或多个Region，他们可以在一个相同的HRegionServer上，也可以分布在不同的HRegionServer上，一个HRegionServer可以有多个HRegion，他们分别属于不同的Table。**

**HRegion由多个Store(HStore)构成，每个HStore对应了一个Table在这个HRegion中的一个Column Family，即每个Column Family****（****列族****）****就是一个集中的存储单元，**因而最好将具有相近IO特性的Column存储在一个Column Family（列族），以实现高效读取(数据局部性原理，可以提高缓存的命中率)**。HStore是HBase中存储的核心，它实现了读写HDFS功能，一个HStore由一个MemStore 和****0****个或多个StoreFile组成。**

**MemStore是一个写缓存**(In Memory Sorted Buffer)，所有数据的写在完成WAL日志写后，会写入MemStore中，由MemStore根据一定的算法将数据Flush到地层HDFS文件中(HFile)，通常每个HRegion中的每个 Column Family有一个自己的MemStore。

**HFile(StoreFile) 用于存储HBase的数据(Cell/KeyValue)**。在HFile中的数据是按RowKey、Column Family、Column排序，对相同的Cell(即这三个值都一样)，则按timestamp倒序排列。

### **3.3 ZooKeeper集群是协调系统，用于：   1、存放整个 HBase集群的元数据以及集群的状态信息。** ###

2、实现HMaster主从节点的**失效****备援** 。  
ZooKeeper为HBase集群提供协调服务，它管理着HMaster和HRegionServer的状态(available/alive等)，并且会在它们宕机时通知给HMaster，从而HMaster可以实现HMaster之间的失效备援，或对宕机的HRegionServer中的HRegion集合的修复(将它们分配给其他的HRegionServer)。ZooKeeper集群本身使用一致性协议(PAXOS协议)保证每个节点状态的一致性。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 3][]

### **3.4 How The Components Work Together？** ###

ZooKeeper协调集群所有节点的共享信息，在HMaster和HRegionServer连接到ZooKeeper后创建Ephemeral节点，并使用Heartbeat机制维持这个节点的存活状态，如果某个Ephemeral节点失效，则HMaster会收到通知，并做相应的处理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 4][]  
  
另外，HMaster通过监听ZooKeeper中的Ephemeral节点(默认：/hbase/rs/\*)来监控HRegionServer的加入和宕机。在第一个HMaster连接到ZooKeeper时会创建Ephemeral节点(默认：/hbasae/master)来表示Active的HMaster，其后加进来的HMaster则监听该Ephemeral节点，如果当前Active的HMaster宕机，则该节点消失，因而其他HMaster得到通知，而将自身转换成Active的HMaster，在变为Active的HMaster之前，它会创建在/hbase/back-masters/下创建自己的Ephemeral节点。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 5][]

HBase Client通过RPC方式和HMaster、HRegionServer通信；一个HRegionServer可以存放1000个HRegion；底层Table数据存储于HDFS中，而HRegion所处理的数据尽量和数据所在的DataNode在一起，实现数据的本地化；数据本地化并不是总能实现，比如在HRegion移动时，需要等下一次Compact才能继续回到本地化。

**Hbase中的meta表放在zookeeper里，meta表里有info元数据，当执行start-hbase.sh的时候，会将zookeeper里存放的meta表结构信息放入内存，然后将hdfs上的真实数据组合起来！！！**

本着半翻译的原则，再贴一个《An In-Depth Look At The HBase Architecture》的架构图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 6][]  
  
这个架构图比较清晰的表达了HMaster和NameNode都支持多个热备份，使用ZooKeeper来做协调；**ZooKeeper并不是云般神秘，它一般由三台机器组成一个集群，内部使用PAXOS算法支持三台Server中的一台宕机，也有使用五台机器的，此时则可以支持同时两台宕机，既少于半数的宕机，然而随着机器的增加，它的性能也会下降**；**RegionServer和DataNode一般会放在相同的Server上实现数据的本地化。**

### **3.5 HRegion：** ###

HBase使用RowKey将表水平切割成多个HRegion，从HMaster的角度，每个HRegion都纪录了它的**有且仅有一个**StartKey和**有且仅有一个**EndKey（第一个HRegion的StartKey为空，最后一个HRegion的EndKey为空），由于**RowKey是排序的**（环形缓冲区进行字典排序或者是LinkedHashmap排序，**每个HRegion里的RowKey是有序的，各个HRegion相对是无序的**），因而**Client可以通过HMaster快速的定位每个RowKey在哪个HRegion中。HRegion由HMaster分配到相应的HRegionServer中，然后由HRegionServer负责HRegion的启动和管理，和Client的通信，****以及****负责数据的读(使用HDFS)**。每个HRegionServer可以同时管理1000个左右的HRegion（这个数字怎么来的？没有从代码中看到限制，难道是出于经验？超过1000个会引起性能问题？

**来回答这个问题**：感觉这个1000的数字是从BigTable的论文中来的（5 Implementation节）：Each tablet server manages a set of tablets(typically we have somewhere between ten to a thousand tablets per tablet server)）。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 7][]

## **4 META表结构** ##

在 HBase Shell 里对meta表进行 scan 和 describe ：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 8][]

可以看出，meta表的结构如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 9][]

meta表中每一行记录了一个Region的信息。

**1) RowKey**

RowKey就是Region Name，它的命名形式是TableName,StartKey,TimeStamp.Encoded.。

其中 Encoded 是TableName,StartKey,TimeStamp的md5值。

例如：

mytable,,1438832261249.ea2b47e1eba6dd9a7121315cdf0e4f67.

表名是mytable，StartKey为空，时间戳是1438832261249，前面三部分的md5是：

$ echo -n "mytable,,1438832261249" | md5sum   \# -n选项表示不输出换行符

ea2b47e1eba6dd9a7121315cdf0e4f67  -

**2) Column Family**

.META.表有两个Column Family：info 和 historian。

其中info包含了三个Column：

*  regioninfo：region的详细信息，包括StartKey、EndKey以及Table信息等等。
 *  server：管理该region的 RegionServer 的地址。
 *  serverstartcode：RegionServer 开始托管该region的时间。

至于historian：

That was a family used to keep track of region operations like open,   
close, compact, etc. It proved to be more troublesome than handy so we   
disabled this feature until coming up with a better solution. The   
family stayed for backward compatibility.

大致的意思是：这个Column Family是用来追踪一些region操作的，例如open、close、compact等。事实证明这非常的麻烦，所以在想出一个更好的解决方案之前我们禁用了此功能。这个列族会保持向后兼容。

**综上所述**，.META.表中保存了所有用户表的region信息，在进行数据访问时，它是必不可少的一个环节。当Region被拆分、合并或者重新分配的时候，都需要来修改这张表的内容来保证访问数据时能够正确地定位region。

## **5 进入HBase命令行** ##

**hbase shell**** 进入命令行模式**

## **6 过滤器** ##

1、SingleColumnValueFilter

SingleColumnValueFilter 用于测试值的情况（相等，不等，范围 、、、）

2、SingleColumnValueExcludeFilter

跟SingleColumnValueFilter 功能一样，只是不查询出该列的值。

3、FamilyFilter

用于过滤列族（通常在 Scan 过程中通过设定某些列族来实现该功能，而不是直接使用该过滤器）。

4、QualifierFilter

用于列名（Qualifier）过滤

5、ColumnPrefixFilter

用于列名（Qualifier）前缀过滤，即包含某个前缀的所有列名。

6、RowFilter

行键过滤器，一般来讲，执行 Scan 使用 startRow/stopRow 方式比较好，而 RowFilter 过滤器也可以完成对某一行的过滤。

7、RandomRowFilter

该过滤器是随机选择一行的过滤器。参数 chance 是一个浮点值，介于 0.1 和 1.0 之间。

8、PageFilter

用于按行分页。

[20201108165738718.png]: /images/20221120/fd0a85aa21794ef2a50c701334f86933.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70]: /images/20221120/abd04789cc0a4827815ff0ea6cfad035.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 1]: /images/20221120/ce7e4e7caf4e4656b50f98ec1831b1b3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 2]: /images/20221120/21fe6dc82bd842f98dfd793896c5127a.png
[HBASE-5699]: https://issues.apache.org/jira/browse/HBASE-5699
[Write-Ahead Logging]: https://en.wikipedia.org/wiki/Write-ahead_logging
[BlockCache101]: http://www.n10k.com/blog/blockcache-101/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 3]: /images/20221120/86b1144669e9434481abe01a8a858f96.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 4]: /images/20221120/3219faa042c942b9844c6eb90cc435f0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 5]: /images/20221120/7fc50b9ec6c24fda8405b6660f85bb93.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 6]: /images/20221120/2d7746a93aed40278db2d88c3b2c6119.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 7]: /images/20221120/d9c518882a744478816f422dcf3f0f65.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 8]: /images/20221120/d94155bf658a45d6854ea675d8b3c0cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0bDE5OTI_size_16_color_FFFFFF_t_70 9]: /images/20221120/794f219437b24302b1583685556e0b1e.png