深入理解HBase的原理及系统架构

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
注册配置 MSE Nacos/ZooKeeper,182元/月
云原生网关 MSE Higress,422元/月
简介: 深入理解HBase的原理及系统架构

HBase的构成



物理上来说,HBase是由三种类型的服务器以主从模式构成的。这三种服务器分别是:Region serverHBase HMasterZooKeeper

其中Region server负责数据的读写服务。用户通过沟通Region server来实现对数据的访问。

HBase HMaster负责Region的分配及数据库的创建和删除等操作。

ZooKeeper作为HDFS的一部分,负责维护集群的状态(某台服务器是否在线,服务器之间数据的同步操作及master的选举等)。

另外,Hadoop DataNode负责存储所有Region Server所管理的数据。HBase中的所有数据都是以HDFS文件的形式存储的。出于使Region server所管理的数据更加本地化的考虑,Region server是根据DataNode分布的。HBase的数据在写入的时候都存储在本地。但当某一个region被移除或被重新分配的时候,就可能产生数据不在本地的情况。这种情况只有在所谓的compaction之后才能解决。

NameNode负责维护构成文件的所有物理数据块的元信息(metadata)。

HBase结构如下图所示:

1ddef7b5cd4ccd4c5590320742af56f9.jpg

Regions


HBase中的表是根据row key的值水平分割成所谓的region的。一个region包含表中所有row key位于region的起始键值和结束键值之间的行。集群中负责管理Region的结点叫做Region server。Region server负责数据的读写。每一个Region server大约可以管理1000个region。Region的结构如下图所示:

6c846d775a0de1ce6d028ddb79179670.jpg

HBase的HMaster


HMaster负责region的分配,数据库的创建和删除操作。

具体来说,HMaster的职责包括:

  • 调控Region server的工作
  • 在集群启动的时候分配region,根据恢复服务或者负载均衡的需要重新分配region。
  • 监控集群中的Region server的工作状态。(通过监听zookeeper对于ephemeral node状态的通知)。
  • 管理数据库
  • 提供创建,删除或者更新表格的接口。

HMaster的工作如下图所示:

e065a84148e2d679fe75c3657d166d00.jpg

ZooKeeper


HBase利用ZooKeeper维护集群中服务器的状态并协调分布式系统的工作。ZooKeeper维护服务器是否存活,是否可访问的状态并提供服务器故障/宕机的通知。ZooKeeper同时还使用一致性算法来保证服务器之间的同步。同时也负责Master选举的工作。需要注意的是要保证良好的一致性及顺利的Master选举,集群中的服务器数目必须是奇数。例如三台或五台。

ZooKeeper的工作如下图所示:

0cf6f6dabbd17f737cd499186f2363ea.jpg

HBase各组成部分之间的合作


ZooKeeper用来协调分布式系统的成员之间共享的状态信息。Region Server及HMaster也与ZooKeeper连接。ZooKeeper通过心跳信息为活跃的连接维持相应的ephemeral node。如下图所示:

d2883bee475111f853cd949dded21024.jpg

每一个Region server都在ZooKeeper中创建相应的ephemeral node。HMaster通过监控这些ephemeral node的状态来发现正常工作的或发生故障下线的Region server。HMaster之间通过互相竞争创建ephemeral node进行Master选举。ZooKeeper会选出区中第一个创建成功的作为唯一一个活跃的HMaster。活跃的HMaster向ZooKeeper发送心跳信息来表明自己在线的状态。不活跃的HMaster则监听活跃HMaster的状态,并在活跃HMaster发生故障下线之后重新选举,从而实现了HBase的高可用性。

如果Region server或者HMaster不能成功向ZooKeeper发送心跳信息,则其与ZooKeeper的连接超时之后与之相应的ephemeral node就会被删除。监听ZooKeeper状态的其他节点就会得到相应node不存在的信息,从而进行相应的处理。活跃的HMaster监听Region Server的信息,并在其下线后重新分配Region server来恢复相应的服务。不活跃的HMaster监听活跃HMaster的信息,并在起下线后重新选出活跃的HMaster进行服务。

HBase的第一次读写


HBase中有一个特殊的起目录作用的表格,称为META table。META table中保存集群region的地址信息。ZooKeeper中会保存META table的位置。

当用户第一次想HBase中进行读或写操作时,以下步骤将被执行:

  1. 客户从ZooKeeper中得到保存META table的Region server的信息。
  2. 客户向该Region server查询负责管理自己想要访问的row key的所在的region的Region server的地址。客户会缓存这一信息以及META table所在位置的信息。
  3. 客户与负责其row所在region的Region Server通信,实现对该行的读写操作。

在未来的读写操作中,客户会根据缓存寻找相应的Region server地址。除非该Region server不再可达。这时客户会重新访问META table并更新缓存。这一过程如下图所示:

3074b6cfcc1fca0180c3a705fdae7070.jpg

HBase的META table


  • META table中保存了HBase中所有region的信息。
  • META table的格式类似于B tree。
  • META table的结构如下:
  • 键:region的起始键,region id。
  • 值:Region server

如下图所示:

92e0d3c8b826f430b6a37fc53afa63c1.jpg

Region Server的组成


运行在HDFS DataNode上的Region server包含如下几个部分:

  • WAL:既Write Ahead Log。WAL是HDFS分布式文件系统中的一个文件。WAL用来存储尚未写入永久性存储区中的新数据。WAL也用来在服务器发生故障时进行数据恢复。
  • Block Cache:Block cache是读缓存。Block cache将经常被读的数据存储在内存中来提高读取数据的效率。当Block cache的空间被占满后,其中被读取频率最低的数据将会被杀出。
  • MemStore:MemStore是写缓存。其中存储了从WAL中写入但尚未写入硬盘的数据。MemStore中的数据在写入硬盘之前会先进行排序操作。每一个region中的每一个column family对应一个MemStore。
  • Hfiles:Hfiles存在于硬盘上,根据排序号的键存储数据行。

Region server的结构如下图所示:

205c55ee213071fc7b4eec9cdb262f89.jpg

HBase的写操作步骤


步骤一

当HBase的用户发出一个PUT请求时(也就是HBase的写请求),HBase进行处理的第一步是将数据写入HBase的write-ahead log(WAL)中。

  • WAL文件是顺序写入的,也就是所有新添加的数据都被加入WAL文件的末尾。WAL文件存在硬盘上。
  • 当server出现问题之后,WAL可以被用来恢复尚未写入HBase中的数据(因为WAL是保存在硬盘上的)。

如下图所示:

0cc42af6b48be809ba1fb534008edc43.jpg

步骤二

当数据被成功写入WAL后,HBase将数据存入MemStore。这时HBase就会通知用户PUT操作已经成功了。

过程如下图所示:

8daf59f013079b8998886c8693aafb19.jpg

HBase的MemStore


Memstore存在于内存中,其中存储的是按键排好序的待写入硬盘的数据。数据也是按键排好序写入HFile中的。每一个Region中的每一个Column family对应一个Memstore文件。因此对数据的更新也是对应于每一个Column family。

如下图所示:

dc7884f2e8c191520290d50ee9dd96bc.jpg

HBase Region Flush


当MemStore中积累了足够多的数据之后,整个Memcache中的数据会被一次性写入到HDFS里的一个新的HFile中。因此HDFS中一个Column family可能对应多个HFile。这个HFile中包含了相应的cell,或者说键值的实例。这些文件随着MemStore中积累的对数据的操作被flush到硬盘上而创建。

需要注意的是,MemStore存储在内存中,这也是为什么HBase中Column family的数目有限制的原因。每一个Column family对应一个MemStore,当MemStore存满之后,里面所积累的数据就会一次性flush到硬盘上。同时,为了使HDFS能够知道当前哪些数据已经被存储了,MemStore中还保存最后一次写操作的序号。

每个HFile中最大的序号作为meta field存储在其中,这个序号标明了之前的数据向硬盘存储的终止点和接下来继续存储的开始点。当一个region启动的时候,它会读取每一个HFile中的序号来得知当前region中最新的操作序号是什么(最大的序号)。

如下图所示:

8f67674c9cc09161ad107cb2bb398017.jpg

HFile


HBase中的键值数据对存储在HFile中。上面已经说过,当MemStore中积累足够多的数据的时候就会将其中的数据整个写入到HDFS中的一个新的HFile中。因为MemStore中的数据已经按照键排好序,所以这是一个顺序写的过程。由于顺序写操作避免了磁盘大量寻址的过程,所以这一操作非常高效。

如下图所示:

cfbc3c753524a893aa3f240aaf940162.jpg

HFile的结构


HFile中包含了一个多层索引系统。这个多层索引是的HBase可以在不读取整个文件的情况下查找数据。这一多层索引类似于一个B+树。

  • 键值对根据键大小升序排列。
  • 索引指向64KB大小的数据块。
  • 每一个数据块还有其相应的叶索引(leaf-index)。
  • 每一个数据块的最后一个键作为中间索引(intermediate index)。
  • 根索引(root index)指向中间索引。

文件结尾指向meta block。因为meta block是在数据写入硬盘操作的结尾写入该文件中的。文件的结尾同时还包含一些别的信息。比如bloom filter及时间信息。Bloom filter可以帮助HBase加速数据查询的速度。因为HBase可以利用Bloom filter跳过不包含当前查询的键的文件。时间信息则可以帮助HBase在查询时跳过读操作所期望的时间区域之外的文件。

如下图所示:

2bb230a8606bc50aca20e4f6338ac1da.jpg

HFile的索引

HFile的索引在HFile被打开时会被读取到内存中。这样就可以保证数据检索只需一次硬盘查询操作。

如下图所示:

4ac02dbeb4aa80eb7961a7537adbcef0.jpg

HBase的读合并(Read Merge)以及读放大(Read amplification)


通过上面的论述,我们已经知道了HBase中对应于某一行数据的cell可能位于多个不同的文件或存储介质中。比如已经存入硬盘的行位于硬盘上的HFile中,新加入或更新的数据位于内存中的MemStore中,最近读取过的数据则位于内存中的Block cache中。所以当我们读取某一行的时候,为了返回相应的行数据,HBase需要根据Block cache,MemStore以及硬盘上的HFile中的数据进行所谓的读合并操作。

  1. HBase会首先从Block cache(HBase的读缓存)中寻找所需的数据。
  2. 接下来,HBase会从MemStore中寻找数据。因为作为HBase的写缓存,MemStore中包含了最新版本的数据。
  3. 如果HBase从Block cache和MemStore中没有找到行所对应的cell所有的数据,系统会接着根据索引和bloom filter从相应的HFile中读取目标行的cell的数据。

如下图所示:

ba64dd40c2a3bce6af4e052b35e5efa6.jpg

这里一个需要注意的地方是所谓的读放大效应(Read amplification)。根据前文所说,一个MemStore对应的数据可能存储于多个不同的HFile中(由于多次的flush),因此在进行读操作的时候,HBase可能需要读取多个HFile来获取想要的数据。这会影响HBase的性能表现。

如下图所示:

22fd8e6812a1b45b44cb2d3d02f84b35.jpg

HBase的Compaction


Minor Compaction

HBase会自动选取一些较小的HFile进行合并,并将结果写入几个较大的HFile中。这一过程称为Minor compaction。Minor compaction通过Merge sort的形式将较小的文件合并为较大的文件,从而减少了存储的HFile的数量,提升HBase的性能。

这一过程如下图所示:

0b8dc31308ab6a01466f6ae5e5bcc278.jpg

Major Compaction

所谓Major Compaction指的是HBase将对应于某一个Column family的所有HFile重新整理并合并为一个HFile,并在这一过程中删除已经删除或过期的cell,更新现有cell的值。这一操作大大提升读的效率。但是因为Major compaction需要重新整理所有的HFile并写入一个HFile,这一过程包含大量的硬盘I/O操作以及网络数据通信。这一过程也称为写放大(Write amplification)。在Major compaction进行的过程中,当前Region基本是处于不可访问的状态。

Major compaction可以配置在规定的时间自动运行。为避免影响业务,Major compaction一般安排在夜间或周末进行。

需要注意的一点事,Major compaction会将当前Region所服务的所有远程数据下载到本地Region server上。这些远程数据可能由于服务器故障或者负载均衡等原因而存储在于远端服务器上。

这一过程如下图所示:

30db26f908c39bfba14a8cff63249094.jpg

Region的分割(Region split)


首先我们快速复习一下Region:

  • HBase中的表格可以根据行键水平分割为一个或几个region。每个region中包含了一段处于某一起始键值和终止键值之间的连续的行键。
  • 每一个region的默认大小为1GB。
  • 相应的Region server负责向客户提供访问某一region中的数据的服务。
  • 每一个Region server能够管理大约1000个region(这些region可能来自同一个表格,也可能来自不同的表格)。

如下图所示:

0825568984cbf1130a082d1a3058bba7.jpg

每一个表格最初都对应于一个region。随着region中数据量的增加,region会被分割成两个子region。每一个子region中存储原来一半的数据。同时Region server会通知HMaster这一分割。出于负载均衡的原因,HMaster可能会将新产生的region分配给其他的Region server管理(这也就导致了Region server服务远端数据的情况的产生)。

如下图所示:

295180ed15689ca05c7812688b6ab737.jpg

读操作的负载均衡(Read Load Balancing)


Region的分割最初是在Region server本地发生的。但是出于负载均衡的原因,HMaster可能会将新产生的region分配给其他的Region server进行管理。这也就导致了Region server管理存储在远端服务器上的region情况的产生。这一情况会持续至下一次Major compaction之前。如上文所示,Major compaction会将任何不在本地的数据下载至本地。

也就是说,HBase中的数据在写入时总是存储在本地的。但是随着region的重新分配(由于负载均衡或数据恢复),数据相对于Region server不再一定是本地的。这种情况会在Major compaction后得到解决。

如下图所示:

bef61866e4819beb8519749f5713b029.jpg

HDFS的数据备份(Data Replication)


HDFS中所有的数据读写操作都是针对主节点进行的。HDFS会自动备份WAL和HFile。HBase以来HDFS来提供可靠的安全的数据存储。当数据被写入HDFS本地时,另外两份备份数据会分别存储在另外两台服务器上。

如下图所示:

b89e1ba6b80e19f084f3effd77f45514.jpg

HBase的异常恢复(Crash Recovery)


WAL文件和HFile都存储于硬盘上且存在备份,因此恢复它们是非常容易的。那么HBase如何恢复位于内存中的MemStore呢?

80e92a1ed50232ae7bf638023fc7953f.jpg

当Region server宕机的时候,其所管理的region在这一故障被发现并修复之前是不可访问的。ZooKeeper负责根据服务器的心跳信息来监控服务器的工作状态。当某一服务器下线之后,ZooKeeper会发送该服务器下线的通知。HMaster收到这一通知之后会进行恢复操作。

HMaster会首先将宕机的Region server所管理的region分配给其他仍在工作的活跃的Region server。然后HMaster会将该服务器的WAL分割并分别分配给相应的新分配的Region server进行存储。新的Region server会读取并顺序执行WAL中的数据操作,从而重新创建相应的MemStore。

如下图所示:1ed485e2ec74b9a95a0534d944bf97a1.jpg

数据恢复(Data Recovery)


WAL文件之中存储了一系列数据操作。每一个操作对应WAL中的一行。新的操作会顺序写在WAL文件的末尾。

那么当MemStore中存储的数据因为某种原因丢失之后应该如何恢复呢?HBase以来WAL对其进行恢复。相应的Region server会顺序读取WAL并执行其中的操作。这些数据被存入内存中当前的MemStore并排序。最终当MemStore存满之后,这些数据被flush到硬盘上。

如下图所示:

ca25e4f27c94926243166fb40ff8fb39.jpg

Apache HBase的优缺点


优点

  • 强一致性模型
  • 当一个写操作得到确认时,所有的用户都将读到同一个值。
  • 可靠的自动扩展
  • 当region中的数据太多时会自动分割。
  • 使用HDFS分布存储并备份数据。
  • 内置的恢复功能
  • 使用WAL进行数据恢复。
  • 与Hadoop集成良好
  • MapReduce在HBase上非常直观。

缺点

  • WAL回复较慢。
  • 异常恢复复杂且低效。
  • 需要进行占用大量资源和大量I/O操作的Major compaction。


目录
相关文章
|
3月前
|
存储 监控 算法
园区导航系统技术架构实现与原理解构
本文聚焦园区导航场景中室内外定位精度不足、车辆调度路径规划低效、数据孤岛难以支撑决策等技术痛点,从架构设计到技术原理,对该系统从定位到数据中台进行技术拆解。
116 0
园区导航系统技术架构实现与原理解构
|
4月前
|
存储 消息中间件 canal
zk基础—2.架构原理和使用场景
ZooKeeper(ZK)是一个分布式协调服务,广泛应用于分布式系统中。它提供了分布式锁、元数据管理、Master选举及分布式协调等功能,适用于如Kafka、HDFS、Canal等开源分布式系统。ZK集群采用主从架构,具有顺序一致性、高性能、高可用和高并发等特点。其核心机制包括ZAB协议(保证数据一致性)、Watcher监听回调机制(实现通知功能)、以及基于临时顺序节点的分布式锁实现。ZK适合小规模集群部署,主要用于读多写少的场景。
|
5月前
|
存储 人工智能 自然语言处理
为什么混合专家模型(MoE)如此高效:从架构原理到技术实现全解析
本文深入探讨了混合专家(MoE)架构在大型语言模型中的应用与技术原理。MoE通过稀疏激活机制,在保持模型高效性的同时实现参数规模的大幅扩展,已成为LLM发展的关键趋势。文章分析了MoE的核心组件,包括专家网络与路由机制,并对比了密集与稀疏MoE的特点。同时,详细介绍了Mixtral、Grok、DBRX和DeepSeek等代表性模型的技术特点及创新。MoE不仅解决了传统模型扩展成本高昂的问题,还展现出专业化与适应性强的优势,未来有望推动AI工具更广泛的应用。
1938 4
为什么混合专家模型(MoE)如此高效:从架构原理到技术实现全解析
|
5月前
|
存储 缓存 分布式数据库
【赵渝强老师】HBase的体系架构
HBase是一种基于BigTable思想的列式存储NoSQL数据库,适合数据分析与处理。其主从架构包含HBase HMaster、Region Server和ZooKeeper。HMaster负责Region分配及表管理;Region Server执行数据读写操作,并包含WAL预写日志、Block Cache读缓存和MemStore写缓存;ZooKeeper维护集群状态并协调分布式系统工作。通过视频讲解与架构图示,详细解析各组件功能与协作机制。
243 11
|
10月前
|
存储 SQL 关系型数据库
MySQL进阶突击系列(03) MySQL架构原理solo九魂17环连问 | 给大厂面试官的一封信
本文介绍了MySQL架构原理、存储引擎和索引的相关知识点,涵盖查询和更新SQL的执行过程、MySQL各组件的作用、存储引擎的类型及特性、索引的建立和使用原则,以及二叉树、平衡二叉树和B树的区别。通过这些内容,帮助读者深入了解MySQL的工作机制,提高数据库管理和优化能力。
|
6月前
|
消息中间件 存储 设计模式
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
1638 21
RocketMQ原理—5.高可用+高并发+高性能架构
|
5月前
|
机器学习/深度学习 算法 测试技术
图神经网络在信息检索重排序中的应用:原理、架构与Python代码解析
本文探讨了基于图的重排序方法在信息检索领域的应用与前景。传统两阶段检索架构中,初始检索速度快但结果可能含噪声,重排序阶段通过强大语言模型提升精度,但仍面临复杂需求挑战
141 0
图神经网络在信息检索重排序中的应用:原理、架构与Python代码解析
|
5月前
|
Java 开发者 Spring
Spring框架 - 深度揭秘Spring框架的基础架构与工作原理
所以,当你进入这个Spring的世界,看似一片混乱,但细看之下,你会发现这里有个牢固的结构支撑,一切皆有可能。不论你要建设的是一座宏大的城堡,还是个小巧的花园,只要你的工具箱里有Spring,你就能轻松搞定。
212 9
|
6月前
|
人工智能 自然语言处理 安全
基于LlamaIndex实现CodeAct Agent:代码执行工作流的技术架构与原理
CodeAct是一种先进的AI辅助系统范式,深度融合自然语言处理与代码执行能力。通过自定义代码执行代理,开发者可精准控制代码生成、执行及管理流程。本文基于LlamaIndex框架构建CodeAct Agent,解析其技术架构,包括代码执行环境、工作流定义系统、提示工程机制和状态管理系统。同时探讨安全性考量及应用场景,如软件开发、数据科学和教育领域。未来发展方向涵盖更精细的代码生成、多语言支持及更强的安全隔离机制,推动AI辅助编程边界拓展。
282 3
基于LlamaIndex实现CodeAct Agent:代码执行工作流的技术架构与原理

热门文章

最新文章