HBase性能深度分析

  hbase一张表保存多少条记录量左右不会使性能下降重?如果每天几亿条的数据往一张表里塞,到最后会不会跑不了了?

   对于Bigtable类型的分布式数据库应用来说，用户往往会对其性能状况有极大的兴趣，这其中又对实时数据插入性能更为关注。HBase作为Bigtable的一个实现，在这方面的性能会如何呢？这就需要通过测试数据来说话了。

数据插入性能测试的设计场景是这样的，取随机值的Rowkey长度为2000字节，固定值的Value长度为4000字节，由于单行Row插入速度太快，系统统计精度不够，所以将插入500行Row做一次耗时统计。

这里要对HBase的特点做个说明，首先是Rowkey值为何取随机数，这是因为HBase是对Rowkey进行排序的，随机Rowkey将被分配到不同的region上，这样才能发挥出分布式数据库的性能优点。而Value对于HBase来说不会进行任何解析，其数据是否变化，对性能是不应该有任何影响的。同时为了简单起见，所有的数据都将只插入到一个表格的同一个Column中。

在测试之初，需要对集群进行调优，关闭可能大量耗费内存、带宽以及CPU的服务，例如Apache的Http服务。保持集群的宁静度。此外，为了保证测试不受干扰，Hbase的集群系统需要被独立，以保证不与HDFS所在的Hadoop集群有所交叉。

那么做好一切准备，就开始进行数据灌入，客户端从Zookeeper上查询到Regionserver的地址后，开始源源不断的向Hbase的Regionserver上喂入Row。

这里，我写了一个通过JFreeChart来实时生成图片的程序，每3分钟，喂数据的客户端会将获取到的耗时统计打印在一张十字坐标图中，这些图又被保存在制定的web站点中，并通过http服务展示出来。在通过长时间不间断的测试后，我得到了如下图形：

这个图形非常有特点，好似一条直线上，每隔一段时间就会泛起一个波浪，且两个高峰之间必有一个较矮的波浪。高峰的间隔则呈现出越来越大的趋势。而较矮的波浪恰好处于两高峰的中间位置。

为了解释这个现象，我对HDFS上Hbase所在的主目录下文件，以及被插入表格的region情况进行了实时监控，以期发现这些波浪上发生了什么事情。

回溯到客户端喂入数据的开始阶段，创建表格，在HDFS上便被创建了一个与表格同名的目录，该目录下将出现第一个region，region中会以family名创建一个目录，这个目录下才存在记录具体数据的文件。同时在该表表名目录下，还会生成一个“compaction.dir”目录，该目录将在family名目录下region文件超过指定数目时用于合并region。

当第一个region目录出现的时候，内存中最初被写入的数据将被保存到这个文件中，这个间隔是由选项“hbase.hregion.memstore.flush.size”决定的，默认是64MB，该region所在的Regionserver的内存中一旦有超过64MB的数据的时候，就将被写入到region文件中。这个文件将不断增殖，直到超过由“hbase.hregion.max.filesize”决定的文件大小时（默认是256MB，此时加上内存刷入的数据，实际最大可能到256+64M），该region将被执行split，立即被一切为二，其过程是在该目录下创建一个名为“.splits”的目录作为标记，然后由Regionserver将文件信息读取进来，分别写入到两个新的region目录中，最后再将老的region删除。这里的标记目录“.splits”将避免在split过程中发生其他操作，起到类似于多线程安全的锁功能。在新的region中，从老的region中切分出的数据独立为一个文件并不再接受新的数据（该文件大小超过了64M，最大可达到（256+64）/2=160MB），内存中新的数据将被保存到一个重新创建的文件中，该文件大小将为64MB。内存每刷新一次，region所在的目录下就将增加一个64M的文件，直到总文件数超过由“hbase.hstore.compactionThreshold”指定的数量时（默认为3），compaction过程就将被触发了。在上述值为3时，此时该region目录下，实际文件数只有两个，还有额外的一个正处于内存中将要被刷入到磁盘的过程中。Compaction过程是Hbase的一个大动作，Hbase不仅要将这些文件转移到“compaction.dir”目录进行压缩，而且在压缩后的文件超过256MB时，还必须立即进行split动作。这一系列行为在HDFS上可谓是翻山倒海，影响颇大。待Compaction结束之后，后续的split依然会持续进行一小段时间，直到所有的region都被切割分配完毕，Hbase才会恢复平静并等待下一次数据从内存写入到HDFS的到来。

理解了上述过程，则必然对HBase的数据插入性能为何是上图所示的曲线的原因一目了然。与X轴几乎平行的直线，表明数据正在被写入HBase的Regionserver所在机器的内存中。而较低的波峰意味着Regionserver正在将内存写入到HDFS上，较高的波峰意味着Regionserver不仅正在将内存刷入到HDFS，而且还在执行Compaction和Split两种操作。如果调整“hbase.hstore.compactionThreshold”的值为一个较大的数量，例如改成5，可以预见，在每两个高峰之间必然会等间隔的出现三次较低的波峰，并可预见到，高峰的高度将远超过上述值为3时的高峰高度（因为Compaction的工作更为艰巨）。由于region数量由少到多，而我们插入的Row的Rowkey是随机的，因此每一个region中的数据都会均匀的增加，同一段时间插入的数据将被分布到越来越多的region上，因此波峰之间的间隔时间也将会越来越长。

再次理解上述论述，我们可以推断出Hbase的数据插入性能实际上应该被分为三种情况，即直线状态、低峰状态和高峰状态。在这三种情况下得到的性能数据才是最终Hbase数据插入性能的真实描述。那么提供给用户的数据该是采取哪一个呢？我认为直线状态由于其所占时间会较长，尤其在用户写入数据的速度也许并不是那么快的情况下，所以这个状态下得到的性能数据结果更应该提供给用户。



转自： HBase性能深度分析