1、上面的2张图主要说明hbase的存储特点
(1)、每个值（每条记录的每一个列的值）的存储，都完整的存储了rowkey、column family、column、版本(时间戳)，以及该列的值。
这样其实很浪费存储空间。对应的最直接的存储优化方案就是缩短rowkey、column family、column、版本(时间戳)的长度。在建表的时候就把这几项设置的极其短。
(2)、hbase是列式存储，天生就适合进行压缩等优化。
(3)、也可以通过（合并多个记录为一条记录）减少rowkey来减少表的记录数，达到减少key查找的效果，从而提升查询性能。代价就是每次查询的结果需要解析拆开，并且读取的对象比原来的单个记录要大。
2、hbase的存储优化的方案选择：压缩还是编码
(1)、参照这篇文章，对比了hbase编码和压缩2种优化方案的优缺点
A、REFIX_TREE编码方式不仅能起到压缩的效果
B、而且比较省CPU和内存。
http://blog.csdn.net/javastart/article/details/51820212
(2)、下面这篇文章，列出了PREFIX_TREE编码方式的优点：
A、REFIX_TREE提升从DataBlock中查找数据的效率。
B、省内存和cpu。
http://zjushch.iteye.com/blog/1843793
3、具体的优化命令
==========hbase命令================================================
disable 'logs:radwa'
alter 'logs:radwa', NAME => 'info', DATA_BLOCK_ENCODING => 'PREFIX_TREE' #修改编码（此编码效果最好）
#alter 'logs:radwa', NAME => 'info', COMPRESSION => 'snappy' #修改压缩
enable 'logs:radwa' #enable表后压缩还不会生效, 需要立即生效
major_compact 'logs:radwa' #这个命令执行的时间会相当长, 会对整个集群的CPU, IO有大量的占用
==========hbase命令================================================
4、优化效果
线上实测500G的表，编码后变为140G，效果还是不错的。
至于查询效率的提升，我并没有测试。理论上是应该有提升的，当然您需要根据自己的业务实际选择自己的优化方式。
这里任然有巨大的优化空间，比如把rowkey等设置的比较短，也可以省下很多存储空间。