HBase 核心架构和增删改查
一、HBase 核心架构
HBase 架构采用 “主从模式”，由客户端（Client）、主节点（HMaster）、从节点（RegionServer）、ZooKeeper、HDFS 五大核心组件构成，各组件职责明确且相互协作。
| 组件 | 核心职责 |
|---|---|
| Client | 1. 与 HMaster 交互完成表的创建 / 删除 / 修改（DDL 操作）；2. 与 RegionServer 交互完成数据增删改查（DML 操作）；3. 缓存 Region 位置信息，减少与 HMaster 的交互。 |
| HMaster | 1. 管理 RegionServer 集群（如 RegionServer 上线 / 下线检测、负载均衡）；2. 负责 Region 的分配与拆分（当 Region 数据量超过阈值时拆分）；3. 处理表的 DDL 操作（创建表、删除表、修改列族）；4. 通常部署多个（1 主 N 备），由 ZooKeeper 选主，保证高可用。 |
| RegionServer | 1. 存储并管理 “Region”（HBase 的最小数据存储单元，一个 Region 对应表的一段 RowKey 范围）；2. 处理客户端的 DML 请求（增删改查）；3. 维护 Region 内的 MemStore（内存缓存）和 HFile（磁盘持久化文件）；4. 定期将 MemStore 数据刷写到 HDFS 生成 HFile。 |
| ZooKeeper | 1. 存储 HBase 的元数据（如 HMaster 地址、表的 Region 分布信息）；2. 实现 HMaster 的选主（主节点故障时自动切换备节点）；3. 监控 RegionServer 的存活状态（通过心跳机制）。 |
| HDFS | 1. 持久化存储 HBase 的核心数据（HFile、WAL 日志）；2. 依托 HDFS 的分布式存储能力，保证 HBase 数据的高可靠（多副本）和高扩展。 |
关键概念补充：
- Region：HBase 表按 RowKey 范围拆分的 “数据分片”，每个 Region 由 1 个 RegionServer 管理，一个 RegionServer 可管理多个 Region。
- MemStore：Region 内的内存缓存，客户端写入数据先存 MemStore，满了之后刷写到 HDFS 生成 HFile（顺序写，效率高）。
- WAL（Write-Ahead Log）：写入 MemStore 前先写 WAL 日志，防止 MemStore 数据丢失（如 RegionServer 宕机，可通过 WAL 恢复数据）。
- HFile：HBase 在 HDFS 上的持久化数据文件，按列族存储，内部数据按 RowKey 有序排列。
二、HBase 增删改查（CRUD）流程
HBase 的 CRUD 操作均由 Client 发起，依赖 RegionServer 完成实际数据处理，核心围绕 “MemStore 缓存 + WAL 保障 + HFile 持久化” 展开。
1. 写入（Create/Insert）流程
- 定位 Region：Client 通过 ZooKeeper 获取表的 Region 分布信息，找到待写入 RowKey 对应的 RegionServer。
- 写 WAL 日志：Client 将数据发送到目标 RegionServer，RegionServer 先将数据顺序写入 WAL 日志（确保数据不丢失）。
- 写 MemStore：WAL 写入成功后，数据被插入到对应 Region 的 MemStore（内存缓存，按 RowKey 有序排列）。
- 完成响应：MemStore 写入成功后，RegionServer 向 Client 返回 “写入成功”。
- 后台刷写：当 MemStore 大小达到阈值（默认 128MB），RegionServer 异步将 MemStore 数据刷写到 HDFS，生成 HFile（此时数据持久化）。
2. 查询（Read）流程
- 定位 Region：Client 通过 ZooKeeper 找到待查询 RowKey 对应的 RegionServer。
- 查询 MemStore：RegionServer 先查询目标 Region 的 MemStore，若找到对应 RowKey 数据，直接返回（内存查询快）。
- 查询 BlockCache：若 MemStore 未找到，查询 BlockCache（HFile 的内存缓存，缓存热点 HFile 块），命中则返回。
- 查询 HFile：若 BlockCache 未命中，从 HDFS 读取对应的 HFile，加载数据到 BlockCache（方便后续查询），并返回数据给 Client。
- 合并结果：若查询涉及多个 HFile（如历史版本数据），RegionServer 会合并多文件中的数据，返回最新版本给 Client。
3. 修改（Update）流程
HBase 无 “原地修改”，而是通过 “写入新版本数据” 实现更新，本质是特殊的 “写入操作”：
- 流程与 “写入” 完全一致，Client 写入一条相同 RowKey、相同列族的新数据。
- HBase 会为数据自动添加 “时间戳”（版本号），查询时默认返回时间戳最大的最新版本数据。
- 旧版本数据不会立即删除，会在后台 “Compaction”（合并 HFile）时清理（按列族配置的版本数保留策略，如保留最近 3 个版本）。
4. 删除（Delete）流程
HBase 无 “物理删除”，而是通过 “标记删除”（Tombstone）实现，延迟到 Compaction 时清理：
- 写入删除标记：Client 发起删除请求，RegionServer 先写 WAL 日志，再向 MemStore 插入一条 “删除标记”（Tombstone，包含待删除 RowKey / 列族 / 时间戳）。
- 查询屏蔽：后续查询时，若遇到 “删除标记”，会屏蔽对应版本的数据，不返回给 Client（看起来已删除）。
- 物理清理：后台 Compaction 合并 HFile 时，会过滤掉带 “删除标记” 的数据，彻底从 HDFS 中删除（释放存储空间）。
三、核心设计逻辑总结
- 写入优化：“先写 WAL 再写 MemStore”+“MemStore 满了刷 HFile”，通过顺序写（WAL、HFile）规避磁盘随机写，提升写入效率。
- 查询优化：多级缓存（MemStore→BlockCache→HFile），优先从内存获取数据，减少 HDFS 读 IO，提升查询速度。
- 高可用保障：HMaster 主备切换（ZooKeeper 选主）+ WAL 日志恢复（RegionServer 宕机数据不丢）+ HDFS 多副本（HFile 高可靠）。
-HBase 中的 Compaction 触发情况
- MemStore 刷盘后：当 MemStore 刷写（Flush）生成新的 HFile 后，系统会检查当前 Store 中的 HFile 数量是否超过阈值
hbase.hstore.compactionThreshold，其默认值为 3。若超过阈值，则触发 Minor Compaction。 - 后台线程周期性检查：后台线程 CompactionChecker 会定期检查是否需要执行 Compaction，检查周期为
hbase.server.thread.wakefrequency与hbase.server.compactchecker.interval.multiplier的乘积，其中hbase.server.thread.wakefrequency默认值为 10000 毫秒，即 10 秒，hbase.server.compactchecker.interval.multiplier默认值为 1000，所以默认检查周期约为 2 小时 46 分 40 秒。该线程先检查文件数是否大于配置，一旦大于就会触发 Compaction，如果不满足，会接着检查是否满足 Major Compaction 条件，即当前 store 中 HFile 的最早更新时间早于某个值 mcTime，若满足则触发 Major Compaction。 - 基于时间的 Major Compaction：默认每 7 天（由参数
hbase.hregion.majorcompaction控制，默认值为 604800000 毫秒）尝试触发一次 Major Compaction，实际触发时间会加入抖动（由参数hbase.hregion.majorcompaction.jitter控制，默认值为 0.5），使时间窗口在 3.5 到 10.5 天内随机分布。 - 手动触发：可以通过 HBase Shell 或 API 执行
compact或major_compact命令来手动触发 Compaction。通常在业务低峰期手动触发 Major Compaction 以避免自动触发影响业务，或在执行完alter操作后希望立刻生效，以及 HBase 管理员发现硬盘容量不够的情况下手动触发 Major Compaction 来删除大量过期数据。