转自：http://www.aboutyun.com/thread-7119-1-1.html
对于任何系统的数据设计，我们都想提高性能，达到资源最大化利用，那么对于hbase我们产生如下问题：
1.hbase rowkey设计如何才能提高性能？
2.hbase rowkey如何设计才能散列到不同的节点上？
访问hbase table中的行，只有三种方式：
1 通过单个row key访问
2 通过row key的range
3 全表扫描
文中可能涉及到的API：
Hadoop/HDFS:http://hadoop.apache.org/common/docs/current/api/
HBase: http://hbase.apache.org/apidocs/index.html?overview-summary.html
HBase的查询实现只提供两种方式：
1、按指定RowKey获取唯一一条记录，get方法（org.apache.hadoop.hbase.client.Get）
2、按指定的条件获取一批记录，scan方法（org.apache.hadoop.hbase.client.Scan）
实现条件查询功能使用的就是scan方式，scan在使用时有以下几点值得注意：
1、scan可以通过setCaching与setBatch方法提高速度（以空间换时间）；
2、scan可以通过setStartRow与setEndRow来限定范围。范围越小，性能越高。
通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起（应该在同一个Region下），可以在遍历结果时获得很好的性能。
3、scan可以通过setFilter方法添加过滤器，这也是分页、多条件查询的基础。
-------------------------------------------------------------------------------------------------------------------------------------------------
下面举个形象的例子：
我们在表中存储的是文件信息，每个文件有5个属性：文件id（long，全局唯一）、创建时间（long）、文件名（String）、分类名（String）、所有者（User）。
我们可以输入的查询条件：文件创建时间区间（比如从20120901到20120914期间创建的文件），文件名（“中国好声音”），分类（“综艺”），所有者（“浙江卫视”）。
假设当前我们一共有如下文件：
内容列表 ID CreateTime Name Category UserID 1 2 3 4 5 6 7 8 9 10
| 20120902 | 中国好声音第1期 | 综艺 | 1 |
| 20120904 | 中国好声音第2期 | 综艺 | 1 |
| 20120906 | 中国好声音外卡赛 | 综艺 | 1 |
| 20120908 | 中国好声音第3期 | 综艺 | 1 |
| 20120910 | 中国好声音第4期 | 综艺 | 1 |
| 20120912 | 中国好声音选手采访 | 综艺花絮 | 2 |
| 20120914 | 中国好声音第5期 | 综艺 | 1 |
| 20120916 | 中国好声音录制花絮 | 综艺花絮 | 2 |
| 20120918 | 张玮独家专访 | 花絮 | 3 |
| 20120920 | 加多宝凉茶广告 | 综艺广告 | 4 |
这里UserID应该对应另一张User表，暂不列出。我们只需知道UserID的含义：
1代表 浙江卫视； 2代表 好声音剧组； 3代表 XX微博； 4代表 赞助商。
调用查询接口的时候将上述5个条件同时输入find(20120901,20121001,"中国好声音","综艺","浙江卫视")。
此时我们应该得到记录应该有第1、2、3、4、5、7条。第6条由于不属于“浙江卫视”应该不被选中。
我们在设计RowKey时可以这样做：采用UserID + CreateTime + FileID组成rowKey，这样既能满足多条件查询，又能有很快的查询速度。
需要注意以下几点：
1、每条记录的RowKey，每个字段都需要填充到相同长度。假如预期我们最多有10万量级的用户，则userID应该统一填充至6位，如000001，000002...
2、结尾添加全局唯一的FileID的用意也是使每个文件对应的记录全局唯一。避免当UserID与CreateTime相同时的两个不同文件记录相互覆盖。
按照这种RowKey存储上述文件记录，在HBase表中是下面的结构：
rowKey（userID 6 + time 8 + fileID 6） name category ....
00000120120902000001
00000120120904000002
00000120120906000003
00000120120908000004
00000120120910000005
00000120120914000007
00000220120912000006
00000220120916000008
00000320120918000009
00000420120920000010
怎样用这张表？
在建立一个scan对象后，我们setStartRow(00000120120901)，setEndRow(00000120120914)。
这样，scan时只扫描userID=1的数据，且时间范围限定在这个指定的时间段内，满足了按用户以及按时间范围对结果的筛选。并且由于记录集中存储，性能很好。
然后使用SingleColumnValueFilter（org.apache.hadoop.hbase.filter.SingleColumnValueFilter），共4个，分别约束name的上下限，与category的上下限。满足按同时按文件名以及分类名的前缀匹配。
（注意：使用SingleColumnValueFilter会影响查询性能，在真正处理海量数据时会消耗很大的资源，且需要较长的时间。
在后续的博文中我将多举几种应用场景下rowKey的，可以满足简单条件下海量数据瞬时返回的查询功能）
如果需要分页还可以再加一个PageFilter限制返回记录的个数。
以上，我们完成了高性能的支持多条件查询的HBase表结构设计。
-------------------------------------------------------------------------------------------------------------------------------------------------
如何散列存储
即时间上连续的数据。这些数据可能来自于某个传感器网络、证券交易或者一个监控系统。它们显著的特点就是rowkey中含有事件发生时间。带来的一个问题便是HBase对于row的不均衡分布，它们被存储在一个唯一的rowkey区间中，被称为region，区间的范围被称为Start Key和End Key。
对于单调递增的时间类型数据，很容易被散列到同一个Region中，这样它们会被存储在同一个服务器上，从而所有的访问和更新操作都会集中到这一台服务器上，从而在集群中形成一个hot spot，从而不能将集群的整体性能发挥出来。
要解决这个问题是非常容易的，只需要将所有的数据散列到全部的Region上即可。这是可以做到的，比如，在rowkey前面加上一个非线程序列，常常有如下选择：
Hash散列
您可以使用一个Hash前缀来保证所有的行被分发到多个Region服务器上。例如：
byte prefix =
(byte) (Long.hashCode(timestamp) % <number of regionservers>);
byte[] rowkey =
Bytes.add(Bytes.toBytes(prefix), Bytes.toBytes(timestamp);
这个公式可以产生足够的数字，将数据散列到所有的Region服务器上。当然，公式里假定了Region服务器的数目。如果您打算后期扩容您的集群，那么您可以把它先设置为集群的整数倍。生成的rowkey类似下面：
0myrowkey-1,
1myrowkey-2, 2myrowkey-3, 0myrowkey-4, 1myrowkey-5, \
2myrowkey-6, …
当他们将按如下顺序被发送到各个Region服务器上去：
0myrowkey-1
0myrowkey-4
1myrowkey-2
1myrowkey-5
…
换句话说，对于0myrowkey-1和0myrowkey-4的更新操作会被发送到同一个region服务器上去（假定它们没有被散列到两个region上去），1myrowkey-2和1myrowkey-5会被发送到同一台服务器上。
这种方式的缺点是，rowkey的范围必须通过代码来控制，同时对数据的访问，可能要访问多台region服务器。当然，可以通过多个线程同时访问，来实现并行化的数据读取。这种类似于只有map的MapReduce任务，可以大大增加IO的性能。
案例：Mozilla
Socoroo
Mozilla公司搭建了一个名为Socorro的crash报告系统，用来跟踪Firefox和Thunderbird的crash记录，存储所有的用户提交的关于程序非正常中止的报告。这些报告被顺序访问，通过Mozilla的开发团队进行分析，使得它们的应用软件更加稳定。
这些代码是开源的，包含着Python写的客户端代码。它们使用Thrift直接与HBase集群进行交互。下面的给出了代码中用于Hash时间的部分：
def
merge_scan_with_prefix(self,table,prefix,columns):
“”"
A generator based
iterator that yields totally ordered rows starting with a
given prefix. The
implementation opens up 16 scanners (one for each leading
hex character of
the salt) simultaneously and then yields the next row in
order from the
pool on each iteration.
“”"
iterators = []
next_items_queue =
[]
for salt in
’0123456789abcdef’:
salted_prefix =
“%s%s” % (salt,prefix)
scanner = self.client.scannerOpenWithPrefix(table,
salted_prefix, columns)
iterators.append(salted_scanner_iterable(self.logger,self.client,
self._make_row_nice,salted_prefix,scanner))
# The i below is
so we can advance whichever scanner delivers us the polled
# item.
for i,it in
enumerate(iterators):
try:
next = it.next
next_items_queue.append([next(),i,next])
except
StopIteration:
pass
heapq.heapify(next_items_queue)
while 1:
try:
while 1:
row_tuple,iter_index,next= s = next_items_queue[0]
#tuple[1]
is the actual nice row.
yield
row_tuple[1]
s[0]
= next()
heapq.heapreplace(next_items_queue,s)
except
StopIteration:
heapq.heappop(next_items_queue)
except
IndexError:
return
这些Python代码打开了一定数目的scanner，加上Hash后的前缀。这个前缀是一个单字符的，共有16个不同的字母。heapq对象将scanner的结果进行全局排序。
字段位置交换
在前面提到了Key部分扫描，您可以移动timestamp字段，将它放在前一个字段的前面。这种方法通过rowkey的组合来将一个顺序递增的timestamp字段放在rowkey的第二个位置上。
如果你的rowkey不单单含有一个字段，您可以交换它们的位置。如果你现在的rowkey只有一个timestamp字段，您有必要再选出一个字段放在rowkey中。当然，这也带来了一个缺点，即您常常只能通过rowkey的范围查询来访问数据，比如timestamp的范围。