Sumary:
MemStore结构
KeyValue构成细节
HFile分析
Maven
项目例子使用了Maven来管理Dependency,要运行例子，需要有maven环境，后面提到的HFile,StoreFile,HStoreFile指的是同一样东西，也就是HBase中Region每个CF对应的数据文件。
HBase一直有一个问题，困扰着我一段时间了.时而思考一下，终不得解。
问题发生于5月某天，在做大量Put测试去观察MemStore的flush,
HStoreFile的Split和Compact操作时，奇怪的事情发生了，默认MemStore的size为128M,headSize达到128M,进行flush之后，MemStore恢复为0M,生成snapshot写hfile,最终生在hdfs的大小却是30M左右。
百思不得奇怪，为什么会减少了这么多,压缩？NO!
最近开始研究HFile的相关内容时，又想起了MemStore size和HFile size不一致问题，再次做试验。最终找到了答案.
场景设置：
环境: 64位 CentOS VM 伪分布Hadoop ，standalone方式的HBase 连接本机hdfs. 4G内存
4核
Hadoop 2.3 HBase 0.98.1-hadoop2 HFileReader(Writer)
V2
单个表,1个CF, 10W rows,即 70WKV,每个KV heapSize占100+byte左右，目测KV headSize会占有
70M
具体见测试代码。
1. 执行App.java 结束后，查看后台 master:60010 ,memStore的内存达到 112.9M
图1
2.通常，数据不会被flush至HFile中，重启HBase,强制flush memStore，再次查看后台web gui.
stop-hbase.sh
start-hbase.sh
图2
查看HFile只有26M。只有源数据的25%不到，很好，是我想要的结果。
也可以在stop后，直接使用hadoop
命令查看dfs中的文件大小 :hadoop fs -ls -R /hbase/data/default/t_sample/
图3
至此，第一个小实验做完了，结果很明显，MemStore 112.9M
flush到StoreFile中只有26M，不到1/4的容量，why?
首先我们看一个KeyValue的构成
图4
从图中可以得知KeyValue的细节,我们继续一些有趣的小实验。
1.构建一个KeyValue
public static void main(String[] args) throws Exception {
final byte[] row = Bytes.toBytes("u1");
final byte[] family = Bytes.toBytes("info");
final byte[] qualifier = Bytes.toBytes("sex");
final byte[] value = Bytes.toBytes("M");
KeyValue kv = new KeyValue(row, family, qualifier, value);
kv.setMvccVersion(System.currentTimeMillis());
System.out.println(kv.heapSize());
}
输出: 96
顺手抓了一幅图如下：
图5
结合KeyValue结构图4及实际一个KeyValue的字节码图5我们分析一下：
第0-3个字节 为 int类型 Key的长度，在这里是 21
第4-7个字节 为 int类型
Value的长度,在这里只有1
第8-28个字节为Key的内容
8-9 short类型，指定了 rowKey的长度 值为 2.
10-11 对应的rowKey,转为原String为u1
12 byte型的ColumnFamility Length,值为4
13-16 对应CF值，转为原String为info
28为KeyType,由于我们创建KeyValue时没有显式指定，默认为Put(4)
20-27为8字节的Long型，对应timestamp.
所以剩下的为 17-19
三字节为Qualifier,转为原String为sex
第29，即最后一字节，是Value内容 : "M"
好，假设我们KeyValue的真实内容，就是这堆长度为30的字节码，我们简单算一下, 30 * 70 * 10000 /
1024 / 1024 =
20M，这个数值是不是和我们的HFile的大小有点接近呢？我们试想一下，文件中还有一些Index、MetaBlock、Meta、FileInfo等信息，七七八八加起来，再加上本身其它column的
value就不止1字节，所以已经非常接近我们这26M的目标大小了。
好的，我们假设这些字节码，就是直接存入到HFile中的,那么MemStore呢，存的又是哪样？我们再简单地算一下,
96 * 70*10000 / 1024 / 1024 = 64M,离 112.9M差了近一倍。
走另一条路，我们想另一个问题，再来看看，为什么KeyValue本身只有30byte,但是打印出来是在MemStore的heapSize是96?看看heapSize()方法。
public long heapSize() {
int sum = 0;
sum += ClassSize.OBJECT;// the KeyValue object itself 16字节
sum += ClassSize.REFERENCE;// pointer to "bytes" 8字节
sum += ClassSize.align(ClassSize.ARRAY);// "bytes" 24字节
sum += ClassSize.align(length);// number of bytes of data in the "bytes" array 以刚才的为例，30,会转化为32字节.
sum += 2 * Bytes.SIZEOF_INT;// offset, length 2字节
sum += Bytes.SIZEOF_LONG;// memstoreTS 8字节
return ClassSize.align(sum);
}
OK，由于在内存中的原因，一个KeyValue对象除了本身实际内容外，还有
64byte是对象的内部实例等占用了部分空间，从而会这么大。
另外，我们查看MemStore的结构：
volatile KeyValueSkipListSet kvset;
KeyValue是放在SkipListSet中的，内部其实就是一个Map,那么我们每个KeyValue存在Map中其实是一个又一个是Entry.其中每一个Entry又占了64byte.所以，一个KeyValue占MemStore的空间大约是160bytes.
我们取168个字节为一个KeyValue大概算一算 168 * 70 * 10000 / 1024 / 1024 = 112.1
,之所以取168其实也就是一行中7个KeyValue肉眼大约算出来的平均值，112.1M已经非常接近112.9M了.
假设我们用38* 70 * 10000 / 1024 /
1024来算，25.3M，更为精确点，所以结合二个size，我们假定，这就是它们的真实的内存大小和文件大小。
为了论证这一点，我们还是做一个实例。具体源码见附件中。
我们直接通过HFileReader去读取HDFS中的HFile，然后Scan里面所有的KeyValue进行统计。结果输出为：
MemStoreSize:118391920,HFileSize:27723608,KeyValue
Count:700000 转化单位
MemStoreSize:112.9M,HFileSize:26.4M,KeyValue Count:700000
好了，真相大白，完全证明了上面的推断是正确的。
项目源码下载： http://files.cnblogs.com/bdifn/MemStore_HStore_sample.zip
HBase MemStore与HStoreFile 的大小分析,布布扣,bubuko.com