HBase在单Column和多Column情况下批量Put的性能对比分析

作者: 大圆那些事 | 文章可以转载，请以超链接形式标明文章原始出处和作者信息 

网址: http://www.cnblogs.com/panfeng412/archive/2013/11/28/hbase-batch-put-performance-analysis-of-single-column-and-multiple-columns.html 

针对HBase在单column family单column qualifier和单column family多column qualifier两种场景下，分别批量Put写入时的性能对比情况，下面是结合HBase的源码来简单分析解释这一现象。 

1. 测试结果 
在客户端批量写入时，单列族单列模式和单列族多列模式的TPS和RPC次数相差很大，以客户端10个线程，开启WAL的两种模式下的测试数据为例， 

单列族单列模式下，TPS能够达到12403.87，实际RPC次数为53次； 
单列族多列模式下，TPS只有1730.68，实际RPC次数为478次。 
二者TPS相差约7倍，RPC次数相差约9倍。详细的测试环境这里不再罗列，我们这里关心的只是在两种条件下的性能差别情况。 

2. 粗略分析 
下面我们先从HBase存储原理层面“粗略”分析下为什么出现这个现象： 

HBase的KeyValue类中自带的字段占用大小约为50~60 bytes左右（参考HBase源码org/apache/hadoop/hbase/KeyValue.java），那么客户端Put一行数据时（53个字段，row key为64 bytes，value为751 bytes）： 

1）  开WAL，单column family单column qualifier，批量Put：(50~60) + 64 + 751 = 865~875 bytes； 

2）  开WAL，单column family多column qualifier，批量Put：((50~60) + 64) * 53 + 751 = 6793~7323 bytes。 

因此，总体来看，后者实际传输的数据量是前者的：(6793~7323 bytes) / (865~875 bytes) = 7.85~8.36倍，与测试结果478 / 53 = 9.0倍基本相符（由于客户端write buffer大小一样，实际请求数的比例关系即代表了实际传输的数据量的比例关系）。 

3. 源码分析 
OK，口说无凭，下面我们通过对HBase的源码分析来进一步验证以上理论估算值： 

HBase客户端执行put操作后，会调用put.heapSize()累加当前客户端buffer中的数据，满足以下条件则调用flushCommits()将客户端数据提交到服务端： 

1）每次put方法调用时可能传入的是一个List<Put>，此时每隔DOPUT_WB_CHECK条（默认为10条），检查当前缓存数据是否超过writeBufferSize（测试中被设置为5MB），超过则强制执行刷新； 

2）autoFlush被设置为true，此次put方法调用后执行一次刷新； 

3）autoFlush被设置为false，但当前缓存数据已超过设定的writeBufferSize，则执行刷新。 
Java代码 

 

1. private void doPut(final List<Put> puts) throws IOException {  
2.         int n = 0;  
3.         for (Put put : puts) {  
4.             validatePut(put);  
5.             writeBuffer.add(put);  
6.             currentWriteBufferSize += put.heapSize();  
7.             // we need to periodically see if the writebuffer is full instead   
8.             // of waiting until the end of the List  
9.             n++;  
10.             if (n % DOPUT_WB_CHECK == 0  
11.                     && currentWriteBufferSize > writeBufferSize) {  
12.                 flushCommits();  
13.             }  
14.         }  
15.         if (autoFlush || currentWriteBufferSize > writeBufferSize) {  
16.             flushCommits();  
17.         }  
18.     }  

由上述代码可见，通过put.heapSize()累加客户端的缓存数据，作为判断的依据；那么，我们可以按照测试数据的实际情况，编写代码生成Put对象后就能得到测试过程中的一行数据（由53个字段组成，共计731 bytes）实际占用的客户端缓存大小： 
Java代码 

 

1. import org.apache.hadoop.hbase.client.Put;  
2. import org.apache.hadoop.hbase.util.Bytes;  
3.   
4. public class PutHeapSize {  
5.     /** 
6.      * @param args 
7.      */  
8.     public static void main(String[] args) {  
9.         // single column Put size  
10.         byte[] rowKey = new byte[64];  
11.         byte[] value = new byte[751];  
12.         Put singleColumnPut = new Put(rowKey);  
13.         singleColumnPut.add(Bytes.toBytes("t"), Bytes.toBytes("col"), value);  
14.         System.out.println("single column Put size: " + singleColumnPut.heapSize());  
15.           
16.         // multiple columns Put size  
17.         value = null;  
18.         Put multipleColumnsPut = new Put(rowKey);  
19.         for (int i = 0; i < 53; i++) {  
20.             multipleColumnsPut.add(Bytes.toBytes("t"), Bytes.toBytes("col" + i), value);  
21.         }  
22.         System.out.println("multiple columns Put size: " + (multipleColumnsPut.heapSize() + 751));  
23.     }  
24. }  

程序输出结果如下： 

single column Put size: 1208 
multiple columns Put size: 10575 
由运行结果可得到，9719/1192 = 8.75，与上述理论分析值（7.85~8.36倍）、实际测试结果值（9.0倍）十分接近，基本可以验证测试结果的准确性。 

如果你还对put.heapSize()方法感兴趣，可以继续阅读其源码实现，你会发现对于一个put对象来说，其中KeyValue对象的大小最主要决定了整个put对象的heapSize大小，为了进一步通过实例验证，下面的这段代码分别计算单column和多columns两种情况下一行数据的KeyValue对象的heapSize大小： 
Java代码 

 

1. import org.apache.hadoop.hbase.KeyValue;  
2. public class KeyValueHeapSize {  
3.     /** 
4.      * @param args 
5.      */  
6.     public static void main(String[] args) {  
7.           
8.         // single column KeyValue size  
9.         byte[] row = new byte[64]; // test row length  
10.         byte[] family = new byte[1]; // test family length  
11.         byte[] qualifier = new byte[4]; // test qualifier length  
12.         long timestamp = 123456L; // ts  
13.         byte[] value = new byte[751]; // test value length  
14.         KeyValue singleColumnKv = new KeyValue(row, family, qualifier, timestamp, value);  
15.         System.out.println("single column KeyValue size: " + singleColumnKv.heapSize());  
16.           
17.         // multiple columns KeyValue size  
18.         value = null;  
19.         KeyValue multipleColumnsWithoutValueKv = new KeyValue(row, family, qualifier, timestamp, value);  
20.         System.out.println("multiple columns KeyValue size: " + (multipleColumnsWithoutValueKv.heapSize() * 53 + 751));  
21.     }  
22.       
23. }  

程序输出结果如下： 

single column KeyValue size: 920 
multiple columns KeyValue size: 10079 
与前面PutHeapSize程序的输出结果对比发现，KeyValue确实占据了整个Put对象的大部分heapSize空间，同时发现从KeyValue对象级别对比两种情况下的传出数据量情况：10079/920 = 10.9倍，也与实际测试值比较接近。 

4. 相关结论 
经过以上分析可以得出以下结论： 

在实际应用场景中，对于单column qualifier和多column qualifier两种情况，如果value长度越长，row key长度越短，字段数（column qualifier数）越少，前者和后者在实际传输数据量上会相差小些；反之则相差较大。 
如果采用多column qualifier的方式存储，且客户端采取批量写入的方式，则可以根据实际情况，适当增大客户端的write buffer大小，以便能够提高客户端的写入吞吐量。

转载于:https://www.cnblogs.com/Levyxu/p/10659736.html