一、引言为什么需要理解HBase架构在前两篇文章中我们了解了HBase的基本概念和数据模型。但要想真正掌握HBase理解其架构原理是必不可少的。HBase的架构设计决定了它的性能特征、可用性保证以及运维方式。HBase采用经典的Master-Slave架构包含四个核心组件HMaster集群的管理者负责元数据管理和负载均衡RegionServer数据的实际管理者负责读写请求处理Zookeeper分布式协调服务保障集群高可用HDFS底层存储系统提供数据持久化本文将从整体架构入手逐一剖析每个组件的职责然后详细讲解读写流程的全链路。二、HBase整体架构概览2.1 架构全景图HBase集群由多个节点组成每个节点承担不同的角色上图展示了HBase的整体架构Client客户端发起读写请求HMaster管理节点负责表和Region的元数据管理RegionServer数据节点负责实际的数据读写Zookeeper协调节点维护集群状态和元数据入口HDFS存储层所有数据最终持久化到HDFS2.2 架构层次关系三、HMaster集群的管理者3.1 HMaster的职责HMaster是HBase集群的管理节点负责整个集群的元数据管理和协调工作。其实现类为HMaster。职责1表级别操作HMaster负责所有与表相关的管理操作操作类型具体命令说明创建表create创建新表并分配初始Region删除表drop删除表及其所有数据修改表alter修改表结构如增加列族启用/禁用表enable/disable控制表的可用状态职责2RegionServer管理HMaster负责RegionServer的生命周期管理分配Region将Region分配给合适的RegionServer监控状态通过Zookeeper监控每个RegionServer的心跳负载均衡定期检查Region分布进行负载均衡调整故障转移RegionServer宕机时将其上的Region迁移到其他节点职责3Region管理Region分裂监控监控Region大小触发Split操作Region合并协调协调Major Compaction后的Region合并Region迁移根据负载情况迁移Region3.2 HMaster的高可用HBase支持配置Backup Master实现HMaster的高可用高可用机制多个HMaster节点同时启动通过Zookeeper竞争成为Active MasterZookeeper的临时节点机制保证只有一个Active MasterActive Master宕机时Standby Master自动接管所有RegionServer同时向Zookeeper注册新Master可以快速发现它们配置Backup Master# 在conf目录下创建backup-masters文件touchconf/backup-masters# 添加备份Master节点echohadoop103conf/backup-masters# 将配置同步到所有节点xsync conf/3.3 HMaster不是性能瓶颈重要认知HMaster不参与实际的数据读写只负责元数据管理。因此HMaster的负载很轻通常不会成为性能瓶颈即使HMaster短暂不可用已有的数据读写仍然可以继续因为客户端会缓存Region位置信息但HMaster宕机期间无法进行DDL操作创建/删除表等和Region的重新分配四、RegionServer数据的实际管理者4.1 RegionServer的职责RegionServer是HBase中最核心的组件负责实际的数据存储和读写处理。其实现类为HRegionServer。职责1数据操作RegionServer直接处理客户端的数据读写请求操作说明Get根据RowKey获取单条数据Put写入/更新数据Delete删除数据添加Delete标记Scan范围扫描数据职责2Region管理Region服务为分配给它的Region提供读写服务Region分裂当Region过大时执行Split操作Region合并参与Compaction过程职责3存储管理MemStore管理管理内存中的写缓存StoreFile管理管理磁盘中的HFile文件Flush操作将MemStore数据刷写到HDFSCompaction合并StoreFile清理过期数据4.2 RegionServer的内部结构上图展示了RegionServer的内部结构一个RegionServer管理多个Region每个Region包含多个Store每个列族一个Store每个Store包含一个MemStore内存缓存和多个StoreFile磁盘文件所有Region共享一个HLogWAL预写日志4.3 RegionServer的关键组件组件1WALWrite-Ahead Log预写日志WAL是HBase数据可靠性的核心保障WAL的作用数据恢复RegionServer宕机时通过WAL恢复未Flush的MemStore数据顺序写入WAL采用追加写入方式性能极高数据可靠性数据先写WAL再写MemStore确保不丢失WAL的存储WAL文件存储在HDFS上默认每个RegionServer一个WAL可以配置多个WALMultiWAL提升并发写入性能WAL文件会定期滚动Roll旧的WAL在数据Flush后可以删除组件2MemStore内存写缓存MemStore是HBase高性能写入的关键上图展示了WAL、MemStore和HFile的关系数据先写入WAL保证可靠性再写入MemStore保证写入性能MemStore中的数据排序后Flush生成HFileMemStore的核心特性特性说明排序存储数据在MemStore中按RowKey排序为生成有序HFile做准备内存结构使用ConcurrentSkipListMap实现支持高并发写入Flush机制达到一定阈值后批量刷写到HDFS生成HFile多版本支持同一Cell的多个版本在MemStore中同时存在MemStore的Flush时机将在第5篇详细讲解MemStore大小达到hbase.hregion.memstore.flush.size默认128MBRegionServer全局MemStore大小达到阈值距离上次Flush超过一定时间默认1小时WAL文件数量超过限制组件3BlockCache读缓存BlockCache是HBase提升读性能的关键组件上图展示了RegionServer中的缓存结构BlockCache缓存从HFile中读取的数据块BlockMemStore同时作为写缓存和未Flush数据的读缓存HFile磁盘中的持久化数据BlockCache的核心特性特性说明LRU淘汰采用最近最少使用策略自动淘汰不常用的数据块块大小默认64KB与HFile的块大小对应多级缓存支持on-heapJVM堆内和off-heap堆外缓存缓存命中率热点数据的缓存命中率通常可达90%以上读取数据时的缓存查找顺序先在BlockCache中查找内存最快再在MemStore中查找内存未Flush的数据最后在**StoreFileHFile**中查找磁盘最慢五、Zookeeper分布式协调的基石5.1 Zookeeper在HBase中的作用Zookeeper是HBase集群正常运行的基石承担以下关键职责职责1Master高可用┌─────────────┐ │ Zookeeper │ │ /hbase │ │ /master │ ← 临时节点只有一个Master能创建成功 └──────┬──────┘ │ ▼ ┌─────────────┐ ┌─────────────┐ │ HMaster-1 │ │ HMaster-2 │ │ (Active) │ │ (Standby) │ │ 持有锁 │ │ 监听节点 │ └─────────────┘ └─────────────┘多个HMaster竞争创建Zookeeper临时节点创建成功者成为Active Master其他Master监听该节点Active Master宕机时自动接管职责2RegionServer监控┌─────────────┐ │ Zookeeper │ │ /hbase │ │ /rs │ ← RegionServer注册目录 │ /rs1 │ ← 每个RegionServer创建一个临时节点 │ /rs2 │ │ /rs3 │ └─────────────┘每个RegionServer启动时向Zookeeper注册临时节点HMaster通过监听这些节点监控RegionServer状态RegionServer宕机时临时节点自动删除HMaster感知并处理故障转移职责3元数据入口┌─────────────┐ │ Zookeeper │ │ /hbase │ │ /meta-region-server │ ← hbase:meta表所在的RegionServer地址 └─────────────┘hbase:meta表存储了所有用户表的Region位置信息客户端通过Zookeeper找到hbase:meta表所在的RegionServer然后读取hbase:meta表获取目标数据的位置职责4集群配置管理存储集群的配置信息协调分布式操作如表禁用/启用状态5.2 Zookeeper的关键配置在hbase-site.xml中配置Zookeeperpropertynamehbase.zookeeper.quorum/namevaluehadoop102,hadoop103,hadoop104/valuedescriptionZookeeper集群地址/description/propertypropertynamehbase.zookeeper.property.clientPort/namevalue2181/valuedescriptionZookeeper客户端端口/description/propertypropertynamehbase.zookeeper.property.dataDir/namevalue/opt/module/zookeeper-3.4.10/zkData/valuedescriptionZookeeper数据目录/description/property5.3 Zookeeper与HBase的交互流程┌─────────┐ ┌─────────────┐ ┌─────────────┐ │ Client │────►│ Zookeeper │────►│ hbase:meta │ │ │ │ │ │ 所在位置 │ └────┬────┘ └─────────────┘ └─────────────┘ │ │ 获取meta表位置 ▼ ┌─────────────┐ ┌─────────────┐ │ RegionServer│────►│ hbase:meta │ │ (meta所在) │ │ 读取Region │ └────┬────────┘ │ 位置信息 │ │ └─────────────┘ │ 获取目标Region位置 ▼ ┌─────────────┐ ┌─────────────┐ │ RegionServer│────►│ 目标数据 │ │ (数据所在) │ │ 读写操作 │ └─────────────┘ └─────────────┘六、HDFS底层存储的保障6.1 HDFS在HBase中的作用HDFSHadoop Distributed File System为HBase提供最终的底层数据存储服务HDFS特性对HBase的意义分布式存储数据分散在多个DataNode支持海量存储副本机制默认3副本自动容错数据不丢失高吞吐顺序读写适合HBase的批量Flush和Compaction故障自动恢复DataNode宕机自动复制副本对HBase透明6.2 HBase在HDFS上的存储结构/hbase/ ├── .hbaseid ← HBase实例ID ├── .tmp ← 临时目录 ├── archive ← 归档目录已删除的HFile ├── corrupt ← 损坏文件目录 ├── data/ │ └── default/ ← 默认命名空间 │ └── student/ ← 表目录 │ └── region-hash/ ← Region目录 │ ├── info/ ← 列族目录 │ │ └── hfile1 ← HFile数据文件 │ └── personal_info/ │ └── hfile2 ├── hbase.id ├── hbase.version ├── masterProcWALs ← Master的WAL ├── oldWALs ← 旧的WAL文件 ├── staging └── WALs/ ← RegionServer的WAL └── RegionServer-name/ └── WAL-file6.3 HBase与HDFS的配置关联HBase需要知道HDFS的位置在hbase-site.xml中配置propertynamehbase.rootdir/namevaluehdfs://hadoop102:9000/HBase/valuedescriptionHBase在HDFS上的根目录/description/propertypropertynamehbase.cluster.distributed/namevaluetrue/valuedescription启用分布式模式/description/property七、HBase写流程详解7.1 写流程全景HBase的写流程是一个精心设计的多阶段过程兼顾了性能和可靠性上图展示了HBase的写路径时序图Client发送Put/Delete请求到RegionServerRegionServer先写入WAL保证数据不丢失再写入MemStore保证写入性能返回成功响应给Client后台异步Flush MemStore到HFile7.2 写流程详细步骤步骤1Client定位目标RegionServer关键点客户端会缓存Region位置信息Meta Cache避免每次请求都访问Zookeeper缓存失效如Region迁移时客户端会自动重新获取步骤2RegionServer处理写入请求写入顺序先写WAL数据追加写入HLog文件保证数据可靠性再写MemStore数据写入内存中的ConcurrentSkipListMap保证高性能返回ACK只要WAL和MemStore写入成功立即返回客户端成功为什么先写WAL再写MemStore如果先写MemStore写入成功后RegionServer宕机MemStore中的数据会丢失。先写WAL确保了即使宕机数据也可以通过WAL恢复。步骤3后台Flush到HFileFlush的触发条件将在第5篇详细讲解MemStore大小达到128MB默认RegionServer全局MemStore达到阈值距离上次Flush超过1小时WAL文件数量超过限制7.3 写流程的关键设计设计1WAL顺序写入WAL采用追加写入方式而不是随机修改磁盘顺序写入性能极高尤其是HDD不需要寻道时间与HDFS的Append-only特性完美契合设计2MemStore内存排序数据在MemStore中按RowKey排序为生成有序的HFile做准备有序HFile支持高效的二分查找和范围扫描避免了磁盘排序的开销设计3异步FlushFlush操作是异步的不影响写入请求的响应客户端收到ACK时数据可能还在MemStore中Flush在后台线程中执行即使Flush失败数据也不会丢失因为WAL已写入八、HBase读流程详解8.1 读流程全景HBase的读流程比写流程更复杂因为数据可能分布在多个位置上图展示了RegionServer中的读取路径先在BlockCache中查找缓存了之前读取的HFile数据块再在MemStore中查找未Flush的最新数据最后在HFile中查找磁盘中的历史数据8.2 读流程详细步骤步骤1Client定位目标RegionServer与写流程相同客户端首先定位目标RegionServer检查本地Meta Cache未命中则访问Zookeeper获取hbase:meta位置读取hbase:meta获取Region位置缓存到Meta Cache步骤2RegionServer处理读取请求┌─────────────┐ │ RegionServer│ │ │ │ ┌────────┐ │ │ │BlockCache│ │ ← 1. 在BlockCache中查找 │ │(读缓存) │ │ 命中直接返回 │ └────────┘ │ │ │ │ │ ▼ 未命中 │ ┌────────┐ │ │ │MemStore│ │ ← 2. 在MemStore中查找 │ │(写缓存) │ │ 获取最新版本数据 │ └────────┘ │ │ │ │ │ ▼ │ │ ┌────────┐ │ │ │ HFile │ │ ← 3. 在HFile中查找 │ │(磁盘) │ │ 读取相关数据块 │ └────────┘ │ │ │ │ │ ▼ │ │ ┌────────┐ │ │ │ 合并 │ │ ← 4. 合并所有来源的数据 │ │ 去重 │ │ 按时间戳选择最新版本 │ └────────┘ │ │ │ │ │ ▼ │ │ ┌────────┐ │ │ │ 返回 │ │ ← 5. 返回结果给Client │ │ 结果 │ │ │ └────────┘ │ └─────────────┘步骤3多数据源合并HBase读取时需要从三个数据源获取数据然后合并数据源数据特点查找方式BlockCache之前读取过的HFile数据块内存哈希查找O(1)MemStore未Flush的最新数据内存树查找O(log n)HFile已Flush的历史数据磁盘二分查找O(log n)合并规则同一CellRowKeyColumnFamilyColumnQualifier可能有多个版本按时间戳排序返回最新的版本或指定版本数Delete标记的数据会被过滤步骤4BlockCache缓存从HFile中读取的数据块会被放入BlockCache下次读取相同数据块时直接从内存获取采用LRU淘汰策略显著提升热点数据的读取性能8.3 读流程的关键设计设计1读缓存BlockCacheBlockCache是HBase读性能的关键缓存HFile的数据块默认64KB热点数据的缓存命中率可达90%以上支持多级缓存on-heap和off-heap设计2写缓存即读缓存MemStoreMemStore不仅是写缓存也是最新的读缓存未Flush的数据只能从MemStore读取MemStore中的数据按RowKey排序查找效率高读取时需要同时检查MemStore和HFile合并结果设计3布隆过滤器Bloom FilterHFile支持布隆过滤器用于快速判断某个RowKey是否存在于该HFile中如果不存在直接跳过该HFile减少IO如果可能存在再读取HFile确认显著提升Get操作的性能九、架构组件协作总结9.1 完整请求流程图┌─────────┐ │ Client │ └────┬────┘ │ │ 1. 查询Zookeeper获取hbase:meta位置 ▼ ┌─────────────┐ │ Zookeeper │ └──────┬──────┘ │ 返回meta RegionServer地址 ▼ ┌─────────────┐ │ RegionServer│ ← hbase:meta表所在节点 │ (meta) │ └──────┬──────┘ │ 2. 读取hbase:meta获取目标Region位置 ▼ ┌─────────────┐ │ RegionServer│ ← 目标数据所在节点 │ (data) │ │ │ │ ┌────────┐ │ ← WAL可靠性保障 │ │ WAL │ │ │ └────────┘ │ │ ┌────────┐ │ ← MemStore写缓存/最新读缓存 │ │MemStore│ │ │ └────────┘ │ │ ┌────────┐ │ ← BlockCache读缓存 │ │BlockCache│ │ │ └────────┘ │ │ ┌────────┐ │ ← StoreFile/HFile持久化数据 │ │ HFile │ │ │ └────────┘ │ └──────┬──────┘ │ 3. 执行读写操作 ▼ ┌─────────────┐ │ HDFS │ ← 底层存储 └─────────────┘9.2 各组件职责总结组件核心职责是否参与数据读写宕机影响HMaster元数据管理、Region分配、负载均衡否DDL操作不可用已有读写不受影响RegionServer数据读写、MemStore/StoreFile管理是该节点上的Region不可用需故障转移Zookeeper集群协调、Master选举、元数据入口否间接集群无法管理已有读写可能受影响HDFS数据持久化、副本容错是底层单DataNode宕机不影响有副本9.3 高可用保障组件高可用机制HMasterBackup Master Zookeeper选举RegionServer无状态设计宕机后Region迁移到其他节点ZookeeperZookeeper集群奇数个节点如3/5/7HDFS3副本机制自动复制十、架构相关的配置参数10.1 HMaster相关配置!-- HBase Master端口 --propertynamehbase.master.port/namevalue16000/value/property!-- HBase Master Web UI端口 --propertynamehbase.master.info.port/namevalue16010/value/property10.2 RegionServer相关配置!-- RegionServer端口 --propertynamehbase.regionserver.port/namevalue16020/value/property!-- RegionServer Web UI端口 --propertynamehbase.regionserver.info.port/namevalue16030/value/property!-- MemStore Flush阈值 --propertynamehbase.hregion.memstore.flush.size/namevalue134217728/value!-- 128MB --/property!-- RegionServer全局MemStore上限 --propertynamehbase.regionserver.global.memstore.size/namevalue0.4/value!-- JVM堆的40% --/property10.3 Zookeeper相关配置!-- Zookeeper集群地址 --propertynamehbase.zookeeper.quorum/namevaluehadoop102,hadoop103,hadoop104/value/property!-- Zookeeper会话超时时间 --propertynamezookeeper.session.timeout/namevalue90000/value!-- 90秒 --/property十一、常见问题与排查Q1HMaster和RegionServer都宕机了数据会丢失吗不会。因为数据已经持久化到HDFS通过WAL和HFileHDFS有3副本机制重启后HMaster会重新分配RegionRegionServer会恢复WAL但未Flush的MemStore数据在RegionServer宕机时可能丢失这正是WAL存在的意义——通过WAL可以恢复这些数据。Q2为什么HBase是读比写慢的框架这个说法需要辩证理解写入快因为写入只需追加WAL和MemStore内存操作返回ACK很快读取慢因为读取需要查找多个数据源BlockCache、MemStore、多个HFile还要合并多版本数据但HBase的读取性能在海量数据场景下仍然优秀因为BlockCache缓存热点数据HFile有序存储支持高效查找布隆过滤器减少无效IOQ3Meta Cache失效了怎么办客户端的Meta Cache可能因Region迁移而失效客户端请求RegionServer发现Region已不在该节点RegionServer返回NotServingRegionException客户端清除缓存的Region位置重新访问Zookeeper获取最新的Region位置更新Meta Cache重新发送请求这个过程对应用透明客户端会自动处理。Q4如何查看HBase集群状态Web UIHMaster Web UIhttp://hmaster-host:16010RegionServer Web UIhttp://regionserver-host:16030Shell命令# 查看集群状态hbase(main):001:0status# 查看RegionServer列表hbase(main):002:0statussimple# 查看Region分布hbase(main):003:0statusdetailed十二、总结12.1 核心要点回顾组件职责关键特性HMaster集群管理表管理、Region分配、负载均衡、故障恢复RegionServer数据读写WAL、MemStore、BlockCache、StoreFile管理Zookeeper分布式协调Master选举、节点监控、元数据入口HDFS底层存储分布式文件存储、3副本容错12.2 读写流程口诀写入先查缓存定位RegionServer先写WAL保可靠再写MemStore保性能异步Flush刷磁盘返回ACK客户端。读取先查缓存定位RegionServer先查BlockCache命中快再查MemStore最新态最后HFile磁盘来合并去重返回快。12.3 架构设计精髓HBase的架构设计体现了几个重要的分布式系统设计原则读写分离写入走WALMemStore读取走BlockCacheMemStoreHFile分层缓存BlockCache缓存磁盘数据MemStore缓存未Flush数据顺序写优化WAL追加写MemStore内存排序HFile顺序写自动分片Region自动分裂数据均匀分布故障自愈Zookeeper监控自动故障转移如果本文对你有帮助欢迎点赞、收藏、关注专栏有问题请在评论区留言讨论。
HBase架构原理解析——Master、RegionServer与Zookeeper的协作
发布时间：2026/6/4 19:00:22
一、引言为什么需要理解HBase架构在前两篇文章中我们了解了HBase的基本概念和数据模型。但要想真正掌握HBase理解其架构原理是必不可少的。HBase的架构设计决定了它的性能特征、可用性保证以及运维方式。HBase采用经典的Master-Slave架构包含四个核心组件HMaster集群的管理者负责元数据管理和负载均衡RegionServer数据的实际管理者负责读写请求处理Zookeeper分布式协调服务保障集群高可用HDFS底层存储系统提供数据持久化本文将从整体架构入手逐一剖析每个组件的职责然后详细讲解读写流程的全链路。二、HBase整体架构概览2.1 架构全景图HBase集群由多个节点组成每个节点承担不同的角色上图展示了HBase的整体架构Client客户端发起读写请求HMaster管理节点负责表和Region的元数据管理RegionServer数据节点负责实际的数据读写Zookeeper协调节点维护集群状态和元数据入口HDFS存储层所有数据最终持久化到HDFS2.2 架构层次关系三、HMaster集群的管理者3.1 HMaster的职责HMaster是HBase集群的管理节点负责整个集群的元数据管理和协调工作。其实现类为HMaster。职责1表级别操作HMaster负责所有与表相关的管理操作操作类型具体命令说明创建表create创建新表并分配初始Region删除表drop删除表及其所有数据修改表alter修改表结构如增加列族启用/禁用表enable/disable控制表的可用状态职责2RegionServer管理HMaster负责RegionServer的生命周期管理分配Region将Region分配给合适的RegionServer监控状态通过Zookeeper监控每个RegionServer的心跳负载均衡定期检查Region分布进行负载均衡调整故障转移RegionServer宕机时将其上的Region迁移到其他节点职责3Region管理Region分裂监控监控Region大小触发Split操作Region合并协调协调Major Compaction后的Region合并Region迁移根据负载情况迁移Region3.2 HMaster的高可用HBase支持配置Backup Master实现HMaster的高可用高可用机制多个HMaster节点同时启动通过Zookeeper竞争成为Active MasterZookeeper的临时节点机制保证只有一个Active MasterActive Master宕机时Standby Master自动接管所有RegionServer同时向Zookeeper注册新Master可以快速发现它们配置Backup Master# 在conf目录下创建backup-masters文件touchconf/backup-masters# 添加备份Master节点echohadoop103conf/backup-masters# 将配置同步到所有节点xsync conf/3.3 HMaster不是性能瓶颈重要认知HMaster不参与实际的数据读写只负责元数据管理。因此HMaster的负载很轻通常不会成为性能瓶颈即使HMaster短暂不可用已有的数据读写仍然可以继续因为客户端会缓存Region位置信息但HMaster宕机期间无法进行DDL操作创建/删除表等和Region的重新分配四、RegionServer数据的实际管理者4.1 RegionServer的职责RegionServer是HBase中最核心的组件负责实际的数据存储和读写处理。其实现类为HRegionServer。职责1数据操作RegionServer直接处理客户端的数据读写请求操作说明Get根据RowKey获取单条数据Put写入/更新数据Delete删除数据添加Delete标记Scan范围扫描数据职责2Region管理Region服务为分配给它的Region提供读写服务Region分裂当Region过大时执行Split操作Region合并参与Compaction过程职责3存储管理MemStore管理管理内存中的写缓存StoreFile管理管理磁盘中的HFile文件Flush操作将MemStore数据刷写到HDFSCompaction合并StoreFile清理过期数据4.2 RegionServer的内部结构上图展示了RegionServer的内部结构一个RegionServer管理多个Region每个Region包含多个Store每个列族一个Store每个Store包含一个MemStore内存缓存和多个StoreFile磁盘文件所有Region共享一个HLogWAL预写日志4.3 RegionServer的关键组件组件1WALWrite-Ahead Log预写日志WAL是HBase数据可靠性的核心保障WAL的作用数据恢复RegionServer宕机时通过WAL恢复未Flush的MemStore数据顺序写入WAL采用追加写入方式性能极高数据可靠性数据先写WAL再写MemStore确保不丢失WAL的存储WAL文件存储在HDFS上默认每个RegionServer一个WAL可以配置多个WALMultiWAL提升并发写入性能WAL文件会定期滚动Roll旧的WAL在数据Flush后可以删除组件2MemStore内存写缓存MemStore是HBase高性能写入的关键上图展示了WAL、MemStore和HFile的关系数据先写入WAL保证可靠性再写入MemStore保证写入性能MemStore中的数据排序后Flush生成HFileMemStore的核心特性特性说明排序存储数据在MemStore中按RowKey排序为生成有序HFile做准备内存结构使用ConcurrentSkipListMap实现支持高并发写入Flush机制达到一定阈值后批量刷写到HDFS生成HFile多版本支持同一Cell的多个版本在MemStore中同时存在MemStore的Flush时机将在第5篇详细讲解MemStore大小达到hbase.hregion.memstore.flush.size默认128MBRegionServer全局MemStore大小达到阈值距离上次Flush超过一定时间默认1小时WAL文件数量超过限制组件3BlockCache读缓存BlockCache是HBase提升读性能的关键组件上图展示了RegionServer中的缓存结构BlockCache缓存从HFile中读取的数据块BlockMemStore同时作为写缓存和未Flush数据的读缓存HFile磁盘中的持久化数据BlockCache的核心特性特性说明LRU淘汰采用最近最少使用策略自动淘汰不常用的数据块块大小默认64KB与HFile的块大小对应多级缓存支持on-heapJVM堆内和off-heap堆外缓存缓存命中率热点数据的缓存命中率通常可达90%以上读取数据时的缓存查找顺序先在BlockCache中查找内存最快再在MemStore中查找内存未Flush的数据最后在**StoreFileHFile**中查找磁盘最慢五、Zookeeper分布式协调的基石5.1 Zookeeper在HBase中的作用Zookeeper是HBase集群正常运行的基石承担以下关键职责职责1Master高可用┌─────────────┐ │ Zookeeper │ │ /hbase │ │ /master │ ← 临时节点只有一个Master能创建成功 └──────┬──────┘ │ ▼ ┌─────────────┐ ┌─────────────┐ │ HMaster-1 │ │ HMaster-2 │ │ (Active) │ │ (Standby) │ │ 持有锁 │ │ 监听节点 │ └─────────────┘ └─────────────┘多个HMaster竞争创建Zookeeper临时节点创建成功者成为Active Master其他Master监听该节点Active Master宕机时自动接管职责2RegionServer监控┌─────────────┐ │ Zookeeper │ │ /hbase │ │ /rs │ ← RegionServer注册目录 │ /rs1 │ ← 每个RegionServer创建一个临时节点 │ /rs2 │ │ /rs3 │ └─────────────┘每个RegionServer启动时向Zookeeper注册临时节点HMaster通过监听这些节点监控RegionServer状态RegionServer宕机时临时节点自动删除HMaster感知并处理故障转移职责3元数据入口┌─────────────┐ │ Zookeeper │ │ /hbase │ │ /meta-region-server │ ← hbase:meta表所在的RegionServer地址 └─────────────┘hbase:meta表存储了所有用户表的Region位置信息客户端通过Zookeeper找到hbase:meta表所在的RegionServer然后读取hbase:meta表获取目标数据的位置职责4集群配置管理存储集群的配置信息协调分布式操作如表禁用/启用状态5.2 Zookeeper的关键配置在hbase-site.xml中配置Zookeeperpropertynamehbase.zookeeper.quorum/namevaluehadoop102,hadoop103,hadoop104/valuedescriptionZookeeper集群地址/description/propertypropertynamehbase.zookeeper.property.clientPort/namevalue2181/valuedescriptionZookeeper客户端端口/description/propertypropertynamehbase.zookeeper.property.dataDir/namevalue/opt/module/zookeeper-3.4.10/zkData/valuedescriptionZookeeper数据目录/description/property5.3 Zookeeper与HBase的交互流程┌─────────┐ ┌─────────────┐ ┌─────────────┐ │ Client │────►│ Zookeeper │────►│ hbase:meta │ │ │ │ │ │ 所在位置 │ └────┬────┘ └─────────────┘ └─────────────┘ │ │ 获取meta表位置 ▼ ┌─────────────┐ ┌─────────────┐ │ RegionServer│────►│ hbase:meta │ │ (meta所在) │ │ 读取Region │ └────┬────────┘ │ 位置信息 │ │ └─────────────┘ │ 获取目标Region位置 ▼ ┌─────────────┐ ┌─────────────┐ │ RegionServer│────►│ 目标数据 │ │ (数据所在) │ │ 读写操作 │ └─────────────┘ └─────────────┘六、HDFS底层存储的保障6.1 HDFS在HBase中的作用HDFSHadoop Distributed File System为HBase提供最终的底层数据存储服务HDFS特性对HBase的意义分布式存储数据分散在多个DataNode支持海量存储副本机制默认3副本自动容错数据不丢失高吞吐顺序读写适合HBase的批量Flush和Compaction故障自动恢复DataNode宕机自动复制副本对HBase透明6.2 HBase在HDFS上的存储结构/hbase/ ├── .hbaseid ← HBase实例ID ├── .tmp ← 临时目录 ├── archive ← 归档目录已删除的HFile ├── corrupt ← 损坏文件目录 ├── data/ │ └── default/ ← 默认命名空间 │ └── student/ ← 表目录 │ └── region-hash/ ← Region目录 │ ├── info/ ← 列族目录 │ │ └── hfile1 ← HFile数据文件 │ └── personal_info/ │ └── hfile2 ├── hbase.id ├── hbase.version ├── masterProcWALs ← Master的WAL ├── oldWALs ← 旧的WAL文件 ├── staging └── WALs/ ← RegionServer的WAL └── RegionServer-name/ └── WAL-file6.3 HBase与HDFS的配置关联HBase需要知道HDFS的位置在hbase-site.xml中配置propertynamehbase.rootdir/namevaluehdfs://hadoop102:9000/HBase/valuedescriptionHBase在HDFS上的根目录/description/propertypropertynamehbase.cluster.distributed/namevaluetrue/valuedescription启用分布式模式/description/property七、HBase写流程详解7.1 写流程全景HBase的写流程是一个精心设计的多阶段过程兼顾了性能和可靠性上图展示了HBase的写路径时序图Client发送Put/Delete请求到RegionServerRegionServer先写入WAL保证数据不丢失再写入MemStore保证写入性能返回成功响应给Client后台异步Flush MemStore到HFile7.2 写流程详细步骤步骤1Client定位目标RegionServer关键点客户端会缓存Region位置信息Meta Cache避免每次请求都访问Zookeeper缓存失效如Region迁移时客户端会自动重新获取步骤2RegionServer处理写入请求写入顺序先写WAL数据追加写入HLog文件保证数据可靠性再写MemStore数据写入内存中的ConcurrentSkipListMap保证高性能返回ACK只要WAL和MemStore写入成功立即返回客户端成功为什么先写WAL再写MemStore如果先写MemStore写入成功后RegionServer宕机MemStore中的数据会丢失。先写WAL确保了即使宕机数据也可以通过WAL恢复。步骤3后台Flush到HFileFlush的触发条件将在第5篇详细讲解MemStore大小达到128MB默认RegionServer全局MemStore达到阈值距离上次Flush超过1小时WAL文件数量超过限制7.3 写流程的关键设计设计1WAL顺序写入WAL采用追加写入方式而不是随机修改磁盘顺序写入性能极高尤其是HDD不需要寻道时间与HDFS的Append-only特性完美契合设计2MemStore内存排序数据在MemStore中按RowKey排序为生成有序的HFile做准备有序HFile支持高效的二分查找和范围扫描避免了磁盘排序的开销设计3异步FlushFlush操作是异步的不影响写入请求的响应客户端收到ACK时数据可能还在MemStore中Flush在后台线程中执行即使Flush失败数据也不会丢失因为WAL已写入八、HBase读流程详解8.1 读流程全景HBase的读流程比写流程更复杂因为数据可能分布在多个位置上图展示了RegionServer中的读取路径先在BlockCache中查找缓存了之前读取的HFile数据块再在MemStore中查找未Flush的最新数据最后在HFile中查找磁盘中的历史数据8.2 读流程详细步骤步骤1Client定位目标RegionServer与写流程相同客户端首先定位目标RegionServer检查本地Meta Cache未命中则访问Zookeeper获取hbase:meta位置读取hbase:meta获取Region位置缓存到Meta Cache步骤2RegionServer处理读取请求┌─────────────┐ │ RegionServer│ │ │ │ ┌────────┐ │ │ │BlockCache│ │ ← 1. 在BlockCache中查找 │ │(读缓存) │ │ 命中直接返回 │ └────────┘ │ │ │ │ │ ▼ 未命中 │ ┌────────┐ │ │ │MemStore│ │ ← 2. 在MemStore中查找 │ │(写缓存) │ │ 获取最新版本数据 │ └────────┘ │ │ │ │ │ ▼ │ │ ┌────────┐ │ │ │ HFile │ │ ← 3. 在HFile中查找 │ │(磁盘) │ │ 读取相关数据块 │ └────────┘ │ │ │ │ │ ▼ │ │ ┌────────┐ │ │ │ 合并 │ │ ← 4. 合并所有来源的数据 │ │ 去重 │ │ 按时间戳选择最新版本 │ └────────┘ │ │ │ │ │ ▼ │ │ ┌────────┐ │ │ │ 返回 │ │ ← 5. 返回结果给Client │ │ 结果 │ │ │ └────────┘ │ └─────────────┘步骤3多数据源合并HBase读取时需要从三个数据源获取数据然后合并数据源数据特点查找方式BlockCache之前读取过的HFile数据块内存哈希查找O(1)MemStore未Flush的最新数据内存树查找O(log n)HFile已Flush的历史数据磁盘二分查找O(log n)合并规则同一CellRowKeyColumnFamilyColumnQualifier可能有多个版本按时间戳排序返回最新的版本或指定版本数Delete标记的数据会被过滤步骤4BlockCache缓存从HFile中读取的数据块会被放入BlockCache下次读取相同数据块时直接从内存获取采用LRU淘汰策略显著提升热点数据的读取性能8.3 读流程的关键设计设计1读缓存BlockCacheBlockCache是HBase读性能的关键缓存HFile的数据块默认64KB热点数据的缓存命中率可达90%以上支持多级缓存on-heap和off-heap设计2写缓存即读缓存MemStoreMemStore不仅是写缓存也是最新的读缓存未Flush的数据只能从MemStore读取MemStore中的数据按RowKey排序查找效率高读取时需要同时检查MemStore和HFile合并结果设计3布隆过滤器Bloom FilterHFile支持布隆过滤器用于快速判断某个RowKey是否存在于该HFile中如果不存在直接跳过该HFile减少IO如果可能存在再读取HFile确认显著提升Get操作的性能九、架构组件协作总结9.1 完整请求流程图┌─────────┐ │ Client │ └────┬────┘ │ │ 1. 查询Zookeeper获取hbase:meta位置 ▼ ┌─────────────┐ │ Zookeeper │ └──────┬──────┘ │ 返回meta RegionServer地址 ▼ ┌─────────────┐ │ RegionServer│ ← hbase:meta表所在节点 │ (meta) │ └──────┬──────┘ │ 2. 读取hbase:meta获取目标Region位置 ▼ ┌─────────────┐ │ RegionServer│ ← 目标数据所在节点 │ (data) │ │ │ │ ┌────────┐ │ ← WAL可靠性保障 │ │ WAL │ │ │ └────────┘ │ │ ┌────────┐ │ ← MemStore写缓存/最新读缓存 │ │MemStore│ │ │ └────────┘ │ │ ┌────────┐ │ ← BlockCache读缓存 │ │BlockCache│ │ │ └────────┘ │ │ ┌────────┐ │ ← StoreFile/HFile持久化数据 │ │ HFile │ │ │ └────────┘ │ └──────┬──────┘ │ 3. 执行读写操作 ▼ ┌─────────────┐ │ HDFS │ ← 底层存储 └─────────────┘9.2 各组件职责总结组件核心职责是否参与数据读写宕机影响HMaster元数据管理、Region分配、负载均衡否DDL操作不可用已有读写不受影响RegionServer数据读写、MemStore/StoreFile管理是该节点上的Region不可用需故障转移Zookeeper集群协调、Master选举、元数据入口否间接集群无法管理已有读写可能受影响HDFS数据持久化、副本容错是底层单DataNode宕机不影响有副本9.3 高可用保障组件高可用机制HMasterBackup Master Zookeeper选举RegionServer无状态设计宕机后Region迁移到其他节点ZookeeperZookeeper集群奇数个节点如3/5/7HDFS3副本机制自动复制十、架构相关的配置参数10.1 HMaster相关配置!-- HBase Master端口 --propertynamehbase.master.port/namevalue16000/value/property!-- HBase Master Web UI端口 --propertynamehbase.master.info.port/namevalue16010/value/property10.2 RegionServer相关配置!-- RegionServer端口 --propertynamehbase.regionserver.port/namevalue16020/value/property!-- RegionServer Web UI端口 --propertynamehbase.regionserver.info.port/namevalue16030/value/property!-- MemStore Flush阈值 --propertynamehbase.hregion.memstore.flush.size/namevalue134217728/value!-- 128MB --/property!-- RegionServer全局MemStore上限 --propertynamehbase.regionserver.global.memstore.size/namevalue0.4/value!-- JVM堆的40% --/property10.3 Zookeeper相关配置!-- Zookeeper集群地址 --propertynamehbase.zookeeper.quorum/namevaluehadoop102,hadoop103,hadoop104/value/property!-- Zookeeper会话超时时间 --propertynamezookeeper.session.timeout/namevalue90000/value!-- 90秒 --/property十一、常见问题与排查Q1HMaster和RegionServer都宕机了数据会丢失吗不会。因为数据已经持久化到HDFS通过WAL和HFileHDFS有3副本机制重启后HMaster会重新分配RegionRegionServer会恢复WAL但未Flush的MemStore数据在RegionServer宕机时可能丢失这正是WAL存在的意义——通过WAL可以恢复这些数据。Q2为什么HBase是读比写慢的框架这个说法需要辩证理解写入快因为写入只需追加WAL和MemStore内存操作返回ACK很快读取慢因为读取需要查找多个数据源BlockCache、MemStore、多个HFile还要合并多版本数据但HBase的读取性能在海量数据场景下仍然优秀因为BlockCache缓存热点数据HFile有序存储支持高效查找布隆过滤器减少无效IOQ3Meta Cache失效了怎么办客户端的Meta Cache可能因Region迁移而失效客户端请求RegionServer发现Region已不在该节点RegionServer返回NotServingRegionException客户端清除缓存的Region位置重新访问Zookeeper获取最新的Region位置更新Meta Cache重新发送请求这个过程对应用透明客户端会自动处理。Q4如何查看HBase集群状态Web UIHMaster Web UIhttp://hmaster-host:16010RegionServer Web UIhttp://regionserver-host:16030Shell命令# 查看集群状态hbase(main):001:0status# 查看RegionServer列表hbase(main):002:0statussimple# 查看Region分布hbase(main):003:0statusdetailed十二、总结12.1 核心要点回顾组件职责关键特性HMaster集群管理表管理、Region分配、负载均衡、故障恢复RegionServer数据读写WAL、MemStore、BlockCache、StoreFile管理Zookeeper分布式协调Master选举、节点监控、元数据入口HDFS底层存储分布式文件存储、3副本容错12.2 读写流程口诀写入先查缓存定位RegionServer先写WAL保可靠再写MemStore保性能异步Flush刷磁盘返回ACK客户端。读取先查缓存定位RegionServer先查BlockCache命中快再查MemStore最新态最后HFile磁盘来合并去重返回快。12.3 架构设计精髓HBase的架构设计体现了几个重要的分布式系统设计原则读写分离写入走WALMemStore读取走BlockCacheMemStoreHFile分层缓存BlockCache缓存磁盘数据MemStore缓存未Flush数据顺序写优化WAL追加写MemStore内存排序HFile顺序写自动分片Region自动分裂数据均匀分布故障自愈Zookeeper监控自动故障转移如果本文对你有帮助欢迎点赞、收藏、关注专栏有问题请在评论区留言讨论。
相关文章
学术写作新纪元！2026全流程AI写作辅助网站推荐指南
2026 年 AI 论文写作工具已进入全流程闭环 学术合规时代，千笔 AI（综合评分 99 分）中文学术场景标杆；Grammarly Academic与Elicit为英文论文写作首选；按需求匹配度 - 数据可信度 - 成本承受力三维模型选型，…
低空+生态环保落地SaaS新模式：空天地一体化监测组网，破解环境治理四大行业痛点
传统生态环境监测受地理环境、人力成本、部门协同等多重因素制约，存在监测覆盖面不足、巡检效率偏低、治理闭环缺失等行业痛点。围绕低空智航SaaS平台落地生态环保场景，结合卫星遥感、AI 智能识别、大数据、多源传感技术，从立体感知、AI 解析…
南宁靠谱的牙科诊所top3推荐：高性价比服务让你无后顾之忧
在口腔健康日益受到重视的今天，选择一家技术过硬、服务贴心、价格透明的口腔门诊部，成为了许多消费者的核心诉求。尤其是在南宁这样医疗资源汇聚的城市，面对众多选择，往往令人眼花缭乱，不知从何下手。本次测评…
10分钟快速搭建专业开源问卷系统的完整指南
10分钟快速搭建专业开源问卷系统的完整指南 【免费下载链接】SurveyKing One command to deploy a more powerful, self‑hosted alternative to SurveyMonkey. 项目地址: https://gitcode.com/gh_mirrors/su/SurveyKing 想要快速搭建一个功能全面的问卷系统？…
Ice：让你的Mac菜单栏变得干净有序的智能管理工具
Ice：让你的Mac菜单栏变得干净有序的智能管理工具 【免费下载链接】Ice Powerful menu bar manager for macOS 项目地址: https://gitcode.com/GitHub_Trending/ice/Ice 你是否曾经盯着Mac屏幕顶部的菜单栏，看着那些密密麻麻的图标感到头疼&#x…
技术解析：ROFL-Player如何解决《英雄联盟》回放文件跨版本管理难题
技术解析：ROFL-Player如何解决《英雄联盟》回放文件跨版本管理难题 【免费下载链接】ROFL-Player (No longer supported) One stop shop utility for viewing League of Legends replays! 项目地址: https://gitcode.com/gh_mirrors/ro/ROFL-Player ROFL-Pla…
AKShare终极指南：快速免费获取全市场金融数据的完整教程
AKShare终极指南：快速免费获取全市场金融数据的完整教程 【免费下载链接】akshare AKShare is an elegant and simple financial data interface library for Python, built for human beings! 开源财经数据接口库 项目地址: https://gitcode.com/gh_mirrors/aks/…
为什么92%的财务团队AI收票项目半年内停滞？揭秘被忽视的票据语义理解盲区（含独家NLP校验矩阵）
更多请点击： https://intelliparadigm.com 第一章：为什么92%的财务团队AI收票项目半年内停滞？揭秘被忽视的票据语义理解盲区（含独家NLP校验矩阵） 财务团队在落地AI收票系统时，常将焦点集中于OCR识别准确率…
YY/T0681.5-2010气泡法检漏标准详解、取样数量要求
一、标准是什么YY/T0681.5-2010 是医用无菌包装袋泡水充气检漏国标，泡水持续冒气泡即为包装大泄漏。分两种检测：不透气膜袋（方法 A）：打孔插气管，入水直接加压测漏特卫强透气袋（方法 B࿰…
告别激活烦恼：IAR Embedded Workbench 许可证管理的最佳实践与合法替代方案探讨
IAR Embedded Workbench 许可证管理全指南与合规开发方案在嵌入式开发领域，IAR Embedded Workbench 以其高效的编译器和强大的调试功能著称，成为众多工程师的首选工具。然而，随着团队规模扩大和项目复杂度提升，许可证管理问题逐渐…
赤铁矿磨矿过程运行优化控制软件系统【附程序】
✨ 长期致力于赤铁矿磨矿过程、磨矿粒度、数据驱动、运行优化控制、神经网络、案例推理、规则推理、软件系统研究工作，擅长数据搜集与处理、建模仿真、程序编写、仿真设计。 ✅ 专业定制毕设、代码 ✅ 如需沟通交流，点击《获取方式》 （1&…
终极指南：如何使用Attu轻松管理你的Milvus向量数据库
终极指南：如何使用Attu轻松管理你的Milvus向量数据库 【免费下载链接】attu The Best GUI for Milvus 项目地址: https://gitcode.com/gh_mirrors/at/attu Attu是一款专为Milvus向量数据库设计的现代化AI工作台管理工具，提供全面的可视化界面&…
Win10/Win11下Realtek 8188GU网卡驱动感叹号？别急着扔，试试这个手动安装的野路子
Realtek 8188GU网卡驱动故障深度修复指南：从原理到实战当设备管理器里那个顽固的黄色感叹号挥之不去，而你已经尝试了所有"标准操作"——Windows自动更新、第三方驱动工具、甚至重启大法——却依然无济于事时，是时候换个思路了。这篇…
AnolisOS 8.8安装源配置踩坑实录：从‘设置基础软件仓库时出错’到成功联网的保姆级指南
AnolisOS 8.8安装源配置实战指南：从诊断到解决方案的全流程解析当你在安装AnolisOS 8.8时遇到"设置基础软件仓库时出错"的提示，这通常意味着系统无法访问或识别安装源。这个问题看似简单，但背后可能涉及网络配置、镜像选择、启动参…
基于树莓派Pico的反应速度测试游戏：从GPIO编程到状态机实战
1. 项目概述与核心思路最近在整理工作室的电子元件，翻出来几个闲置的街机按钮和一块树莓派Pico，灵机一动，决定做个简单又有趣的反应速度测试游戏。这个项目非常适合想入门嵌入式开发的朋友，它不涉及复杂的传感器和通信协议&#x…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…