随着Facebook使用HBase来构建实时消息系统，基于Hadoop的面向列存储的HBase持续升温。

    目前稳定版本的HBase0.90.2只能基于Hadoop0.20.x系列版本，暂不支持最新的0.21.x。而且官方版本的Hadoop0.20.2(或者0.203.0)缺少一个重要的特性，HDFS不支持sync模式的持久，这样HBase就有较大的丢失数据的风险。要在生产环境使用HBase，有两个选择，一是使用Cloudera的CDH3版本，Cloudera就类似MySQL的Percona，对官方版本的Hadoop做了很多改进工作，而且经典的《Hadoop：The Definitive Guide》一书的作者Tom White就是Cloudera的一员，这也和《High performance MySQL》一书的作者主要来是Percona一样。另外一种选择，就是自行编译Hadoop branch-0.20-append源码分支，这里有详细的说明。

    对于HBase这种类似BigTable的系统，其优化之一是消除了磁盘的随机写。付出的代价是将最新的数据保存在内存表中，对内存有较大的需求。如果内存表的数量较多，则每个内存表就会在较小的时候刷到磁盘，导致磁盘文件多而且小。范围读取数据的时候就会跨多个数据文件甚至多个节点。为提升读性能，系统都会设计有compaction操作。另外为了防止某些情况下数据文件过大(hbase.hregion.max.filesize，默认256M，太大的数据文件在compaction等操作是对内存的消耗更大)，HBase也设计了split操作。Compaction和Split操作，对于在线应用的响应时间都容易造成波动，他们的策略需要根据应用的特性进行调整。建议在业务低峰期手工调整。

    HBase的regionserver宕机超过一定时间后，HMaster会将其所管理的region重新分布到其他存活的regionserver，由于数据和日志都持久在HDFS中，因此该操作不会导致数据丢失。但是重新分配的region需要根据日志恢复原regionserver中的内存表，这会导致宕机的region在这段时间内无法对外提供服务。而一旦重分布，宕机的节点起来后就相当于一个新的regionserver加入集群，为了平衡，需要再次将某些region分布到该server。 因此这个超时建议根据情况进行调整，一般情况下，宕机重启后即可恢复，如果重启需要10分钟，region重分布加恢复的时间要超过5分钟，那么还不如等节点重启。Region Server的内存表memstore如何在节点间做到更高的可用，是HBase的一个较大的挑战。Oceanbase也是采用内存表保持最新的更新数据，和HBase不同的是，Oceanbase使用的是集中的UpdateServer，只需要全力做好UpdateServer的容灾切换即可对业务连续性做到最小影响。分布还是集中，哪些功能分布，哪些功能集中，各自取不同平衡，是目前大部分分布式数据库或者存储的一个主要区别。当然，像Cassandra这种全分布的，架构上看起来很完美，实际应用起来反而问题更多。

    对于java应用，线上运维最大的挑战之一就是heap内存管理。GC的不同方式，以及使用内存表和cache对内存的消耗，可能导致局部阻塞应用或者stop the world全局阻塞或者OOM。因此HBase的很多参数设置都是针对这两种情况。HBase使用了较新的CMS GC(-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode)。

    默认触发GC的时机是当年老代内存达到90%的时候，这个百分比由 -XX:CMSInitiatingOccupancyFraction=N 这个参数来设置。concurrent mode failed发生在这样一个场景：

     当年老代内存达到90%的时候，CMS开始进行并发垃圾收集，于此同时，新生代还在迅速不断地晋升对象到年老代。当年老代CMS还未完成并发标记时，年老代满了，悲剧就发生了。CMS因为没内存可用不得不暂停mark，并触发一次全jvm的stop the world(挂起所有线程)，然后采用单线程拷贝方式清理所有垃圾对象。这个过程会非常漫长。为了避免出现concurrent mode failed，我们应该让GC在未到90%时，就触发。

    通过设置 -XX:CMSInitiatingOccupancyFraction=N

    这个百分比， 可以简单的这么计算。如果你的 hfile.block.cache.size 和 hbase.regionserver.global.memstore.upperLimit 加起来有60%(默认)，那么你可以设置 70-80，一般高10%左右差不多。

    (以上CMS GC的说明引自HBase性能调优)

    目前关于HBase的书不多，《Hadoop： The Definitive Guide》第二版有一章，另外最权威的要算官方的这本电子书了。

    这篇是最近看HBase过程中的一些零碎的东西，记录于此备忘。

建议继续学习：

1. HBase集群出现NotServingRegionException问题的排查及解决方法    (阅读：16227)
2. HFile存储格式    (阅读：14538)
3. hbase运维    (阅读：13678)
4. hbase介绍    (阅读：11033)
5. HBase技术介绍    (阅读：6761)
6. HBase随机写以及随机读性能测试    (阅读：6492)
7. HBase性能优化方法总结    (阅读：5830)
8. HBase二级索引与Join    (阅读：5791)
9. HBase Thrift 接口使用注意事项    (阅读：5413)
10. Cassandra和HBase主要设计思路对比    (阅读：4139)