1. HBase概述：HBase的起源与历史、HBase与传统关系型数据库对比、HBase在大数据生态中的定位

1.1 HBase的起源：从Google BigTable说起

说起HBase，得先聊聊Google那篇著名的BigTable论文。2006年，Google发表了《BigTable: A Distributed Storage System for Structured Data》。这篇论文，说白了就是告诉全世界——我们怎么在几千台服务器上存PB级的数据。

我当时刚入行，读到这篇论文时，第一反应是：这玩意儿能落地吗？后来Apache社区用Java把它实现了，这就是HBase的雏形。2007年，HBase作为Hadoop的子项目诞生。我记得那会儿HBase还叫"Hadoop Database"，名字挺直白的。

为什么会诞生HBase？因为传统数据库搞不定海量数据了。你想想看，一个电商平台每天产生几十亿条用户行为日志，MySQL怎么扛？分库分表？太痛苦了。HBase就是为解决这类问题而生的。

1.2 HBase与传统关系型数据库的对比

很多刚接触HBase的朋友会问：它和MySQL有什么区别？我一般这么回答：MySQL是存钱的保险柜，HBase是装杂货的仓库。

咱们直接看对比表：

对比维度	传统关系型数据库（如MySQL）	HBase
数据模型	行式存储，固定Schema	列式存储，动态Schema
扩展性	垂直扩展为主，水平扩展困难	天然水平扩展，加机器就行
事务支持	ACID事务，强一致性	仅支持单行事务，最终一致性
查询方式	SQL，支持复杂Join、聚合	API方式，仅支持简单查询
存储容量	GB~TB级别	PB级别起步
读写性能	读写均衡，延迟低	写性能极强，读性能一般
典型场景	OLTP、财务系统、用户中心	日志存储、时序数据、推荐系统

嗯，这里要注意：HBase不是用来替代MySQL的。我在项目中遇到过不少团队，想把所有业务都搬到HBase上，结果搞得很痛苦。HBase擅长的是海量数据的写入和简单查询，而不是复杂的事务处理。

1.3 HBase在大数据生态中的定位

HBase在整个大数据生态里，扮演什么角色？我习惯把它比作「实时数据的中转站」。

来看这张定位图：

• 底层存储层：HDFS（Hadoop分布式文件系统）——存原始数据
• 中间层：HBase——提供随机读写能力
• 上层计算层：MapReduce、Spark、Flink——做批量或实时计算
• 查询层：Phoenix、Presto——提供SQL接口

说白了，HBase填补了HDFS不能随机读写的空白。HDFS只能追加写，不能修改。但HBase可以。你想想看，如果用户要修改三天前的订单状态，HDFS做不到，HBase可以。

我曾经在一个物联网项目中，用HBase存储设备上报的实时数据。每天几十亿条记录，写入延迟控制在毫秒级。查询时按设备ID和时间戳范围扫描，响应时间在100毫秒以内。换成MySQL？想都不敢想。

1.4 什么时候该用HBase？

我总结了几个典型场景：

1. 海量数据写入：比如用户行为日志、监控数据、IoT传感器数据
2. 稀疏数据存储：比如用户画像，每个用户属性不同，用关系型数据库会浪费大量空字段
3. 需要版本控制：HBase天然支持多版本，可以回溯历史数据
4. 实时查询需求：比如订单状态查询、推荐系统特征获取

反过来，如果你的业务需要复杂Join、事务、或者数据量很小，就别折腾HBase了。我见过有人用HBase存用户登录信息，总共才几万条记录，这不是杀鸡用牛刀吗？

1.5 小结

这一章我们聊了HBase的起源、与传统数据库的对比，以及它在生态中的定位。记住一句话：HBase是为海量数据而生，为实时查询而活。

下一章，咱们会深入HBase的数据模型，聊聊RowKey、Column Family、TimeStamp这些核心概念。到时候我会分享一些实际项目中的RowKey设计经验，保证让你少踩坑。