【华为云技术分享】HBase与AI/用户画像/推荐系统的结合：CloudTable标签索引特性介绍...

标签数据已经成为越来越普遍的一类数据，以用户画像场景最为典型，如在电商场景中，这类数据可被应用于精准营销推荐。常见的用户画像标签数据举例如下：

• 基础信息：如性别，职业，收入，房产，车辆等。

• 购买能力：消费水平、败家指数等。

• 行为特征：活跃程度，购物类型，起居时间等。

• 兴趣偏好：品牌偏好，颜色偏好，价格偏好等。

在AI、图计算、时序、时空数据领域，标签数据也是关键的构成部分：

• AI领域：人工标注通常为标签，而预测结果中也可能包含标签信息。

• 图计算领域：无论是实体还是关系数据，都包含各类标签数据。

• 时序数据领域：可使用标签来描述不同的Timelines。

• 时空数据领域：基于时空条件查询时，也通常带有标签特征来进行结果过滤：如在地图上划定一个区域，查询在某一个时间区间内在该范围内出现过的具有某些特征的嫌疑人。

标签通常与某类实体对象(Entity)有关，每一个Entity所拥有的标签数量不等，这属于典型的半结构数据场景，HBase的"稀疏矩阵"模型天然适合存储这类数据，但HBase受限的查询能力却极大的限制了基于灵活标签组合条件的数据探索能力。CloudTable提出了一种新的HBase索引思路，能够基于预定义的规则自动提取标签并且构建标签索引，在TB/PB级别标签数据规模下，达到ms级别的组合标签ad-hoc查询能力。这套方案目前已经在推荐系统、用户画像标签平台以及某客户的时空搜索平台等多个项目中得到了应用。在2017年首届HBaseCon Asia大会上，我们曾经做过简单的披露，本文将呈现更丰富的内容。

本文内容共分为4个部分：

1. HBase为何适用于标签数据存储？

2. 现有的标签数据存储方案与技术挑战。

3. 基于倒排/位图索引的标签索引技术。

4. 方案设计思路简介。

HBase天然适合标签数据存储

HBase的数据表，是一种"稀疏矩阵"的结构，没有严格的列结构定义，或者说，每一行都可以拥有自己的列定义。

举例说明如下：

Row1: {[Age:10_20], [City:Shenzhen]}

Row2: {[Age:20_30], [Occupation:Teacher]}

Row3: {[Age:30_40], [City:Guangzhou], [Occupation:Accountant]}

注： 假设Row1, Row2, Row3为RowKey，而"{""}"中的部分为这一行数据中所包含的所有列，每一个"[""]"中的内容一个列。可以看出来：不同的行所包含的列的集合可能不同。

如果将拥有标签数据的对象称之为一个实体，实体可理解成人、车辆、手机号码、图片等等，每一个实体所拥有的标签数量是不固定的，这天然与HBase数据表的"稀疏矩阵"特点吻合，再结合HBase自身的高性能随机读写能力、强数据一致性、优秀的线性扩展能力等特点，促成了很多标签应用选型HBase作为数据存储系统。

现有技术难以满足标签数据需求

关于标签数据，支持灵活的标签组合条件查询(ad-hoc查询)是一个普遍的需求，但基于原生HBase接口能力却难以达成此需求，最关键的原因在于HBase仅仅支持基于RowKey的快速查询能力，这意味着原生HBase所能提供的查询场景是有限的、确定的。如果要支持标签组合条件的ad-hoc查询，需要对HBase进行扩展，或者依赖于第三方技术来实现。常见的实现