HBase它是一个非常强大且流行的分布式 NoSQL 数据库。
一、HBase 是什么?
HBase 的全称是 Hadoop Database,顾名思义,它是一个建立在 Hadoop 生态体系之上的数据库。其核心设计思想来源于 Google 的 Bigtable 论文。
你可以把它理解为:
- 一个开源的、分布式的、面向列的、可扩展的 NoSQL 数据库。
- 它被设计用来在海量数据上提供随机、实时的读写访问。
- 它本身不擅长复杂的分析计算(那是 MapReduce/Spark 的工作),但它擅长作为海量数据的“输入源”和“输出源”。
二、核心特性
-
海量存储 (Massive Storage)
- 得益于建立在 HDFS 之上,HBase 可以轻松处理包含数十亿行、数百万列的庞大数据集,容量可达 PB 级别。这是传统关系型数据库无法想象的。
-
面向列 (Column-Oriented)
- 注意:HBase 是“面向列”的,但它不是纯粹的列式存储(如 Parquet, ORC)。它更像是“列族”存储。
- 它将数据按列族分组,同一个列族下的所有列存储在一起。这种结构非常适合存储稀疏数据(即很多行为空的数据)。
-
高可靠性 (High Reliability)
- 数据自动通过 HDFS 进行多副本冗余存储,硬件故障是常态而非异常,但 HBase 能自动处理 RegionServer 的故障转移。
-
高性能随机读写 (High Performance)
- 通过使用 LSM树 和 内存缓存 机制,HBase 在写入方面性能极高。
- 通过布隆过滤器和块缓存,它在点查询(根据键查数据)方面也非常快。
-
强一致性 (Strong Consistency)
- 在一个 Region 内,所有的读写操作都是强一致的。你读到的数据一定是最近一次成功写入的数据。
-
可扩展性 (High Scalability)
- 扩展极其方便,可以通过简单地添加新的 RegionServer 节点来线性提升集群的存储能力和处理能力,整个过程对业务应用透明。
三、核心概念与数据模型
理解 HBase 的关键在于理解其多维度的数据模型,它不像关系型数据库是简单的“表+行+列”。
| 概念 | 解释 | 类比 |
|---|---|---|
| 表 (Table) | 存储数据的集合。 | 一张 Excel sheet。 |
| 行键 (Row Key) | 唯一标识一行数据的主键。所有行按照行键的字典序排序。设计好坏直接决定性能。 | Excel 中的行号,但它是有业务意义的字符串(如 userid_timestamp)。 |
| 列族 (Column Family) | 一个物理存储分组。一个表下有多个列族,每个列族下的所有列存储在一起。这是调优和权限控制的最小单位。 | 在 Excel 里,你可以把“基本信息”列(姓名、年龄)和“交易信息”列(订单、金额)分成两个组。 |
| 列限定符 (Column Qualifier) | 列族下的具体列,可以动态添加。列族 + 列限定符才能唯一确定一列,如 info:name,info:age。 | “基本信息”组下的“姓名”列、“年龄”列。 |
| 单元格 (Cell) | 存储数据的基本单位。由 {Row Key, Column Family: Column Qualifier, Version} 唯一确定。 | 某个单元格里的具体值。 |
| 时间戳 (Timestamp) | 每个单元格的值都可以有多个版本,版本号默认由时间戳指定。HBase 会自动保留指定版本数量的数据。 | 类似于 Git 的每次提交记录,你可以查到历史值。 |
一个经典的数据视图示例:
| Row Key | Column Family cf1 | Column Family cf2 |
|---|---|---|
Column name | Column age | |
| rowkey1 | value1 (t3) | value2 (t3) |
value1_old (t1) | ||
| rowkey2 | value3 (t4) | value4 (t4) |
| rowkey3 |
- 从这可以看出稀疏性:
rowkey3在cf1列族下没有数据,但这不会占用存储空间。 rowkey1的cf1:name有两个版本,时间戳为 t1 和 t3。
四、架构与工作原理
HBase 采用主从架构:
-
HMaster:
- 管理角色,负责表的增删改、RegionServer 的负载均衡、Region 的分配和故障转移。
- 它本身不是数据读写路径的一部分,因此即使 HMaster 短暂宕机,集群依然可以正常进行读写(但无法做管理操作),实现了高可用。
-
RegionServer:
- 负责数据读写请求的工作节点,一个 RegionServer 负责管理多个 Region。
- 客户端直接与 RegionServer 通信。
-
Region:
- 表的分片。一张大表会按行键范围水平拆分成多个 Region,分布在不同 RegionServer 上。这就是 HBase 能扩展的秘密。
- 当一个 Region 变得太大时,会自动分裂 (Split) 成两个新的 Region。
-
Store:
- 一个 Region 由一个或多个 Store 组成,一个 Store 对应一个列族。
-
MemStore 与 HFile:
- MemStore: 写在内存里。数据写入时,首先会写入到 MemStore 和 Write-Ahead-Log (WAL) 中(用于故障恢复)。
- HFile: 存储在 HDFS 上。当 MemStore 填满后,会异步刷新(Flush)到 HDFS 上形成一个不可变的存储文件 HFile。
- 这种 LSM树 结构是 HBase 高写入吞吐量的根源。
-
ZooKeeper:
- 集群的“协调者”。负责维护元数据(如哪个 RegionServer 管理哪个 Region)、监控 RegionServer 状态并通知 HMaster,以及选举主 HMaster。
五、应用场景
HBase 非常适合以下场景:
- 大数据领域的随机读写访问:需要在海量数据中通过 Key 快速查询到 Value(如用户画像查询)。
- 实时数据平台:作为 Kafka 等消息队列的消费者,实时写入数据,并供应用程序实时查询。例如,用户点击流实时写入,然后实时查询用户最新行为。
- 增量数据存储:存储不断增长的时序数据,如物联网传感器数据、监控日志、App 实时报表。
- 作为查询引擎的底层存储:为 Phoenix(提供 SQL 层)、OpenTSDB(时序数据库)等提供底层存储支持。
六、不适合的场景
- 传统事务型应用:不支持跨行跨表事务,只有单行事务。
- 复杂的多表关联查询:没有原生的 SQL JOIN,需要通过在客户端代码中实现或在上层用 Phoenix。
- 纯分析型扫描:全表扫描性能远不如 MapReduce/Spark 直接读取 HDFS 上的列式文件(如 Parquet)。
- 需要大量聚合计算:如 SUM, AVG 等,最好交给上层计算框架(如 Spark)来处理。
总结
HBase 是 Hadoop 生态中填补大规模实时读写空白的关键组件。它牺牲了关系型数据库的复杂功能(如JOIN、事务),换来了在海量数据下的线性扩展和高性能随机访问能力。它是构建大型互联网公司后台数据服务的基石技术之一。

966

被折叠的 条评论
为什么被折叠?



