本文对HBase开发及使用过程中遇到过的常见问题进行梳理总结，希望能解答新加入的HBaser们的一些疑惑。
1. HTable线程安全吗？
HTable不是线程安全的，使用过程中建议一个线程中使用一个HTable对象，不同线程间不要共享HTable对象。
同时，为了提高客户端的效率，不同的HTable对象公用同一个Configuration对象，共享HBase服务端的元数据信息，详见HBase权威指南中有关HTable部分的介绍。
2. HTablePool该如何使用？
HBase 0.90 版本以前，使用HTablePool时通过getTable方法获取HTable对象，使用完成后调用putTable方法将HTable对象放回到池中。
而HBase 0.90 以后的新版本中，使用完成后不再调用putTable方法，而是调用HTable的close方法将HTable对象放回到池中。
3. Scanner的Caching与Batch有什么区别？
caching是一次从服务端取到客户端的记录条数；而batch则是一次返回给客户端（一个Result对象中）的KeyValue的个数。
更多精彩内容：http://www.bianceng.cnhttp://www.bianceng.cn/database/extra/
举个例子：如果每行记录有5个KeyValue，而仅仅设置caching=10，假设scan表过程中表中匹配到的记录数大于10条，那么一次next()操作从服务端返回的是10个Result，每个Result含有5个KeyValue：
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
而如果同时设置batch=2，那么一次next()操作将返回17个KeyValue：
* *
* *
*
* *
* *
*
* *
* *
*
* *
4. Put(List<Put> puts)效率一定更高吗？
put(list)是用于提高吞吐量的。首先在不同region server之间是并行的；在同一个region server上的同一个region上也是并行的，而在不同region上则是串行的。
因为在同一个region server上，如果put(list)在一个region上执行，那么它是打包写一条日志的，相当于并行写入；而在不同region上执行话，它是一个for循环，而不是走线程池，所以是串行的。
5. Increment的正确性和性能靠谱吗？
目前Increment还无法做到完全的正确性，在网络出现timeout和region server发生failover的时候可能不正确，使用时需要根据应用场景慎重选择。
至于Increment的性能，性能还不错，尤其是在HBase 0.94和普通的Put写操作差别不大，能达到每台region server 7000+。
6. Region个数越多越好吗？
Region过多则影响flush效率和region server failover效率，还有就是对HDFS的压力比较大；Region过少则对读有影响，因为StoreFile数量比较多了，如果每个Region的StoreFile数量很少（线上集群一般维持在1.x~2.x个StoreFile），那么对读操作无明显影响。
写入的话，Region多少影响不大，除非Region特别少并且写压力特别大，比如一个region server只有一个Region的特殊情况。
现在HBase 0.90版本每个region server建议3000个以内Region；而HBase 0.94版本则建议在1000个以内，几百个就算很多了。
7. WAL操作日志的开销有多大？
一般情况下，向region server服务端put数据时，如果开启写WAL日志的话，服务端大概会需要1ms~2ms的开销。而如果不开启WAL日志的话，服务端只有大概0.xms的开销，基本上都是MemStore的内存操作。
另外，不管哪种情况下，对于一次put操作，都还需要加上网络传输延迟RTT开销（一般在0.5ms~1ms以内）。
8. 单表单Region的写入性能有多高？
不考虑任何优化的前提下，Java API在WAL开启的情况下每秒能达到800左右 tps，关闭WAL则能达到1000+ tps，基本上就是网络速度的上限；而Thrift接口大概有10~20%的性能损失，实际测试显示在网络RTT=0.7ms的环境下，能达到每秒550左右tps；在网络RTT=2.0ms的情况下，则只能达到350左右tps。
以上的写入性能数据，与HBase的实际写入性能相差甚远，因为没有考虑进行优化，实际应用中可以从预分region、多客户端、多线程、批量写入等方式使每个region server达到性能极限。
注意：单表单region的情况下，短时间内如果低并发写入没有问题，而如果高并发写入，则写一会之后可能会由于发生region split而导致请求被block住。
9. 单Region Server的写入性能有多高？
如果要压测单个region server的写入能力，那么可以新建一张测试表，同时预先创建多个region（例如：10~50个），然后随机生成rowkey和value写入到HBase集群进行压力测试，最终测试结果除以HBase集群内region server的个数，就可以大概得到单个region server的写入性能值了。
从HBase集群测试团队得到的结果，对于16核CPU，24GB内存的region server机器（DataNode进程分配1GB内存，HBase RegionServer进程分配16GB内存），不开WAL的话，单region server可以达到3w以上tps；开启WAL的话，一般单region server能达到9k~2w tps。而HBase的Thrift接口，可以达到Native Java API 80%~90%左右的性能。
10. Rowkey中包含时间戳导致空Region有什么问题？
假设rowkey中包含时间戳，同时设置了TTL，自动删除过期数据，那么随着时间戳值的增长，会导致过期数据已经被删除，但是空的region还存在，过多的region会影响flush效率和region server failover效率，还有就是对HDFS的压力比较大；同时由于过多空region也会占用一些元数据信息。
解决这个问题，一般有两个方法：
1）按时间周期新建不同的表：例如按天建不同的表，跨天时切换表进行读写，该方法的缺点是每天都需要建表，由于DDL事务都是master做的，只要master出问题就容易影响事务，一般来说为了防止受master影响，需要提前几天把表建好。
2）将时间戳字段进行处理：rowkey中不直接存储当前的时间戳timestamp，而改为存储自当周周一凌晨00:00:00开始累计的时间戳值（秒或毫秒等均可），这样表中最多存储一周数据对应的region数，当下周开始后就开始复用之前的region，从而避免了region的膨胀。相应地，查询端也需要对时间戳timestamp进行响应的处理。考虑到扩展性，假设要保存的数据超过一周时间，那么该方法也可以从1周扩展到1个月进行适应。