HBase 性能优化方法总结（一）：表的设计

转自:http://www.cnblogs.com/panfeng412/archive/2012/03/08/hbase-performance-tuning-section1.html
1. 表的设计

1.1 Pre-Creating Regions

默认情况下，在创建 HBase 表的时候会自动创建一个 region 分区，当导入数据的时候，所有的
HBase 客户端都向这一个 region 写数据，直到这个 region 足够大了才进行切分。一种可以加快批
量写入速度的方法是通过预先创建一些空的 regions，这样当数据写入 HBase 时，会按照 region
分区情况，在集群内做数据的负载均衡。
下面是一个例子：

public static boolean createTable(HBaseAdmin admin, HTableDescriptor table, byte[][]
splits)
throws IOException {
try {
admin.createTable(table, splits);
return true;
} catch (TableExistsException e) {
logger.info("table " + table.getNameAsString() + " already exists");
// the table already exists...
return false;
}
}
public static byte[][] getHexSplits(String startKey, String endKey, int numRegions)
{ //start:001,endkey:100,10region [001,010]
[011,020]
byte[][] splits = new byte[numRegions-1][];
BigInteger lowestKey = new BigInteger(startKey, 16);
BigInteger highestKey = new BigInteger(endKey, 16);
BigInteger range = highestKey.subtract(lowestKey);
BigInteger regionIncrement = range.divide(BigInteger.valueOf(numRegions));
lowestKey = lowestKey.add(regionIncrement);
for(int i=0; i < numRegions-1;i++) {
BigInteger key = lowestKey.add(regionIncrement.multiply(BigInteger.valueOf(i)));
byte[] b = String.format("%016x", key).getBytes();
splits[i] = b;
}
return splits;
}

1.2 Row Key

HBase 中 row key 用来检索表中的记录，支持以下三种方式：
1).通过单个 row key 访问：即按照某个 row key 键值进行 get 操作；
2).通过 row key 的 range 进行 scan：即通过设置 startRowKey 和 endRowKey，在这个范围内进
行扫描；
3).全表扫描：即直接扫描整张表中所有行记录。
在 HBase 中， row key 可以是任意字符串，最大长度 64KB，实际应用中一般为 10~100bytes，存为
byte[]字节数组， 一般设计成定长的。
row key 是按照字典序存储，因此，设计 row key 时，要充分利用这个排序特点，将经常一起读取
的数据存储到一块，将最近可能会被访问的数据放在一块。
举个例子：如果最近写入 HBase 表中的数据是最可能被访问的，可以考虑将时间戳作为 row key
的一部分，由于是字典序排序，所以可以使用 Long.MAX_VALUE - timestamp 作为 row key，这样
能保证新写入的数据在读取时可以被快速命中。
Rowkey 规则：
1、 越小越好
2、 Rowkey 的设计是要根据实际业务来
3、 散列性
i. 取反 001 002 100 200
ii. Hash

1.3 Column Family

不要在一张表里定义太多的 column family。目前 Hbase 并不能很好的处理超过 2~3 个 column
family 的表。因为某个 column family 在 flush 的时候，它邻近的 column family 也会因关联效
应被触发 flush，最终导致系统产生更多的 I/O。感兴趣的同学可以对自己的 HBase 集群进行实际
测试，从得到的测试结果数据验证一下。

1.4 In Memory

创建表的时候，可以通过 HColumnDescriptor.setInMemory(true)将表放到 RegionServer 的缓存
中，保证在读取的时候被 cache 命中。

1.5 Max Version

创建表的时候，可以通过 HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据
的最大版本，如果只需要保存最新版本的数据，那么可以设置 setMaxVersions(1)。

1.6 Time To Live

创建表的时候，可以通过 HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存
储生命期，过期数据将自动被删除，例如如果只需要存储最近两天的数据，那么可以设置
setTimeToLive(2 * 24 * 60 * 60)。

1.7 Compact & Split

在 HBase 中，数据在更新时首先写入 WAL 日志(HLog)和内存(MemStore)中， MemStore 中的数据是
排序的，当 MemStore 累计到一定阈值时，就会创建一个新的 MemStore，并且将老的 MemStore 添
加到 flush 队列，由单独的线程 flush 到磁盘上，成为一个 StoreFile。于此同时， 系统会在
zookeeper 中记录一个 redo point，表示这个时刻之前的变更已经持久化了(minor compact)。
StoreFile 是只读的，一旦创建后就不可以再修改。因此 Hbase 的更新其实是不断追加的操作。当
一个 Store 中的 StoreFile 达到一定的阈值后，就会进行一次合并(major compact)，将对同一个
key 的修改合并到一起，形成一个大的 StoreFile，当 StoreFile 的大小达到一定阈值后，又会对
StoreFile 进行分割(split)，等分为两个 StoreFile。
由于对表的更新是不断追加的，处理读请求时，需要访问 Store 中全部的 StoreFile 和 MemStore，
将它们按照 row key 进行合并，由于 StoreFile 和 MemStore 都是经过排序的，并且 StoreFile 带
有内存中索引，通常合并过程还是比较快的。
实际应用中，可以考虑必要时手动进行 major compact，将同一个 row key 的修改进行合并形成一
个大的 StoreFile。同时，可以将 StoreFile 设置大些，减少 split 的发生。
hbase 为了防止小文件（被刷到磁盘的 menstore）过多，以保证保证查询效率， hbase 需要在必要
的时候将这些小的 store file 合并成相对较大的 store file，这个过程就称之为 compaction。
在 hbase 中，主要存在两种类型的 compaction： minor compaction 和 major compaction。
minor compaction:的是较小、很少文件的合并。
major compaction 的功能是将所有的 store file 合并成一个，触发 major compaction 的可能条
件有： major_compact 命令、 majorCompact() API、 region server 自动运行（相关参数：
hbase.hregion.majoucompaction 默认为 24 小时、 hbase.hregion.majorcompaction.jetter 默
认值为 0.2 防止 region server 在同一时间进行 major compaction）。
hbase.hregion.majorcompaction.jetter 参数的作用是：对参数
hbase.hregion.majoucompaction 规定的值起到浮动的作用，假如两个参数都为默认值 24 和 0,2，
那么 major compact 最终使用的数值为： 19.2~28.8 这个范围。
关闭自动 major compaction
手动编程 major compaction
Timer 类， contab
minor compaction 的运行机制要复杂一些，它由一下几个参数共同决定：
hbase.hstore.compaction.min :默认值为 3，表示至少需要三个满足条件的 store file 时，
minor compaction 才会启动
hbase.hstore.compaction.max 默认值为 10，表示一次 minor compaction 中最多选取 10 个
store file
hbase.hstore.compaction.min.size 表示文件大小小于该值的 store file 一定会加入到 minor
compaction 的 store file 中
hbase.hstore.compaction.max.size 表示文件大小大于该值的 store file 一定会被 minor
compaction 排除
hbase.hstore.compaction.ratio 将 store file 按照文件年龄排序（older to younger），
minor compaction 总是从 older store file 开始选择