用户画像特征及标签存储

 

hive 存储  ： 存储数据相关标签表、人群计算表的表结构设计以及ID-Mapping的一种实现方式

建立用户画像首先需要建立数据仓库，用于存储用户标签数据。Hive是基于Hadoop的数据仓库工具，依赖于HDFS存储数据，提供的SQL语言可以查询存储在HDFS中的数据。开发时一般使用Hive作为数据仓库，存储标签和用户特征库等相关数据

mysql 存储  ： 存储标签元数据、监控数据及结果集数据

MySQL作为关系型数据库，在用户画像中可用于元数据管理、监控预警数据、结果集存储等应用中。

Hive适合于大数据量的批处理作业，对于量级较小的数据，MySQL具有更快的读写速度。Web端产品读写MySQL数据库会有更快的速度，方便标签的定义、管理。

MySQL还可用于存储每天对ETL结果的监控信息。从整个画像调度流的关键节点来看，需要监控的环节主要包括对每天标签的产出量、服务层数据同步情况的监控等主要场景。

服务层一般采用HBase、Elasticsearch等作为数据库存储标签数据供线上调用，将标签相关数据从Hive数仓向服务层同步的过程中，有出现差错的可能，因此需要记录相关数据在Hive中的数量及同步到对应服务层后的数量，如果数量不一致则触发告警。

Hbase 存储 ： 存储线上接口实时调用的数据

HBase是一个高性能、列存储、可伸缩、实时读写的分布式存储系统，同样运行在HDFS之上。与Hive不同的是，HBase能够在数据库上实时运行，而不是跑MapReduce任务，适合进行大数据的实时查询。

row key：用来表示唯一一行记录的主键，HBase的数据是按照row key的字典顺序进行全局排列的。

访问HBase中的行只有3种方式：○通过单个row key访问；○通过row key的正则访问；○全表扫描。由于HBase通过rowkey对数据进行检索，而rowkey由于长度限制的因素不能将很多查询条件拼接在rowkey中，因此HBase无法像关系数据库那样根据多种条件对数据进行筛选。一般地，HBase需建立二级索引来满足根据复杂条件查询数据的需求。

Rowkey设计时需要遵循三大原则：○唯一性原则：rowkey需要保证唯一性，不存在重复的情况。在画像中一般使用用户id作为rowkey。○长度原则：rowkey的长度一般为10-100bytes。○散列原则：rowkey的散列分布有利于数据均衡分布在每个RegionServer，可实现负载均衡。

❑columns family：指列簇，HBase中的每个列都归属于某个列簇。列簇是表的schema的一部分，必须在使用表之前定义。划分columns family的原则如下：○是否具有相似的数据格式；○是否具有相似的访问类型。

Elasticsearch 存储  ： 存储标签用于人群计算和人群多维透视分析

Elasticsearch是一个开源的分布式全文检索引擎，可以近乎实时地存储、检索数据。而且可扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。

对于用户标签查询、用户人群计算、用户群多维透视分析这类对响应时间要求较高的场景，也可以考虑选用Elasticsearch进行存储。Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用json作为文档格式。

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

应用场景

基于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索引关联的问题。

流失标签存储

Spark Streaming是Spark Core API的扩展，支持实时数据流的处理，并且有可扩展、高吞吐量、容错的特点。数据可以从Kafka、Flume等多个来源获取，可以使用map、reduce、window等多个高级函数对业务逻辑进行处理。最后，处理后的数据被推送到文件系统、数据库等。

在内部Spark Streaming接收实时数据流并将数据分成多个batch批次，然后由Spark引擎进行处理，批量生成结果流。Spark Streaming提供了一个高层抽象，称为Discretized Stream或Dstream，它表示连续的数据流。Dstream可以通过Kafka、Flume等来源的数据流创建，也可以通过在其他Dstream上应用高级操作来创建。

 

Kafka的核心功能是作为分布式消息中间件。Kafka集群由多个Broker server组成，其中，消息的发送者称为Producer；消息的消费者称为Cousumer；Broker是消息处理的节点，多个Broker组成Kafka集群；Topic是数据主题，用来区分不同的业务系统，消费者通过订阅不同的Topic来消费不同主题的数据，每个Topic又被分为多个Partition，Partition是topic的分组，每个Partition都是一个有序队列；offset用于定位消费者在每个Partition中消费的位置。Kafka对外使用Topic概念，生产者向Topic里写入消息，消费者从Topic中读取消息。一个Topic由多个Partition组成。生产者向Brokers指定的Topic中写消息，消费者从Brokers里面拉取指定的Topic消息，然后进行业务处理。

Spark Streaming可以通过Receiver和Direct两种模式来集成Kafka。在Receiver模式下，Spark Streaming作为Consumer拉取Kafka中的数据，将获取的数据存储在Executor内存中。但可能会因为数据量大而造成内存溢出，所以启用预写日志机制（Write AheadLog）将溢出部分写入到HDFS上。在接收数据中，当一个Receiver不能及时接收所有的数据时，再开启其他Receiver接收，它们必须属于同一个Consumer Group，这样可以提高Streaming程序的吞吐量（如图4-21所示）。整体来说，Receiver模式效率较低，容易丢失数据，在生产环境中使用较少。

流程

❑读取数据源，这里讲解消费Kafka中的数据；❑解析数据，即解析消费的Kafka数据；❑将解析后的数据存储到指定位置（如MySQL、HDFS、HBase等）；❑存储消费的Offset，Direct模式下需要保存消费到的位置。