0. 相关文章链接

1. Elasticsearch简介

Elasticsearch是一个开源的分布式全文检索引擎，可以近乎实时地存储、检索数据。而且可扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。对于用户标签查询、用户人群计算、用户群多维透视分析这类对叩应时间要求较高的场景，也可以考虑选用 Elasticsearch进行存储。

Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用json作为文档格式。为了更清晰地理解Elasticsearch查询的一些概念，将其和关系数据库的类型进行对照，如下图所示。

在关系型数据库中查询数据时可通过选中数据库、表、行、列来定位所查找的内容，在Elasticsearch中通过索引（index）、类型（type）、文档（document）、字段来定位查找内容。一个Elasticsearch集群可以包括多个索引（数据库），也就是说，其中包含了很多类型（表），这些类型中包含了很多的文档（行），然后每个文档中又包含了很多的字段（列）.Elasticsearch的交互可以使用 Java API,也可以使用HTTP的RESTful API方式。

2. 应用场景

基于HBase的存储方案并没有解决数据的高效检索问题。在实际应用中，经常有根据特定的几个字段进行组合后检索的应用场景，而 HBase采用rowkey作为一级索引，不支持多条件查询，如果要对库里的非rowkey进行数据检索和查询，往往需要通过MapReduce等分布式框架进行计算，时间延迟上会比较高，难以同时满足用户对于复杂条件查询和高效率响应这两方面的需求。

为了既能支持对数据的高效查询，同时也能支持通过条件筛选进行复杂查询，需要在HBase上构建二级索引，以满足对应的需要。我们可以采用Elasticsearch存储HBase的索引信息，以支持复杂高效的查询功能。

主要查询过程包括：
1）在Elasticsearch中存放用于检索条件的数据，并将rowkey也存储进去；
2）使用Elasticsearch的API根据组合标签的条件查询出rowkey的集合；
3）使用上一步得到的rowkey去HBase数据库查询对应的结果（如下图）；

HBase数据存储数据的索引放在Elasticsearch中，实现了数据和索引的分离。在Elasticsearch中documentid是文档的唯一标识，在 HBase中rowkey是记出的唯一标识。在工程实践中，两者可同时选用用户在平台上的唯一标识（如userid或deviceid）作为rowkey或 documentid,进而解决HBase和Elasticsearch索引关联的问题。

下面通过使用Elasticsearch解决用户人群计算和分析应用场景的案例来了解这一过程。

对汇聚后的用户标签表 dw.userprofile_userlabel_map_all中的数据进行清洗，过滤掉一些无效字符，达到导入Elasticsearch的条件，如下图所示。

然后将dw.userprofile_userlabel_map_all数据写入 Elasticsearch中，之后需要数据就可以直接从Elasticsearch中获取数据了，对比使用Impala从Hive中进行计算，效果可以从原先的几十秒到几分钟优化到现在的秒级响应。

3. 工程化案例

下面通过一个工程案例来讲解实现画像产品中“用户人群”和“人群分析”功能对用户群计算秒级响应的一种解决方案。

在每天的ETL调度中，需要将Hive计算的标签数据导入 Elasticsearch中。如图3-28所示，在标签调度完成且通过校验后（如下图中的“标签监控预警”任务执行完成后），将标签数据同步到 Elasticsearch中。

在与Elasticsearch数据同步完成并通过校验后，向在MySQL中维护的状态表中插入一条状态记录，表示当前日期的Elasticsearch数据可用，线上计算用户人群的接口则读取最近日期对应的数据。如果某天因为调度延迟等方面的原因，没有及时将当日数据导入 Elasticsearch中，接口也能读取最近一天对应的数据，是一种可行的灾备方案。

例如，数据同步完成后向MySQL状态表“elasticsearch_state”中插入记录（如下图所示），当日数据产出正常时，state字段为“0”，产出异常时为“1”。图3-29中1月 20日导入的数据出现异常，则“state”状态字段置1,线上接口扫描该状态记录位后不读取1月20日数据，而是取用最近的1月19日数据。

为了避免从Hive向Elasticsearch中灌入数据时发生数据缺失，在向状态表更新状态位前需要校验Elasticsearch和Hive中的数据量是否一致。还需要通过其他脚本来看数据校验逻辑：

如上所示就是在工程化调度流中何时将Hive中的用户标签数据灌入 Elasticsearch中，之后业务人员在画像产品端计算人群或透视分析人群时（如下图1所示），通过RESTful API访问Elasticsearch进行计算（如下图2所示）。

4. 用户画像标签数据存储总结

在前面的几篇博文中讲解了使用Hive、MySQL、HBase和Elasticsearch存储标签数据的解决方案，包括：Hive存储数据相关标签表、人群计算表的表结构设计以及ID-Mapping的一种实现方式；MySQL存储标签元数据、监控数据及结果集数据；HBase存储线上接口实时调用的数据； Elasticsearch存储标签用于人群计算和人群多维透视分析。存储过程中涉及如下相关表。

dw.userprofile_attritube_all：存储人口属性维度的标签表；
dw.userprofile_action_all：存储行为属性维度的标签表；
dw.userprofile_consume_all：存储用户消费维度的标签表；
dw.userprofile_riskmanage_all：存储风险控制维度的标签表；
dw.userprofile_social_all：存储社交属性维度的标签表；
dw.userprofile_userlabel_map_all：汇聚用户各维度标签的表；
dw.userprofile_usergroup_labels_all：存储计算后人群数据的表。

面向不同的工程场景使用不同的存储方案，本章通过“工程场景 +案例”的形式介绍了一种可实现的用户标签存储解决方案。

注：再次声明，此博文为根据 赵宏田 老师的 用户画像·方法论与工程化解决方案 一书读后笔记而来，仅供学习使用

注：其他相关文章链接由此进 -> 用户画像文章汇总