Hbase写倾斜排查
1、引言
Hbase 作为一个分布式的、多版本的开源 KV 数据库,面对大数据也能提供随机的、实时的读写性能。那么,性能如此强大的 Hbase,内部的数据存储结构是怎样设计的呐?基于其存储结构,其读写过程又是怎样的呐?难道 Hbase 就没有弊端了吗?在实践中我们如何去应用 Hbase?接下来我们将一步一步揭开这些问题的面纱。
2、存储结构
Hbase 的存储结构将从两个不同的角度进行阐述:逻辑存储结构、物理存储结构。
2.1、逻辑存储结构
Hbase 的逻辑存储相关概念如下 :
概念名词 | Hbase |
---|---|
Table | 包含多个 Row 的数据表 |
Row | 一个 Row 由 rowKey 与多个 column 值组成 |
Column | 由 Column Family 和 Column Qualifier 确定唯一一列 |
Column Family | 一个 Column Family 似于一个集合,下面有多个 Row |
Column Qualifier | 添加到 Column Family 中用来作为 Column 的索引 |
Cell | row、column family、column qualifier的组合,包含值和表示值版本的时间戳。 |
Timestamp | 表示值版本的时间戳 |
以上概念之间的关系可以用下面几张图表示:
2.2、物理存储结构
Hbase 的每个表包含的行数量非常庞大,无法在一台机器上存储,都会按照 rowKey 划分为多个 region,一般划分的时候都会根据当前集群资源设置分区数量,做到一个宿主机包含每个表中的一个 region。其中每个 region 由有一个或多个 store 文件组成(一个 store 对应一个 column family)。其具体结构下图所示:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3eIk1N1H-1663676223633)(https://s3-us-west-2.amazonaws.com/secure.notion-static.com/251a33d2-4845-4724-92c2-71b8321b86b5/%E6%9C%AA%E5%91%BD%E5%90%8D%E6%96%87%E4%BB%B6.png)]
3、Hbase 的读写流程
3.1、Hbase 关键进程
HBase 作为一个 Master/Slave 架构的分布式数据库,内部主要有 Master, RegionServer 两个核心服务,依赖 HDFS 做底层存储,依赖 zookeeper 做一致性等协调工作。
- Master 是一个轻量级进程,负责所有 DDL 操作,负载均衡, region 信息管理,并在宕机恢复中起主导作用。
- RegionServer 管理 HRegion,与客户端点对点通信,负责实时数据的读写,。
- zookeeper 做 HMaster 选举,关键信息如 meta-region 地址,replication 进度,RegionServer 地址与端口等存储。
3.2、Hbase 读流程
-
Client 先访问 zookeeper,获取 hbase:meta 表位于哪个 Region Server。( #zk get /hbase/meta-region-server)
hbase:meta : 存储了 Hbase 集群中全部表的所有的 region 信息,且放在一个 region server 中。
-
访问对应的 Region Server,获取 hbase:meta 表,根据读请求的 namespace:table/rowkey,查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta