说明
作用
减少数据体积，可以存储更多的数据
缺点
压缩/解压缩需要 大量计算，消耗大量CPU资源
解压缩过程
压缩
在写入数据块到 HDFS 之前会首先对数据块进行 压缩，再落盘，从而可以减少磁盘空间使用量
解压缩
在读数据的时候首先从 HDFS 中加载出 block 块之后进行 解压缩
压缩算法
hbase2.1 支持 LZO ZSTD GZ LZ4 算法
GZ（GZIP）
GZIP 压缩率最高，但是其实CPU密集型的，对CPU的消耗比其他算法要多，压缩和解压速度也慢
用于冷数据存储，要求数据访问不频繁
默认支持
LZO
LZO的压缩率居中，比GZIP要低一些，但是压缩和解压速度明显要比GZIP快很多，其中解压速度快的更多
用于热数据存储，数据访问频繁时使用
zstd
zstd是Facebook在2016年开源的新无损压缩算法，优点是 压缩率 和 压缩/解压缩 性能都很突出。
Linux内核、HTTP协议、以及一系列的大数据工具（包括Hadoop 3.0.0，HBase 2.0.0，Spark 2.3.0，Kafka 2.1.0）等都已经加入了对zstd的支持。
lz4
表存储量较小，但 qps 大，对 rt 要求极高。针对这种场景，可使用 lz4 压缩，其解压速度在部分场景下可以达到 lzo 的两倍以上。一旦读操作落盘需要解压缩，lz4 解压的rt和cpu开销都明显小于lzo压缩
默认支持
Snappy
Snappy的压缩率最低，而压缩和解压速度要稍微比LZO要快一些
用于热数据存储，数据访问频繁时使用
需要 hadoop 支持 Snappy 压缩，需要重新编译 hadoop
hbase 1.x 算法比较
是Google几年前发布的一组测试数据，来自《HBase: The Definitive Guide》
| 算法 | 压缩比 | 压缩速度 | 解压速度 |
|---|---|---|---|
| GZIP | 13.4% | 21 MB/s | 118 MB/s |
| LZO | 20.5% | 135 MB/s | 410 MB/s |
| Zippy/Snappy | 22.2% | 172 MB/s | 409 MB/s |
算法选择
Snappy的 压缩率最低，但是编解码 速率最高，对 CPU的消耗也最小，目前一般建议使用Snappy
使用 Snappy，需要 重新编译 hadoop，让hadoop 支持 Snappy 压缩
详见：hadoop3.x编译源码（centos7平台，支持snappy）
阿里提供的算法比较
https://help.aliyun.com/document_detail/59373.html
不同压缩算法在不同场景的压缩比，及解压速度对比如下，都是来自线上真实场景：
阿里建议在：
对rt要求极高，建议使用
lz4压缩算法，lz4解压缩速度最快对rt要求不高，特别是 监控、物联网等场景，建议使用
zstd压缩算法，zstd压缩率最大
rt 解释： Response-time，响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间，即从客户端发起请求到收到服务器响应结果的时间。
