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

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介: 【大数据】分布式数据库HBase

1.概述

1.1.前言

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

当前的分布式数据库其实都是参考的Google的BigTable,所以学习分布式数据库之前先学一下BigTable会一通百通。

分布式数据库底层依托于分部署文件系统进行存储,分布式数据库更像在分布式文件系统上做了一层封装。就像BigTable底层依托于GFS一样,HBase底层依托于HDFS

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。

2.4.master的作用

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

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


相关实践学习
lindorm多模间数据无缝流转
展现了Lindorm多模融合能力——用kafka API写入,无缝流转在各引擎内进行数据存储和计算的实验。
云数据库HBase版使用教程
  相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情: https://cn.aliyun.com/product/hbase   ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
3天前
|
数据库
数据库中的分布式锁有哪些缺点
数据库中的分布式锁有哪些缺点
|
6天前
|
分布式计算 大数据 关系型数据库
MaxCompute产品使用合集之如何实现类似mysql实例中的数据库功能
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
6天前
|
SQL 关系型数据库 MySQL
乐观锁在分布式数据库中与事务隔离级别结合使用
乐观锁在分布式数据库中与事务隔离级别结合使用
|
6天前
|
数据采集 分布式计算 大数据
MaxCompute产品使用合集之数据集成中进行数据抽取时,是否可以定义使用和源数据库一样的字符集进行抽取
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
9天前
|
存储 NoSQL 大数据
大数据存储:HBase与Cassandra的对比
【7月更文挑战第16天】HBase和Cassandra作为两种流行的分布式NoSQL数据库,在数据模型、一致性模型、数据分布、查询语言和性能等方面各有千秋。HBase适用于需要强一致性和与Hadoop生态系统集成的场景,如大规模数据处理和分析。而Cassandra则更适合需要高可用性和灵活查询能力的场景,如分布式计算、云计算和大数据应用等。在实际应用中,选择哪种数据库取决于具体的需求和场景。希望本文的对比分析能够帮助读者更好地理解这两种数据库,并做出明智的选择。
|
16天前
|
存储 Java 分布式数据库
使用Spring Boot和HBase实现大数据存储
使用Spring Boot和HBase实现大数据存储
|
22天前
|
关系型数据库 分布式数据库 数据库
PolarDB,阿里云的开源分布式数据库,与微服务相结合,提供灵活扩展和高效管理解决方案。
【7月更文挑战第3天】PolarDB,阿里云的开源分布式数据库,与微服务相结合,提供灵活扩展和高效管理解决方案。通过数据分片和水平扩展支持微服务弹性,保证高可用性,且兼容MySQL协议,简化集成。示例展示了如何使用Spring Boot配置PolarDB,实现服务动态扩展。PolarDB缓解了微服务数据库挑战,加速了开发部署,为云原生应用奠定基础。
163 3
|
22天前
|
存储 关系型数据库 分布式数据库
PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题
【7月更文挑战第3天】PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题。此架构让存储层专注数据可靠性,计算层专注处理SQL,提升性能并降低运维复杂度。通过RDMA加速通信,多副本确保高可用性。资源可独立扩展,便于成本控制。动态添加计算节点以应对流量高峰,展示了其灵活性。PolarDB的开源促进了数据库技术的持续创新和发展。
237 2
|
22天前
|
关系型数据库 分布式数据库 PolarDB
**PolarDB开源指南:构建分布式数据库集群**踏上PolarDB开源之旅,了解如何从零开始搭建分布式集群
【7月更文挑战第3天】**PolarDB开源指南:构建分布式数据库集群**踏上PolarDB开源之旅,了解如何从零开始搭建分布式集群。采用存储计算分离架构,适用于大规模OLTP和OLAP。先准备硬件和软件环境,包括Linux、Docker和Git。然后,克隆源码,构建Docker镜像,部署控制节点和计算节点。使用PDCli验证集群状态,开始探索PolarDB的高性能与高可用性。在实践中深化学习,贡献于数据库技术创新。记得在安全环境下测试。
135 1
|
3天前
|
消息中间件 缓存 架构师
一个合格的架构师应该怎样处理数据库、调度系统、消息队列、分布式缓存等软件
一个合格的架构师应该怎样处理数据库、调度系统、消息队列、分布式缓存等软件