这并不是hbase的一个很好的用途，因为这正是搜索索引（比如lucene）所擅长的。
存储用户及其信息的一个普通模式可能看起来很像关系数据库，即每个用户有一行，并将所有属性存储为列和值（age=22，language=french，等等）。这对于您提到的可扩展性非常有效（不需要更改任何模式来存储新属性）。使用这个模式，您可以通过唯一的用户id查找任何一个用户（以及他们的所有属性），无论您有多少个用户，这都非常快。
然而，在这种模式下，如果您想按照您描述的方式进行搜索（“返回年龄为22岁的所有用户”），每个查询最终都会扫描整个表，因为hbase只允许您通过主键访问内容；它没有任何类型的辅助索引。这将是非常低效的（图片必须扫描一百万行，每次你想做任何单一的查询）。
如何解决这个问题？您可以“反转”数据的顺序，将值放入行键中，然后指向具有该值的所有用户。例如，行键可以是“age:22，然后在该行的列中可以是年龄为22岁的所有用户标识。这是有问题的原因有很多，其中最重要的是，它将是极其昂贵和棘手的更新。但对于那些特定的查询，它会表现得很好。
诀窍？这正是搜索索引（如lucene）所做的，它比使用hbase滚动自己的索引做得更好。听起来像是你要用的工具。
如果您必须使用hbase（正如您所说，因为它是一个研究项目），那么一起使用hbase和lucene可能是值得研究的；在谷歌上搜索指针。

我同意ian varley的观点，solr/lucene和它的分面查询和连接允许您以您希望的方式查看数据—但是—我也认为您的问题可能是“计数”问题或“成员资格”问题。。。。
听起来你在寻找一个匹配（n）个属性的人的列表-你的问题是，对于每个属性，你可能有数百万个用户ID？
当您只需要计算交集/并集大小时，hbase非常适合。。您的键/值对可以放入hbase，您可以将用户的id“编码”到bloomfilter和hyperloglog中。以速度换取准确性和记忆力。可能在某些类型的日志聚合的单击流上每小时/每夜运行map/reduce样式的作业。
其他人则在广告空间和在线空间中这样做，只针对你正在运行的查询类型（“寻找住在佛罗里达州的喜欢红牛和流行馅饼的人”）
参考文献
使用apachehive和amazon emr的上下文广告http://aws.amazon.com/articles/2855
缩放分布式计数器：http://whynosql.com/scaling-distributed-counters/
谷歌：切分计数器https://developers.google.com/appengine/articles/sharding_counters
hbase中的分布式计数器性能.第1部分http://palominodb.com/blog/2012/08/24/distributed-counter-performance-hbase-part-1
facebook新的实时分析系统：每天处理200亿个事件的hbasehttp://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html
使用hadoop和hbase进行实时分析-http://www.slideshare.net/larsgeorge/realtime-analytics-with-hadoop-and-hbase
用hbase记录事件处理http://tellapart.com/log-event-processing-with-hbase
bazaarvoice的clickstream分析http://www.slideshare.net/bazaarvoice_engineering/austin-scales-clickstream-analytics
使用hbase进行实时分析-http://www.slideshare.net/alexbaranau/realtime-analytics-with-hbase-long-version