我们数据组通过三周的努力，整个集群都变成了可压缩各种模式。
具体操作：
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在实际运行压缩模式中出现的问题》