使用solr构建hbase二级索引

使用solr构建hbase二级索引

@(HBASE)[hbase, solr]

一、概述

正常情况下，hbase适合用于根据rowkey取得一个value的应用场景，但如果是反过来的需求，如根据value值搜索有哪些rowkey满足这个条件，类似于RDBMS的操作，则不是hbase擅长的领域，因为这会导致全表扫描。

（一）业务场景描述

有一些数据记录了用户的一些行为，比如是否玩过某款游戏，是否买过某本书，是否看过某个视频等。现在需要查询以下内容：
（1）根据用户+标签作为查询条件，查询用户是否存在这个标签。这个标签可能是一个视频名称。
（2）根据用户查询该用户的所有标签。
（3）根据标签条件，搜索符合某些标签条件的用户。
前2个应用场景需要实时快速查询，最后一个场景可以离线查询。
这是最典型的应用。其中前2个场景一般用于向用户推荐商品，而第3个场景是搜索符合某些条件的用户，然后进行广告投放。

即：
（1）为用户推荐时根据用户id获取用户的信息，然后进行推荐，由于已经确认rowkey，此时进行hbase get操作是非常高效的。
（2）进行广告投放时，先根据某些条件搜索hbase中的value值，得出符合条件的rowkey，然后进行投放。如果不是所有信息索引的话，还需要根据rowkey回hbase取出完整的用户信息。

（二）技术方案

1、技术方案一

方案描述：由于应用场景1是最常用的场景，即判断用户的某个标签是否存在。将用户信息+标签作为rowkey，这可以最快速的进行查询。对于场景2可以通过Scan#setRowPrefixFilter(用户id)来获取某个用户的所有标签。对于场景3，将通过把hbase信息索引到solr，然后搜索某些符合标签条件的所有用户。
问题：为了将hbase中的内容添加至索引，需要将标签名称也作为内容保存到qualifier的value中，这会导致信息的冗余。

2、技术方案二

方案：另一个方案是直接以用户id作为rowkey，每个标签作为一个qualifier。对于场景1和2都可以直接get就行了，对于场景3同样通过solr作索引。
问题：但用户标签可能很多，过百万、千万，有可能一行超过HFILE大小（默认10G，虽然可能性很小）。另外就是即使对于应用场景1，也需要将整行读取出来，再选取其中的部分内容，这会将大量无用信息读取到内存，很容易触发GC。还有就是这种情形下将以标签作为qualifier，这个标签的名称是无法事先确定的，而solr与hbase的结合只能以cf:qulifier与solr的一个Field作映射（当然这可以通过自己开发模块去将整个cf索引，但这需要较多的人力。不存在这个问题了，已经可以索引整个cf）
建议：如果标签类别数量较少，比如1000以内，则可以使用本方案，此时上面所述的三个问题都不存在了。而且这是一个比较典型的用户画像应用，建议通过归类、聚类等算法更好控制标签的数量。大量的推荐、广告投放等应用均是使用类似的架构。缺点是信息经过整合后会丢失细节，但这部分数据可以保存在hdfs中，以备随时重新提取有效信息。

3、关于索引的