HBase 物理模型 第一节

 

做ETL，设计HBase有段时间了，虽然还是很不成熟，但是有点小小经验，做个笔记

 

HBase暂不谈他负载均衡，容灾性能这堆，只说他在应用上的一些小小经验作为第一节

 

先谈谈rowkey cf cq的设计

keyvalue的结构是

		-------------	----	--------Key---	--------	--------	------------	--------
key length	value length	row length	row	column family length	column family	column Qualifer	time stamp	key type	value

 

Hbase的存储数据结构是基于B+Tree的LSM tree

 

所以设计好rowkey cf cq是提高hbase查询速度的关键，尤其是rowkey，因为如果一次匹配只在rowkey就可以前缀匹配出，则将省略了遍历了巨大的cq。

 

rowkey

在工作中的物理模型，通常现在考虑建立在哪个维度上，因为通常会对这个维度进行操作，如对信息中人这个维度进行建模，就需要将人的唯一标识放在rowkey中（有时维度的标识不会只有一个名词性属性，如地理位置：经度+维度）。

之后需要考虑对于这个物理模型中的通用属性，如时间戳，数据源类型等这种通用属性，也需要拼接在rowkey中，举个例子人id_Long.Max-time_sourceid这样的一个rowkey，就可以在人这个维度上，找到时间段time上执行数据源sourceid的记录了。

 

cf

对于hbase的cf，个人不太建议使用，首先hbase的cf不是很成熟，在region split和file split的时候，多个cf的效果都不好；而且在设计上，cf的确在理论上可以在一个表建立多个维度，但是多个cf在实际中的优点暂时没有看出来（可能是因为工作局限性所导致）

 

cq

对于cq，因为是B+Tree的最后一层，而且hbase这个列式存储不对key进行压缩（很可惜，可能不想违背列式存储数据只在最后数据获取才解压的原则），所以首先不建议把cq设计的过长。cq也是支持前缀匹配的，而且因为hbase是列式存储，非结构化得数据，所以cq上可以有value这样的值，在反向索引中，会经常这样设计。

 

反向索引

hbase是列式存储，所以没有索引这样的东西。但是要是想通过hbase表中列的值，获得rowkey，那么就需要反向索引了，反向索引一般rowkey就是查询内容如手机号值，或查询类型_查询内容，cq为主表rowkey，value可以设置为一些权重，时间戳等附加信息，或是主表rowkey中一些常用信息，如人的姓名，这样就可以减少一次查询

 

统计

数据挖掘中，关联和统计恐怕是各占半壁江山，比起关联，统计还是比较简单的。

统计是按照新的维度，对现有的信息进行分类，并获得所要的维度属性，如次数，top等等。

比如，从刚刚那个表   rowkey：人id_long.max-time_sourceid 中，获得每天登陆某某网站次数最多的前100人

设计的物理模型为：rowkey：yyyyMMdd_long.max-count_人id     cq：人属性类型 value：   人属性值

在统计时，只需要对人+天这两个维度做分类，同时需要sourceid为某某网站，做求和计算，就可以得出count值，在最后存储时，保存成物理模型的样子就可以了。

 

下一节的物理模型想谈谈建模

 

 

评论

3 楼 panggezi 2013-07-02  

Hbase的存储数据结构是基于B+Tree的LSM tree,表示怀疑。有证据吗？没看代码，不过记得definitive guide里提了这个比较.

2 楼 lihao312 2013-07-01  

嗯  文章不错, 头像不错

1 楼 406657836 2013-07-01  

嗯 不错，谈rowkey一定得谈谈它连续递增的热点问题。不过楼主这里是举例用户登录，这里的一般不可能连续，所以回避了这个问题。如果是其他业务可能就要面临这个问题，楼主可以讨论下你们的解决方案。