【Hbase优化_2】Hbase存储优化：Hbase数据压缩

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/hbase-data-compress.html

背景

接: 【Hbase优化_1】HBase 行键设计优化：解决数据倾斜问题

随着业务扩张，Hbase使用率越来越高，大数据那边反馈已经没有资源了，全公司都没有了，要扩资源得等公司出去采购，可以的话问我们能否看能不能优化一下Hbase存储，减少一下空间占用。
基于SISP巴枪数据使用业务场景，每行数据是整体从HBase中查询出来，不存在通过字段过滤查询数据、以及只查询某些字段的使用场景，都是将整条数据拿出来、或者整个运单的所有巴枪数据拿出来解析

方案

在可以放弃根据字段过滤的前提下，可以整行巴枪数据序列化存储到HBase。在查询数据时，再将数据做反序列化。序列化可以大幅减少空间占用。以下数据基于本地测试，使用 protobuf 方式进行序列化.
同时，对于历史数据集群，因为其存储为多列数据，因为不需要根据字段过滤，把字段合并为一列，减少列数，也进一步减少空间占用。

预计效果

基于当前实时和历史两个HBASE集群占用的空间大小，可以大致计算出序列化后所需要的 region 数量
（ 超过10g就算大的region 查询会慢些，region超过20g会自动分裂 。每台机器region不要超过500，超过500就会影响性能。 ）

当前集群情况

集群	当前集群占用	当前机器数量	当前集群region数量
实时数据集群	83692GB	18台	20762
历史数据集群	527976GB	32台	24845

预计优化后集群情况

集群	当前集群占用	当前机器数量	当前集群region数量
实时数据集群	36825GB(原来的44%)	18台	1800
历史数据集群	58078GB(原来的11%)	32台	2900

切换方案

生产上分为实时库与历史库，分别存3+1个月与1年。因为实施方案一样，这里只介绍实时库：

• 上线后3+1个月内读取方式不变，写库时改为新方案双写，以新规则写入新库同时也以旧的规则写入旧库
• 等3+1个月后，读取时只读取新库，写库时只写入新库
• 以上两步做一个开关，一键切换
• 半年后，删除旧库

题外话

这里最后因为使用了数据冗余的兼容过度方案，实际上在过度期间还浪费了不少Hbase资源，好在理论优化幅度确实高，领导们能批hhhh~