1.1 为什么需要 HBase：海量数据与随机读写的空档

1.1 为什么需要 HBase：海量数据与随机读写的空档

本节摘要：HBase 是面向列族的分布式 NoSQL 数据库，填补"数据量大到 PB 级、同时要求毫秒级随机读写"这个关系型数据库和 HDFS 都覆盖不了的空档。本节从两个真实困境推出这个空档，并明确 HBase 的能力边界与代价。

一个把 MySQL 逼到墙角的需求

假设你在做电信信令分析，每天新增 200 亿条记录，要保存 6 个月，总量 3000 多亿行。同时业务方有两个要求：一是任意一个用户号，能在一秒内查出他最近的通话轨迹；二是新数据写入不能阻塞。

单库 MySQL 走到 5 亿行左右，B+ 树高度增加、索引膨胀，点查延迟开始抖动；分库分表能扛一阵，但 3000 亿行意味着几千个分片，跨片查询、二次扩容、分片键改造都是持续失血的成本。更麻烦的是这类数据"宽而不定"：不同制式的信令字段完全不同，关系模型里只能建几百列的宽表，其中大半为空。

再看另一头。HDFS 存 PB 级数据毫无压力，MapReduce/Spark 批处理也没问题——但要"查某个用户最近 10 条记录"，它只能全表扫描或者自己维护一套外部索引，延迟以分钟计。HDFS 的文件是追加写、块为单位，天生不支持按行随机定位。

把两个困境放在一起，空档就出来了：

HBase 用什么换来了这个位置

HBase 能同时要"大"和"快"，靠的是三个结构性决定，每个都有代价。

第一，按 RowKey 字典序组织，数据物理上连续。 一行数据落在哪个 Region、哪台机器，完全由 RowKey 排序决定。这让按行键的范围扫描变得极快（相邻数据在一起），也意味着没有二级索引——按非行键列查就是全表扫描。第 5 章会讲怎么绕。

第二，LSM-Tree 写入模型：顺序写换随机写。 磁盘顺序写的吞吐比随机写高一到两个数量级，HBase 的写入只追加 WAL 和内存缓冲，不动磁盘上的既有数据，靠后台 Compaction 慢慢整理。代价是读路径要查多个文件做合并、写放大与读放大都存在。这是第 2、3 章的主线。

第三，构建在 HDFS 之上，存储层零开发。 数据文件（HFile）放在 HDFS，天然多副本、免运维磁盘。代价是强绑定 Hadoop 生态，部署重，且 HDFS 的三副本是"整文件冗余"，没有 Cassandra 那种机架感知的精准放置。

⚠️ 常见坑：把 HBase 当"更大号的 MySQL"来选型，上来就要二级索引、Join、跨行事务。这些要么没有，要么要靠协处理器或外部组件拼装，成本远高于换一个数据库。

什么时候不该用 HBase

我见过不少失败的引入，共同点是数据量根本没到位。以下场景建议直接绕开：

• 数据量在千万行以内：单库 MySQL 或 PostgreSQL 加好索引绰绰有余，引入 HBase 纯属自找运维负担；
• 需要复杂查询与聚合：多表关联、即席分析是 ClickHouse、Doris 的地盘，HBase 上做这些事倍功半；
• 需要强事务：转账类的多行原子操作，HBase 只保证单行内多列原子写；
• Value 巨大：单值超过几十 MB（比如直接存视频），HBase 会把 Region 撑爆，应存对象存储、HBase 只存指针。

反过来，这些信号出现时就该认真考虑 HBase 了：数据量 TB 级且持续增长；读写模式以按主键点查和范围扫描为主；列结构多变且稀疏；写多读少或读写都要求低延迟。典型的落地场景有用户画像、消息流水、时序监控、风控特征存储——第 7 章会拿其中两个做完整实战。

选型前先算四笔账

"数据量大"是个模糊说法，落到工程上要能换算成机器数。回到开头那个信令需求，我们做一次粗算，这套算法以后每次选型都能用。

第一笔，写入吞吐。 每天 200 亿条、按 10 小时高峰折算约 55 万条每秒。一条记录净荷 300 字节，加行键与元数据算 500 字节，写入带宽约 275 MB 每秒——单台 RegionServer 的顺序写能力在几百 MB 每秒量级，理论上一台就能扛。但现实要留余量：WAL 与 HFile 双写、三副本放大、Compaction 的重写流量，实际按四到五倍放，那就要 4 台左右才稳。

第二笔，存储总量。 3000 亿行乘 500 字节是 150 TB 净数据，压缩后按一半算 75 TB，三副本再乘三，落盘 225 TB。按单机 8 块 8 TB 盘、可用水约七成算，单机可存 45 TB，需要 5 台起。加上 HDFS 的管理开销与增长空间，8 台是合理起点。

第三笔，读的落点数。 55 万行每秒的写入如果 RowKey 分布均匀，会平摊到几十上百个 Region 上；一个"查某用户最近通话"的请求只落一个 Region，单台 RegionServer 轻松承载数万点查每秒。这是 HBase 的账能算得动的前提——RowKey 分布均匀。若 RowKey 是递增时间戳，同样 55 万写入会全部挤进最后一个 Region，一台机器被打满，其余全部闲置。落点分布决定集群利用率，这句话贯穿全册。

第四笔，人的成本。 HBase 依赖 HDFS 与 ZooKeeper，最小生产规模通常 10 台上下，需要专人懂 Compaction 调优、Region 治理、故障恢复。团队没有这个储备时，云上的托管 HBase 或直接用 Cassandra 这类自治性更强的系统，往往总成本更低。

四笔账算完，选型就从"感觉数据量大"变成"需要 N 台机器、M 个 Region、RowKey 能否打散"的判断题。HBase 适不适合，答案从来不在 HBase 本身，而在你的数据形状与读写模式里。

从 Bigtable 到 HBase 的三行历史

HBase 不是凭空发明。2007 年 PowerSet 公司受 Google 2006 年 Bigtable 论文启发启动开源实现，2008 年进入 Apache 孵化器，2010 年成为顶级项目，此后长期是 Facebook 消息系统、阿里淘宝画像这类超大规模系统的底座。理解这条脉络有助于把握 HBase 的定位：它就是开源世界的 Bigtable，把"行键排序 + 列族 + LSM"三件套工程化，并嫁接到 Hadoop 存储层上。后来 Facebook 又基于同样的思想造了 RocksDB/Scylla 系的变种，阿里在 HBase 之上发展出 Lindorm——LSM 这条技术路线的统治力，比 HBase 本身更持久。

本节要点回顾

• 空档定位：HBase 填补"PB 级数据量 + 毫秒级随机读写"，MySQL 管不了量，HDFS 管不了随机读；
• 三个结构性决定：RowKey 字典序组织、LSM 顺序写、复用 HDFS 存储，每个都伴随明确代价；
• 没有的东西：SQL、二级索引、跨行事务，选型前先确认业务真的不需要；
• 量级门槛：千万行以下用 HBase 通常得不偿失，别为了技术而技术；
• 暗线提醒：本册反复追问"一行数据落在哪"，答案的第一块拼图就是 RowKey 字典序——下一节把它拆开看。

下一节我们把镜头拉近，看这行数据在逻辑上到底长什么样：一个行键、几个列族、无数个带时间戳的单元格。