http://blog.csdn.net/bluishglc/article/details/31052749
http://www.jianshu.com/p/0bafd0168647
但对于tsdb-uid这个表，我觉得还是可以说得更详细一点的。以第一个链接提到的例子为例：
我们插入2个metrics：
proc.stat.cpu
proc.stat.mem
以及一条记录：
proc.stat.cpu 1297574486 54.2 host=foo type=user
来观察一下结构
hbase scan：
画个图更形象一点：
看到这个图，其实已经很清晰了：
1.rowKey=0的那一行，只有右边的columnFamily:id才会有值，它记录了metrics/tagk/tagv的个数。可以看到，现在metrics是两个（proc.stat.cpu和proc.stat.mem），tagk也是两个（host和type），tagv也是两个（foo和user）
2.rowKey=1和rowKey=2的这两行，只有左边的columnFamily:name才会有值，提供了根据ID找到名字的功能：
rowKey=1，它记录了id=1的metric/tagk/tagv的名字。也就是，它代表的含义是：proc.stat.cpu是第1个metric，host是第1个tagk，foo是第1个tagv。
rowKey=2跟rowKey=1是类似的含义，它记录了id=2的metric/tagk/tagv的名字。
3.剩余的几行，相当于是rowKey=1和rowKey=2这两行的一个反向关系的存储，提供的功能是根据名字找到ID：
例如rowKey=proc.stat.cpu这一行，它代表proc.stat.cpu是一个metric，且它的id是1（id:metrics=1，表明了类型和ID）
最后，很容易看到，tsdb-uid这个表是很稀疏的，表中空白的地方，永远都不会有值写进去的。但好在hbase是列存储，并不会像关系型数据库那样造成空间的浪费。
从表中也可以看到，即使是不同的metric，只要你的tagk（或者tagv）的名字相同，那这个tagk的ID就相同。例如你新创建一个名为proc.stat.wtf的metric，它也有一个tagk=host，那“host”的ID还是1，不会增加：
proc.stat.wtf 1297574486 54.2 host=bar