这是我参与「第四届青训营」笔记创作活动的第11天。
知识点小记
采用存储计算分离架构
- 存储层基于HDFS存储数据，提供容错机制和高可靠性
- 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力
HBase和传统的关系型数据库的区别
| 标题 | HBase | Relational DB |
|---|---|---|
| 数据结构 | 半结构化，无数据类型，按列族稀疏存储，缺省数据不占用存储空间；支持多版本数据 | 结构化，数据类型丰富，按完整行存储，缺省的列需要存储占位符，不支持多版本数据 |
| 读写模式 | 支持按需读写部分列 | 必须整行读取 |
| 事务支持 | 仅支持单行内原子性 | 支持完整的事务语义 |
| 数据规模 | 适用于TB、PB级的海量数据水平扩展快速平滑 | 仅适用GB、小量TB级，扩展过程较复杂 |
| 索引支持 | 仅支持rowkey主键索引 | 支持二级索引 |
HBase数据模型
逻辑结构
| 概念名称 | 概念用途 |
|---|---|
| 行键 | 用于唯一索引一行数据的主键，以字典序组织，一行可以包含多个列族 |
| 列族 | 用于组织一系列列名，一个列族可以包含任意多个列名，每个列族的数据物理上互相独立存储，以支持按列读取部分数据 |
| 列名 | 用于定义到一个具体的列，一个列族可以包含多个版本的数据，不需要预先定义列名，以支持半个结构化的数据模型 |
| 版本号 | 用于标识一个列内多个不同版本的数据，每个版本号对应一个值 |
| 值 | 存储的一个具体的值 |
HBase以列族为单位存储数据，以行键索引数据，列族需要在使用前预先创建，列名需要预先声明。HBase通过行键、列族、列名、版本号来定位到一个具体的数据。
物理结构
- 物理结构的最小单元 —— KeyValue结构
- 每个版本的数据都会携带全部的行列信息，会产生数据冗余
- 同一行、同一列族的数据物理上连续有序存储
- 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序
- 同列族下不同物理文件不保证数据全局有序
- 仅单个物理文件内有序
HBase数据模型的优缺点
| 优点 | 缺点 |
|---|---|
| 稀疏表友好，不存储缺省列，支持动态新增列类型 | 每条数据都要冗余存储行列信息 |
| 支持保存多版本数据 | 不支持二级索引，只能通过rowkey索引，查询效率以来rowkey设计 |
| 支持只读部分column family的数据，避免读取不必要的数据 | column family数量较多时可能引发性能衰退 |
| 支持的数据规模相比传统数据库更高，更易水平扩展 | 不支持数据类型，一律按字节数组存储 |
| 支持rowkey字典序批量扫描数据 | 仅支持单行内的原子性操作，无跨行事务保障 |
HBase架构设计
主要组件：
- HMaster：元数据的管理，集群调度、保活
- RegionServer：提供数据读写服务，每个实例负责若干个互不重叠的rowkey区间内的数据
- ThriftServer：提供Thrift API读写的代理层
依赖组件：
- Zookeeper：分布式一致性共识协作管理，例如HMaster选主、任务分发、元数据变更管理等
- HDFS：分布式文件系统，HBase数据存储底座。
各组件职责
HMaster
- 管理RegionServer实例生命周期，保证服务可用性
- 协调RegionServer数据故障恢复，保证数据正确性
- 集中管理集群元数据，执行负载均衡等维护集群稳定性
- 定期巡查元数据，调整数据分布，清理废气数据等
- 处理用户主动发起的元数据操作如建表、删表等
RegionServer
- 提供部分rowkey区间数据的读写服务
- 如果负责meta表，向客户端SDK提供rowkey位置信息
- 认领HMaster发布的故障恢复任务，帮助加速数据恢复过程
- 处理HMaster下达的元数据操作，如region的打开/关闭/分裂/合并操作等。
Zookeeper
- HMaster登记信息，对active/backup分工达成共识
- RegionServer登记信息，失联时HMaster保活处理
- 登记meta表位置信息，供SDK查询读写位置信息
- 供HMaster和RegionServer写作处理分布式任务
