Hbase倾斜优化实践

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 读流程

1. Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。( #zk get /hbase/meta-region-server)

   hbase:meta : 存储了 Hbase 集群中全部表的所有的 region 信息，且放在一个 region server 中。

2. 访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta