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

最新推荐文章于 2024-05-06 11:52:17 发布

_BugMan

最新推荐文章于 2024-05-06 11:52:17 发布

阅读量1.8k

点赞数 70

分类专栏：大数据文章标签：大数据分布式数据库 hbase bigdata sstable

本文链接：https://blog.csdn.net/Joker_ZJN/article/details/138218730

版权

大数据专栏收录该内容

7 篇文章 1 订阅

订阅专栏

1.概述

1.1.前言

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

https://blog.csdn.net/joker_zjn/category_12631789.html?spm=1001.2014.3001.5482

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

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

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

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

1.2.数据模型

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

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

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

1.3.列式存储的优势

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

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

比如数据表是这样：

行式和列式的区别会是：

2.实现原理

2.1.region

HBase最核心的概念！！！

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

如何找到要的region？

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

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

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

2.2.LSM树

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

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

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

memstore->memtable

storefile->sstable

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

2.3.完整读写过程

写过程：

客户端发起写请求客户端应用通过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（最近最少使用）策略的缓存，用于加速后续对相同数据块的读取。

读过程：

定位目标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。