做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值，在最后存储时，保存成物理模型的样子就可以了。
下一节的物理模型想谈谈建模