我们数据组通过三周的努力,整个集群都变成了可压缩各种模式。
具体操作:
hbase的数据迁移,hive的数据迁移
首先说说hbase的数据迁移,数据采用了Gz的压缩模式并且rowkey进行了调整后,整个hbase集群region的分布更加合理,主要是从以下几个方面:
1、磁盘空间利用率提高了,现在压缩后,占用300多个GB的空间
2、region大小更加均衡(不会出现之前的有些region大小几个GB,有些region大小是几百MB)
3、region的request请求数更加均衡(不会出现之前的有些region请求数在几百个,有些region的请求数在几万个)
4、客户端写数据时,不会出现1-2分钟的暂停时间(之前就是因为这个暂停时间,导致写数据的吞吐量上不来)
5、每个regionserver节点的socket连接数也更加均衡
6、数据流转提升很高,现在很多数据在整体半个小时之内就可以转到hive库中
7、hbase集群运行很稳定不会出现波动(这里我是指compaction操作的频繁度)
8、在hbase集群进行只有读写操作时,各节点CPU使用率不超过20%(注:依据具体的硬件环境来测试的)
9、hbase节点日志量很小,如下图:
没压缩前,都是几百MB甚至上GB;而压缩后,日志量一天还不到2MB。
以上就是这次hbase的压缩后的体会
目前hive迁移正在进行中,目前有以下几个方面:
1、数据源压缩,测试下来发现Gz比bz的效果好(因为bz占用CPU较高)
2、采用了rcfile,结合gz、snappy、lzo的各种压缩模式,提升了计算效率
目前还需要继续观察其稳定性,后续将对此进行完善。
详细参考另一篇问题描述的blog。
后面说下在hbase和hive使用压缩后,带来的问题:
1、就是CPU消耗很大,最初的一两天regionserver经常自动退出(目前我们hbase与hive是共享HDFS的,最终检查下来是当前资源已经达到了最大,需要进行调整)
2、参考另一篇blog《hive在实际运行压缩模式中出现的问题》