【大数据】分布式数据库HBase

布满荆棘的人生 2024-05-02 20:14 109阅读 0赞

![a714d88af64f4116b87eb994e20fac82.png][]

**目录**

1.概述

1.1.前言

1.2.数据模型

1.3.列式存储的优势

2.实现原理

2.1.region

2.2.LSM树

2.3.完整读写过程

2.4.master的作用

--------------------

## 1.概述 ##

### 1.1.前言 ###

本文式作者大数据系列专栏中的一篇文章，按照专栏来阅读，循序渐进能更好的理解，专栏地址：

[https://blog.csdn.net/joker\_zjn/category\_12631789.html?spm=1001.2014.3001.5482][https_blog.csdn.net_joker_zjn_category_12631789.html_spm_1001.2014.3001.5482]

当前的分布式数据库其实都是参考的Google的BigTable，所以学习分布式数据库之前先学一下BigTable会一通百通。专栏中有对BigTable进行介绍的前文：

[【大数据】bigtable，分布式数据库的鼻祖-CSDN博客][bigtable_-CSDN]

分布式数据库底层依托于分部署文件系统进行存储，分布式数据库更像在分布式文件系统上做了一层封装。就像BigTable底层依托于GFS一样，HBase底层依托于HDFS，专栏有专门介绍HDFS的文章：

[【大数据】分布式文件系统HDFS-CSDN博客][HDFS-CSDN]

### **1.2.数据模型** ###

HBase中一个具体的数据由行键、列族、列限定符、时间戳组成。数据类型是不定的，统一存储为Bytes数组。

![472892b337fd4f348cb21b9fd4868c76.png][]

之所以有时间戳是因为HBASE底层是用的HDFS来做存储的，HDFS只支持追加写，所以HBASE为了实现删除效果只能用时间戳来区分哪个数据是最新的。

列族是个很核心的概念，底层的物理存储以列族为单位进行存储，支持动态扩展，一个列族其实就是HDFS中的一个文件，同一列族下的数据一定是被存到HDFS中的一个文件中的。

![99bbdf5319574e8d9c8ad1e6cafcb576.png][]

### 1.3.列式存储的优势 ###

**大数据技术中为什么采用列式存储：**

HDBASE采用的这种存储模式叫列式存储，传统的关系型数据库采用的行式存储，大数据中普遍都采用列式存储。大数据中之所以采用列式存储是因为列式存储往往更有利于分析，当需要做指标统计的时候往往只需要访问一个列即可，而且列族在物理磁盘上是连续存储的，速度会很快。行式存储要进行指标统计的时候要访问很多无用的列，而且数据在物理磁盘上也不是连续存储的，性能不会很好。

比如数据表是这样：

![1772cfc4966643d8a9d11fde860f9f0b.png][]

行式和列式的区别会是：

![125ee46610c641679700e7978bb6332c.png][]

## 2.实现原理 ##

### 2.1.region ###

HBase最核心的概念！！！

hbase的架构直接参照bigtable即可，只是改了个名字。bigtable的核心是tablet，HBase的核心是region，存储region的服务器叫region server，对应bigtable中的tablet server。一个表会按照行键的字典序列进行排布，然后被分成多个region：

![47506f0f36584ff4bc3614eb6c69110b.png][]

**如何找到要的region？**

HBASE参照BigTable的三层结构也维护了一个类树状结构用来快速查找到要的region：

叶子节点是region、meta表负责维护树形的层级结构，一个meta对应多个region，root只有一个，对应多个meta。

![d384a0486c644943b2ec48742f2469ee.png][]

<table> 
 <thead> 
  <tr> 
   <th>层次</th> 
   <th>名称</th> 
   <th>作用</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>第一层</td> 
   <td>root表</td> 
   <td>记录了META表的位置信息</td> 
  </tr> 
  <tr> 
   <td>第二层</td> 
   <td>meta表</td> 
   <td>记录了region表的位置信息，meta表相当于一个集合，将region分块的管理，用来维护了层级结构</td> 
  </tr> 
  <tr> 
   <td>第三层</td> 
   <td>用户表</td> 
   <td>用来记录用户数据</td> 
  </tr> 
 </tbody> 
</table>

### 2.2.LSM树 ###

LSM树是一种专门针对海量数据读写而升的数据结构，前文中作者聊bigtable的时候单独写了一篇文章对LSM树进行过讲解，可移步：

[【大数据】LSM树，专为海量数据读写而生的数据结构-CSDN博客][LSM_-CSDN]

同样HBASE中也用了LSM树，也有类似于memtable和sstable的东西：

memstore->memtable

storefile->sstable

这里HBase和bigtable唯一有区别的就是bigtable的一个tablet里只会有一条线的memtable和sstable，而HBase由于支持多个列族所以会有多条线的memtable和sstable。

![564f5e98f7224d239b9f322205e5f91f.png][]

### **2.3.完整读写过程** ###

写过程：

![img][]

*  客户端发起写请求 客户端应用通过HBase客户端API（如Java API）向HBase提交一个PUT请求，包含待写入的数据（包括RowKey、列族、列限定符、值以及可选的时间戳等）。
 *  定位目标Region 访问ZooKeeper：客户端首先访问ZooKeeper集群，先查询hbase:root表以获取hbase:meta表所在的Region Server位置。 缓存元数据：客户端将获取到的元数据信息（如hbase:meta表或目标Region的位置）缓存在本地Client Cache中，以减少后续操作对ZooKeeper的依赖和网络开销。
 *  查找目标Region 查询元数据表：客户端使用缓存的信息连接到hbase:meta表所在的Region Server，根据待写入数据的RowKey在hbase:meta表中查找目标Region的位置。这个过程可能涉及Region的三层定位（Namespace、表名、RowKey区间），确保找到正确的Region负责处理该RowKey的数据。 更新缓存：客户端将查询到的目标Region的位置信息（包括Region Server地址和Region边界）更新到本地缓存中。
 *  与目标Region Server交互 发送写请求：客户端根据缓存中的信息，向目标Region Server发送实际的PUT请求。
 *  Region Server内部处理 追加写入HLog（WAL，Write Ahead og）：Region Server接收到PUT请求后，首先将写操作作为一条日志记录追加到HLog。HLog是一种预写式日志，用于保证在发生故障时能够恢复未持久化到磁盘的数据。 随机写入MemStore：接着，Region Server将数据随机写入对应Region的MemStore。MemStore是内存中的数据结构，用于临时存储待写入HFile（HBase的数据文件）的修改。
 *  更新BlockCache 读写加速：写入完成后，新写入的数据会被添加到Region Server的BlockCache中。BlockCache是一种基于LRU（最近最少使用）策略的缓存，用于加速后续对相同数据块的读取。

读过程：

![img][img 1]

*  定位目标Region 访问ZooKeeper：客户端首先访问ZooKeeper集群，查询HBase的元数据表（hbase:meta）的位置信息。这里同样可能存在旧版流程（先查询hbase:root表）和新版流程（直接查询hbase:meta表）的区别。 缓存元数据：客户端将获取到的元数据信息（如hbase:meta表或目标Region的位置）缓存在本地Client Cache中，以减少后续操作对ZooKeeper的依赖和网络开销。
 *  查找目标Region 查询元数据表：客户端使用缓存的信息连接到hbase:meta表所在的Region Server，根据待读取数据的RowKey在hbase:meta表中查找目标Region的位置。这一步确保客户端知道应该向哪个Region Server的哪个Region发送读请求。 更新缓存：客户端将查询到的目标Region的位置信息更新到本地缓存中。
 *  与目标Region Server交互 发送读请求：客户端根据缓存中的信息，向目标Region Server发送实际的GET请求。
 *  Region Server内部处理 查询BlockCache：Region Server首先在本地BlockCache中查找是否有请求的数据。BlockCache是一种基于LRU（最近最少使用）策略的缓存，存储最近访问过的HFile数据块。如果数据在BlockCache中命中，则直接返回给客户端，避免了磁盘I/O。 查询MemStore：如果BlockCache中未找到数据，Region Server接着在对应Region的MemStore中查找。MemStore存储了尚未刷写到HFile的最新数据，如果请求的数据在这里存在且是最新的版本，则直接返回给客户端。 查询HFile：如果BlockCache和MemStore均未命中，Region Server将从磁盘上的HFile中读取数据。HFile是按RowKey排序的持久化存储文件，通过二分查找等高效算法快速定位数据。读取到的数据将返回给客户端，并可能被加入到BlockCache中以供后续读取加速。 合并版本与过滤：对于同一RowKey的多个版本（依据时间戳区分），Region Server按照请求的时间戳范围或其他过滤条件（如列族、列限定符等）筛选并合并结果集，只返回满足条件的数据版本。
 *  客户端接收响应 处理响应：客户端接收到Region Server返回的数据后，解析并呈现给应用程序。如果请求涉及多个列族或多行数据，客户端可能需要合并来自不同Region Server的响应。

**数据flush与compaction：**

MemStore flush：当MemStore达到一定大小阈值时，Region Server将其内容刷写到硬盘上的HFile中，并清空MemStore。同时，对应的HLog记录可以被安全地截断（truncated），因为其数据已持久化。 Compaction：随着时间推移，针对同一Region可能会产生多个HFile。HBase后台会定期执行Compaction操作，合并小文件、删除过期版本的数据，并可能进行压缩，以优化读性能和存储空间利用率。

合并没有什么好说的，和bigtable一样，值得注意的是一直合并下去，单体过大后又会分成小块来存储，这个分块存储的过程就会造成一个大region1分成一个个小region。

![3ea84cf1c3af4ff5b06f41aba258db95.png][]

### 2.4.master的作用 ###

master主要就是负责整个集群的管理：

*  通过master来对表进行增删改查
 *  负责region的分布
 *  负责不同region服务器的负载均衡，将负载较重的region服务器上的region重新分布到其它负载轻的region服务器上去。
 *  region服务器故障失效后，借助master来将上面的region重新分配给其它服务器。

[a714d88af64f4116b87eb994e20fac82.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/4293bd5769ce435487273f2f717ef38b.png
[https_blog.csdn.net_joker_zjn_category_12631789.html_spm_1001.2014.3001.5482]: https://blog.csdn.net/joker_zjn/category_12631789.html?spm=1001.2014.3001.5482
[bigtable_-CSDN]: https://bugman.blog.csdn.net/article/details/137988452?spm=1001.2014.3001.5502
[HDFS-CSDN]: https://blog.csdn.net/Joker_ZJN/article/details/137846603?spm=1001.2014.3001.5501
[472892b337fd4f348cb21b9fd4868c76.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/473e232673fc48bd9b9ca08d235b2450.png
[99bbdf5319574e8d9c8ad1e6cafcb576.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/1c75194ae15d45b7a7a77046ccbb338d.png
[1772cfc4966643d8a9d11fde860f9f0b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/5083e13229ab4508a93a4166a74cacc4.png
[125ee46610c641679700e7978bb6332c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/f34efafc4eaf44efb98902b992dccb2d.png
[47506f0f36584ff4bc3614eb6c69110b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/47798a77bbbb4dc08454bf1a55ebe613.png
[d384a0486c644943b2ec48742f2469ee.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/941a90dedb7a42f0a84af1ab44bcc4c8.png
[LSM_-CSDN]: https://bugman.blog.csdn.net/article/details/138141480?spm=1001.2014.3001.5502
[564f5e98f7224d239b9f322205e5f91f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/65ceaf0856904499b50d967a8ed4ce4d.png
[img]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/3a3317618724465db9ff8b606030960d.png
[img 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/60f2a95e3024460db0ddd85f5b8d58e4.png
[3ea84cf1c3af4ff5b06f41aba258db95.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/02/b581d25c89ca4bc2a3b095674e70d33f.png