HBase性能深度分析.docVIP

Posted on November 23, 2010 by Sean_Liu 对于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的文件，直到总文件数超过由“pactionThreshold”指定的数量时（默认为3），compaction过程就将被触发了。在上述值为3时，此时该region目录下，实际文件数只有两个，还有额外的一个正处于内存中将要被刷入到磁盘的过程中。Compaction过程是Hbase的一个大动作，Hbase不仅要将这些文件转移到“compaction.dir”目录进行压缩，而且在压缩后的文件超过256MB时，还必须立即进行split动作。这一系列行为在HDFS上可谓是翻山倒海，影响颇大。待Compaction结束之后，后续的split依然会持续进行一小段时间，直到所有的region都被切割分配完毕，Hbase才会恢复平静并等待下一次数据从内存写入到HDFS的到来。 理解了上述过程，则必然对HBa