Hbase Schema 设计

Question

我要设计一个Hbase表来存储用户信息，这些信息是针对社交网络的，比如：年龄、性别、教育、爱好、读过的书、去过的国家…… 注意：我们将来可能会添加更多信息，我们现在不知道所有信息。

例如： 姓名：Olha，年龄：25，性别：女，学历：信息技术学士，学历：计算机科学硕士，爱好：篮球，爱好：乒乓球，书籍：随风而逝，书籍：达芬奇密码，语言：英语，语言：法语，国家：德国

主要思想是能够进行如下查询： 返回所有女性，年龄：22岁，会说：英语，会说：法语，读过随风而逝的书，喜欢乒乓球，喜欢篮球和德语。

因此您可以向搜索查询添加任何条件。

您对优化此类搜索查询的 HBASE 表架构（行键、列族...）有何建议（考虑到我们将来会添加更多信息） 编写此类查询（扫描、获取、MapReduce）的最佳方法是什么。

谢谢

Answer 1

我同意 Ian Varley 的观点，即 Solr/Lucene 及其多面查询和连接允许您以您希望的方式查看数据 - 但是 - 我也认为您的问题可能是“计数”问题或“会员”问题....

听起来您在寻找与 (N) 个属性匹配的人员列表 - 您遇到的问题是，对于每个属性，您可能拥有数百万个用户 ID？

当您要做的只是计算交集/联合大小时，HBase 非常适合。您的键/值对可以放入 Hbase，您可以将用户的 ID“编码”到任一 Bloom Filter和 HyperLogLog。以交易速度换取准确性和记忆力。可能每小时/每晚在某种类型的日志聚合的点击流上运行 map/reduce 样式的作业。

其他人已经在广告空间和在线空间中针对您正在运行的查询类型执行此操作（“找到喜欢住在佛罗里达州的红牛和流行馅饼的人”） p>

参考文献

使用 Apache Hive 和 Amazon EMR 的上下文广告http://aws.amazon.com/articles/2855

扩展分布式计数器：http://whynosql.com/scaling-distributed-counters/

Google：分片计数器https://developers.google.com/appengine/articles/sharding_counters

HBase 中的分布式计数器性能 - 第 1 部分 http://palominodb.com/blog/2012/08/24/distributed-counter-performance-hbase-part-1

Facebook 的新实时分析系统：HBase 每天处理 200 亿个事件http://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 的点击流分析http://www.slideshare.net/bazaarvoice_engineering/austin-scales-clickstream-analytics

使用 HBase 进行实时分析 - http://www.slideshare.net/alexbaranau/realtime-analytics-with-hbase-long-version

Answer 2

这并不是 HBase 的一个很好的用途，因为这正是搜索索引（如 Lucene）所擅长的。

一个存储用户及其信息的普通模式可能看起来很像关系数据库，因为每个用户有 1 行，并将所有属性存储为列和值（年龄=22，语言=法语， ETC）。这适用于您提到的可扩展性（您无需更改任何架构即可存储新属性）。使用此模式，您可以通过唯一的用户 ID 查找任何一个用户（及其所有属性）。无论您有多少用户，这都会非常快。

但是，使用该架构，如果您想以您描述的方式进行搜索（“返回所有年龄为 22 岁的用户”），每个查询最终都会扫描整个表，因为仅 HBase允许您通过它们的主键访问事物；它没有任何类型的二级索引。这将是非常低效的（每次您想要执行任何单个查询时都必须扫描一百万行）。

如何解决这个问题？您可以“反转”数据的顺序并将值放在行键中，然后指向具有该值的所有用户。例如，行键可能是“age:22”，然后在行的列中可能是年龄为 22 岁的所有用户 ID。由于很多原因，这是有问题的，其中最重要的是它将是进行更新极其昂贵且棘手。但对于那些特定的查询，它会表现良好。

诀窍？这正是搜索索引（如 Lucene）所做的事情，而且它比使用 HBase 滚动自己的索引做得更好。这听起来像是您想在这里使用的工具。

如果您必须使用 HBase（正如您所说，因为它是一个研究项目），可能值得考虑同时使用 HBase 和 Lucene；谷歌上的指针。