Hbase的MOB以及部分调优

Hbase的MOB特性
改善了对中等大小值的低延迟读写（基理想状态为100k到10M），这使得可以更好的存储文本，图片和一些其他的中等对象，Hbase特性通过将引用文件和MOB对象的IO路径分离来实现这一改进。对MOB使用不同的压缩策略并因此减少了因为Hbase压缩所导致的写放大的问题。若一个表的MOB文件存储在MOB区域（MOB region）中，则意味着该区域中将大量的MOB文件

虚拟脱机region

create 't1', {NAME => 'f1', IS_MOB => true, MOB_THRESHOLD => 1000000, MOB_COMPACT_PARTITION_POLICY => 'weekly’}

alter 't1', {NAME => 'f1', MOB_COMPACT_PARTITION_POLICY => 'monthly'}

写性能优化切入点
1.是否需要写WAL？WAL是否需要同步写入？
     优化原理：数据写入流程可以理解为一次顺序写WAL+一次写缓存，通常情况下写缓存延迟很低，因此提升写性能就只能从WAL入手。WAL机制一方面是为了确保数据即使丢失也可以恢复，另一方面是为了集群之间异步复制。默认WAL机制开启且使用同分机制写入WAL。首先考虑业务是否需要写WAL，通常情况下大多数业务都会开启WAL机制（默认），但是对于部分业务可能并不特别关心异常情况下部分数据丢失，而更关心数据写入吞吐量，比如某些推荐业务，这类业务即使丢失一部分用户行为数据可能对推荐结构并不构成很大影响，但是对写入吞吐量要求很高，不能造成 数据队列阻塞。这种场景下可以考虑关闭WAL写入，写入吞吐量可以提升2x~3x。退而求其次，有些业务不能接受不写WAL，但可以接受WAL异步写入，也是可以考虑优化的，通常也会带来1x～2x的性能提升。
2.Put是否可以同步批量提交 
     优化原理：HBase分别提供了单条put以及批量put的API接口，使用批量put接口可以减少客户端到RegionServer之间的RPC连接数，提高写入性能。另外需要注意的是，批量put请求要么全部成功返回，要么抛出异常。
3.Put是否可以异步批量提交
     优化原理：业务如果可以接受异常情况下少量数据丢失的话，还可以使用异步批量提交的方式提交请求。提交分为两阶段执行：用户提交写请求之后，数据会写入客户端缓存，并返回用户写入成功；当客户端缓存达到阈值（默认2M）之后批量提交给RegionServer。需要注意的是，在某些情况下客户端异常的情况下缓存数据有可能丢失。
     使用方式：setAutoFlush(false) 
4.Region是否太少
     优化原理：当前集群中表的Region个数如果小于RegionServer个数，即Num(Region of Table) < Num(RegionServer)，可以考虑切分Region并尽可能分布到不同RegionServer来提高系统请求并发度，如果Num(Region of Table) > Num(RegionServer)，再增加Region个数效果并不明显。
     优化建议：在Num(Region of Table) < Num(RegionServer)的场景下切分部分请求负载高的Region并迁移到其他RegionServer
5. 写入请求是否不均衡？
     优化原理：另一个需要考虑的问题是写入请求是否均衡，如果不均衡，一方面会导致系统并发度较低，另一方面也有可能造成部分节点负载很高，进而影响其他业务。分布式系统中特别害怕一个节点负载很高的情况，一个节点负载很高可能会拖慢整个集群，这是因为很多业务会使用Mutli批量提交读写请求，一旦其中一部分请求落到该节点无法得到及时响应，就会导致整个批量请求超时。因此不怕节点宕掉，就怕节点奄奄一息！
     优化建议：检查RowKey设计以及预分区策略，保证写入请求均衡。
6. 写入KeyValue数据是否太大？
     KeyValue大小对写入性能的影响巨大，一旦遇到写入性能比较差的情况，需要考虑是否由于写入KeyValue数据太大导致。