hbase宽表和高表以及优缺点

阳光穿透心脏的1/2处 2022-11-01 13:42 170阅读 0赞

### hbase宽表和高表以及优缺点 ###

*  hbase的row key是分布式的索引，也是分片的依据。
 *  在HBase中使用宽表、高表的优劣总结如下：
 *   *  查询性能
     *  分片能力
     *  元数据开销
     *  事务能力
     *  数据压缩比
     *  小结
 *  宽表总结
 *   *  一 宽表的优点
     *   *  大量使用宽表究竟给我们带来了什么好处？
     *  二 宽表的不便
     *  三 如何优雅的使用宽表

hbase中的:

*  宽表：是指很多列较少行，即列多行少，一行中的数据量较大，行数少；
 *  高表：是指很多行较少列，即行多列少，一行中的数据量较少，行数大。

# hbase的row key是分布式的索引，也是分片的依据。 #

hbase 的 `row key + column family + column qualifier + timestamp + value` 是HFile中数据排列依据。

HFile据此，对数据的索引到data block级别，而不是行级别。所以这种key是HFile内部的粗粒度（data block粒度）本地索引的主键。

# 在HBase中使用宽表、高表的优劣总结如下： #

## 查询性能 ##

高表更好，因为查询条件都在row key中, 是全局分布式索引的一部分。高表一行中的数据较少。所以查询缓存BlockCache能缓存更多的行，以行数为单位的吞吐量会更高。

## 分片能力 ##

高表分片粒度更细，各个分片的大小更均衡。因为高表一行的数据较少，宽表一行的数据较多。HBase按行来分片。

## 元数据开销 ##

高表元数据开销更大。高表行多，row key多，可能造成region数量也多，- root -、 .meta表数据量更大。过大的元数据开销，可能引起HBase集群的不稳定、master更大的负担（这方面后续再好好总结）。

## 事务能力 ##

宽表事务性更好。HBase对一行的写入（Put）是有事务原子性的，一行的所有列要么全部写入成功，要么全部没有写入。但是多行的更新之间没有事务性保证。

## 数据压缩比 ##

如果我们对一行内的数据进行压缩，宽表能获得更高的压缩比。因为宽表中，一行的数据量较大，往往存在更多相似的二进制字节，有利于提高压缩比。通过压缩，缓解了宽表一行数据量太大，并导致分片大小不均匀的问题。查询时，我们根据row key找到压缩后的数据，进行解压缩。而且解压缩可以通过协处理器（coproesssor）在HBase服务器上做，而不是在业务应用的服务器上做，以充分应用HBase集群的CPU能力。

## 小结 ##

设计表时，可以不绝对追求高表、宽表，而是在两者之间做好平衡。

根据查询模式，需要分布式索引、分片、有很高选择度（即能据此查询条件迅速锁定很小范围的一些行）的查询用字段，应该放入row key；能够均匀地划分数据字节数的字段，也应该放入row key，作为分片的依据。选择度较低，并且不需要作为分片依据的查询用字段，放入column family和column qualifier，不放入row key。

# 宽表总结 #

## 一 宽表的优点 ##

宽表浅意上的好处

在当前这个项目中，大量使用了宽表，字段超过一百五十个字段的宽表有五张，分别是客户机构级信息表、客户客户经理级信息表、客户经理信息表、集团客户信息表、战略客户信息表。

从上面的表名中可以猜到，这是个CRM项目，我这里能列举出来的优点也是在项目中体现出来的优点。

### 大量使用宽表究竟给我们带来了什么好处？ ###

*  窥一表知全貌
 *  查询速度快（此处我一直保留疑问）

窥一表知全貌：这个好处很明显，尤其是收到报表开发人员的欢迎，他们不关心数据如何存储，只关心这张报表是不是很方便，很快的能开发出来。还有一个就是数据分析人员，银行业大部分数据分析人员很讨厌做表关联，他们喜欢一条记录看到客户的全貌。

查询速度快：大多数情况确实如此，大部分SQL慢都是由于表关联造成的，所以大家都在思考不关联出结果。于是，出现了将一些常用的信息都做成了大宽表。

## 二 宽表的不便 ##

从ETL角度讲，使用宽表带给我的痛苦远远大于它带来的快乐，从系统出发解释宽表带来的问题。

项目是一个CRM系统，以仓库数据（TD）为基础，进行建模、数据加工，作为仓库的一个集市落地后，在将这部分数据，同步到查询服务器（DB2）上，每日从TD到DB2的数据量约为16G，同步数据的方式为TD导出数据生成txt，上传到FTP服务器后在通过SHELL加载到DB2。