Hhase优化之降低IO

1：Hbase表如何设计

1.1：
优化手段：适当增加列簇个数，一起读写的列放在一个列簇。
优化原理：family多，获取单个cell数据时就不会去扫描同一rowkey的所有数据（按列簇存储），明显降低IO。
使用场景：
a、读多写少（family反而增加写的开销，甚至带来过多的split）；
b、经常是某些字段一起读（有规律的）；
c、内存充裕，每个region的每个family对应一个store，每个store对应一个memestore；
注意事项：
a、family不要超过3个；
b、如果读少写多，反而整体上增加了IO；
c、一般建议单列族，除非IO确实成为瓶颈；

1.2：
优化手段：预建分区。
优化原理：一定要预建分区，可以分散IO压力，同时各节点存储也是均匀的，否则一旦形成热点，会影响读写，甚至还要回来迁移存储的数据，造成更多的IO和网络开销。
使用场景：一般都可以。
注意事项：分散IO，起到局部降低IO的作用。
预分区计算：
region(500)个数=数据总量(3520G)/region大小(7G)
region最大：10-20G
region最优值：5-10G

1.3：
优化手段：合理规划Hfile大小，减少split。
优化原理：频繁split会带来额外开销，所以Hfile的maxsize应该根据数据规模来预估，使其尽量不分裂。
使用场景：一般都可以。

1.4：
优化手段：maxversion设置为1。
优化原理：保存一个版本减少存储，可缓解IO。
使用场景：不需要保存多个版本且存在重复写入的场景。
注意事项：仅能缓解IO。

1.5：
优化手段：高宽表结合。
优化原理：对于随时间变化的指标数据可采用宽表，以时间段作为列名；避免太宽导致导致单条数据过大，可以高宽表结合，比如以30分钟为一个时间段，每天子在单起一行记录。
使用场景：时间线查询。
注意事项：对于时间线查询的场景可降低IO。

2：Hbase rowkey设计
1.1:
优化手段：将（Long.MAX_VALUE-timestamp）加到rowkey。
优化原理：若最近写入Hbase的数据可能被访问，可以考虑将z间戳作为rowkey的一部分；由于字典排序，所以可以使用Long.MAX_VALUE - timestamp作为rowkey。这样能保证写入的数据在读取时可以被快速命中。
使用场景：最近写如最可能被访问。
注意事项：缓解IO。

3：读写操作
1.1：
优化手段：使用写缓存（以字节为单位）。
优化原理：较少写入次数。
使用场景：
注意事项：较少网络和磁盘IO。

1.2：
优化手段：批量读写（put(list))。
优化原理：只有一次IO开销。
使用场景：实时性要求高，网络和IO压力大。
注意事项：降低IO。

1.3：
优化手段：使用第三方缓存。
优化原理：数据经常被读取，比如半小时内的数据，加上缓存，可减少磁盘读写。
使用场景：可容忍部分数据差异。
注意事项：降低IO开销；采用合理的淘汰算法设置是TTL；redis的多种淘汰策略+TTL。

1.4：
优化手段：bulkload入库。
优化原理：基于mr思想，直接生成Hbase底层的数据文件，不写wal，降低大量IO，几乎不影响读。
使用场景：a、适合入库实时性要求不高；b、IO很紧张。
注意事项：

1.5：
优化手段：使用堆外内存做二级缓存（blockcache）。
优化原理：以额外内存开销换取IO的下降。
使用场景：热数据不容易被淘汰，命中率变高。
注意事项：采用LRU淘汰。

1.6：
优化手段：适当放宽flush门栏。
优化原理：写数据先写入memstore，超过大小才flush到磁盘，可以把阈值适当放大，使刚写入的数据在内存待一会，增大缓存命中率，同时降低写磁盘的次数。
使用场景：a、刚写入的数据读取频繁；b、内存不是瓶颈。
注意事项：阈值不能太大，否则flush比较慢，hbase.regionserver.global.memstore.upperLimit。

1.7：
优化手段：关闭WAL(慎用)。
优化原理：写入时关闭wal，可以省下IO开销。
使用场景：允许丢失少量数据。
注意事项：不建议使用。

4：数据角度
1.1：
优化手段：忙时关闭major compact，闲时打开major compact。
优化原理：一般业务场景都有忙闲，可能在凌晨读写压力很小，故可能把major compact放到闲时去做，以缓解忙时IO。
使用场景：业务有忙闲时。
注意事项：只是缓解忙时IO，把压力转移到闲时。

1.2：
优化手段：合理使用压缩算法(文件级别)。
优化原理：gzip压缩可以降低存储需求，缓解IO压力。
使用场景：CPU没有压力，IO压力很大。
注意事项：会带来额外的CPU开销，一般推荐snappy，IO特别紧张用gzip。

1.3：
优化手段：使用PrefixTreeCompression(前缀压缩)。
优化原理：hbase的KeyValue存储时按照Row/Family/Qualifier/TimeStamp/Value的形式存储的，Row/Family/Qualifier这些相当于前缀。如果每一行都按照原始数据进行存储会导致存储空间比较大。
使用场景：
注意事项：对IO有缓解作用。

1.4：
优化手段：使用Bloomfilter。
优化原理：对于某个region的随机读写，hbase会遍历读memstore及storefile(按照一定顺序），将结果合并返回给客户端。如果设置了bloomfilter，那么在遍历读storefile时，就可以利用bloomfilter，忽略某些storefile。
使用场景：建议使用。
注意事项：Bloomfilter是一个列簇（cf）级别的配置属性，如果在表中设置了Bloomfilter，那么hbase会在生成storefile时包含一份bloomfilter结构的数据，称其为MetaBlock。MetaBlock与DataBlock(真实的KeyValue数据)一起由LRUBlockCache维护。所以，开启bloomfilter会有一定的存储及内存cache开销。