第 1 章 · 初见 HBase:模型与架构 章节摘要:本章回答三个问题——HBase 解决了什么关系型数据库解决不了的问题;一行数据在逻辑上长什么样(RowKey、列族、单元格版本);这行数据物理上被谁管理(HMaster、RegionServer、ZooKeeper 三层架构)。最后动手装一个单机版,用 Shell 真正写入第一行数据,为后续章节的"落点之旅"备好环境。 学习目标 阅读完本章,你应当能够: 说清 HBase 与 MySQL、HDFS 各自的边界:什么场景选它,什么场景别用它; 用 RowKey、列族、列限定符、单元格版本四个概念精确描述一行数据; 画出 HBase 架构三层图,解释 Meta 表的 Region 寻址过程;
章节摘要:本章回答三个问题——HBase 解决了什么关系型数据库解决不了的问题;一行数据在逻辑上长什么样(RowKey、列族、单元格版本);这行数据物理上被谁管理(HMaster、RegionServer、ZooKeeper 三层架构)。最后动手装一个单机版,用 Shell 真正写入第一行数据,为后续章节的"落点之旅"备好环境。
阅读完本章,你应当能够:
行键是逻辑定位符,Region 是物理存放单元——一行数据落在哪,由它的 RowKey 和当时的 Region 边界共同决定。

从 MySQL 分库分表的困境和 HDFS 无法随机读的两个痛点出发,推出"海量数据 + 随机读写"这个空档,讲清 HBase 的取舍:放弃 SQL 与跨行事务,换来线性扩展与毫秒级点查。
一行数据的逻辑形态。重点讲"稀疏"的含义、四维坐标(行键、列族、列限定符、时间戳)定位一个单元格,以及多版本在业务里的用法。
物理形态。HMaster 管元数据与负载、RegionServer 管数据、ZooKeeper 管协调;客户端三级寻址(ZooKeeper → Meta 表 → 目标 RegionServer)的过程在本节首次完整走通。
动手节。单机模式部署 JDK 与 HBase,建表、put、get、scan、delete 一路敲下来,并顺手看一眼 Web UI 里的 Region 分布。
为什么需要(动机) | 数据模型(逻辑上一行长什么样) | 架构与寻址(物理上这行归谁管) | 安装与 Shell(亲手写一行,看它落盘)
前三节是"看",第四节是"做"。1.2 的 RowKey 概念是第 5 章 Schema 设计的种子,1.3 的寻址链路是第 3 章 Region 管理的入口,务必在这两节打牢。