3.用户画像：方法论与工程化解决方案 --- 标签数据存储

3.用户画像：方法论与工程化解决方案 --- 标签数据存储

第3章　标签数据存储
3.1　Hive存储
	3.1.1　Hive数据仓库
		建立用户画像首先需要建立数据仓库，用于存储用户标签数据。Hive是基于Hadoop的数据仓库工具，依赖于HDFS存储数据，提供的sql语言可以查询存储在HDFS中的
	数据。

		数据仓库：一个面向主题的、集成的、非易失的、随时间变化的、用来支持管理人员决策的数据集合。
			1.面向主题
				业务数据库中的数据是针对事务处理，各个业务系统之间是互相分离的，而数据仓库之间的数据是按照一定主题进行组织的。

			2.集成
				数据仓库中存储的数据是从业务数据库中提取出来的，但并不是对原有数据的简单复制，而是经过了抽取、清洗、转换(ETL)等工作。业务数据库记录的是
			每一项业务处理的流水账。这些数据并不适合进行分析处理，进入数据仓库之前需要经过一系列计算，同时抛弃一些无关分析处理的数据。

			3.非易失
				业务数据库中一般只存储短期数据，因此其数据是不稳定的，记录的是系统中数据变化的瞬态。数据仓库中的数据大多表示过去某一时刻的数据，主要用于
			查询、分析，不像业务系统中的数据库一样经常修改，一般数据仓库构建完成后主要用于访问、不进行修改和删除。

			4.随时间变化
				数据仓库关注的是历史数据，按时间顺序定期从业务库和日志库里面载入新的数据进行追加，带有时间属性。

		在数据仓库建模的过程中，主要涉及 事实表 和 维度表 的建模开发。
			1.事实表
				主要围绕业务过程设计，就应用场景来看主要包括 事务事实表，周期快照表和累计快照事实表。
					a) 事务事实表
						用于描述业务过程，按业务过程的单一性或多业务过程可进一步分为单事务事实表和多事务事实表。其中单事务事实表分别记录每个业务过程，如下单
					业务记入下单事实表，支付业务记入支付事实表。多事务事实表在同一个表中包含不同业务过程，如下单、支付、签收等业务过程记录在同一张表中，通过
					新增字段来判断属于哪一个业务过程。当不同业务过程有着相似性时可考虑将多业务过程放到多事务事实表中。

					b) 周期快照表
						在一个确定的时间间隔内对业务状态进行度量。例如查看一个用户近一年付款金额、近1年购物次数、近30天登陆天数等。

					c) 累计快照表
						用于查看不同事件之间的时间间隔，例如分析用户从购买到支付的时长、从下单到订单完结的时长等。一般适用于有明确时间周期的业务过程。

			2.维度表
				主要用于对事实属性的各个方面描述，例如，商品维度包括商品的价格、折扣、品牌、原厂家、型号等方面信息。维度表的开发过程中，经常会遇到维度缓慢变化的
			情况，对于缓慢变化维一般会采用：
				1.重写纬度值，对历史数据进行覆盖；
				2.保留多条记录，通过插入维度列字段加以区分；
				3.开发日期分区表，每日分区数据记录当日维度的属性；
				4.开发拉链表按时间变化进行全量存储等方式进行处理。

				在画像系统中主要使用Hive作为数据仓库，开发相应的维度表和事实表来存储标签、人群、应用到服务层的相关数据。

	3.1.2　分区存储
		如果将用户标签开发成一张大的宽表，在这张宽表下放着几十种类型标签，那么每天该画像宽表ETL作业将会花费很长时间，而且不便于向这张宽表中新增标签
	类型。要解决这种ETL花费时间较长的问题，可以从下面几个方面入手：	
		1.将数据分区存储，分别执行作业；
		2.标签脚本性能调优；
		3.基于一些标签共同的数据来源开发中间表。


		为了提高数据的插入和查询效率，在Hive中可以使用分区表的方式，将数据存储在不同的目录中。在Hive中select查询时一般会扫描整个表中所有的数据，
	将会花费很多时间扫描不是当前要查询的数据，为了扫描表中关心的一部分数据，在建表时引入了partition的概念。在查询时，可以通过Hive的分区机制来控制
	一次遍历的数据量。

	3.1.3　标签汇聚
		上述把用户的每个标签都插入了相应的分区下面，但是对一个用户来说，打在他身上的全部标签存储在不同的分区下面。为了方便查询和分析，需要将用户身上的
	标签做聚合处理。

		标签汇聚后将一个每个用户身上的全量标签汇聚到一个字段中，

	3.1.4　ID-MAP
		开发用户标签的时候，有项非常重要的内容---ID-MApping，即把用户不同来源的身份标识通过数据手段识别为同一个主体。用户的属性、行为相关数据分散
	在不同的数据来源中，通过ID-MApping能够把用户在不同场景下的行为串联起来，消除数据孤岛。

		举例来说，用户在未登录App的状态下，在App站内访问、搜索相关内容时，记录的是设备id(cookieid)相关的行为数据。而用户在登录App后，访问，收藏，
	下单等相关的行为记录的是账号id(userid)相关的行为数据。虽然是同一个用户，但其在登录和未登录设备时记录的行为数据之间是未打通的。通过ID-MApping
	打通userid和cookied的对应关系，可以在用户登录、未登录设备时都能捕获其行为轨迹。

		缓慢变化维 是在维表设计中常见的一种方式，维度并不是不变的，随时间也会发生缓慢变化。如用户的手机号、邮箱等信息可能会随着用户的状态变化而变化。
	拉链表是针对缓慢变化维表的一种设计方式，记录一个事务从开始到当前状态的全部状态变化信息。


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

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

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

		a)标签计算数据监控
			主要用于监控每天标签ETL的数据量是否出现异常，如果有异常情况则发出告警邮件，同时暂停后面的ETL任务。

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

			在对画像的数据监控中，调度流每跑完相应的模块，就将该模块的监控数据插入mysql中，当校验任务判断达到触发告警阈值时，发送告警邮件，同时
		中断后续的调度任务。

	3.2.3　结果集存储
		结果集可以用来存储多维透视分析用的标签、圈人服务用的用户标签。当日记录各标签数量，用于校验标签数据是否出现异常。

		有的线上业务系统使用mysql,、Oracle等关系型数据库存储数据，如短信系统，消息推送系统等。在打通画像数据与线上业务系统时，需要考虑将存储在Hive
	中的用户标签数据同步到各个业务系统，此时mysql可用于存储结果集。

		Sqoop是一个用来将Hadoop和关系型数据库中的数据互相迁移的工具。它可以将一个关系型数据库中的数据导入Hadoop的HDFS中，也可以将HDFS中的数据导入
	到关系型数据库中。


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

		画像系统中每天在Hive里跑出的结果集数据可同步到Hbase数据库，用于线上实时应用的场景。

		下面介绍几个基本概念：
			1.row key
				用来表示唯一一行记录的主键，Hbase的数据是按照row key 的字典顺序进行全局排序的。访问Hbase中的行只有3种方式：
					a) 通过单个row key访问；
					b) 通过row key 的正则访问；
					c) 全表扫描。

				由于Hbase通过rowkey对数据进行检索，而rowkey由于长度限制的因素不能将很多查询条件拼接在rowkey中，因此Hbase无法像关系型数据库
			那样根据多种条件对数据进行筛选。一般的，Hbase需要建立二级索引来满足根据复杂条件查询数据的需求。

				row key设计时需要遵循三大原则：
					1.唯一性原则
						rowkey需要保证唯一性，不存在重复的情况。在画像中一般使用用户id作为rowkey。

					2.长度原则
						rowkey的长度一般为10~100bytes。

					3.散列原则
						rowkey的散列分布有利于数据均匀分布在每个RegionServer，可实现负载均衡。

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

	3.3.2　应用场景

	3.3.3　工程化案例

		Hive 数仓 => Hive2Hbase => Hbase => API接口 => 线上服务

		在线接口在查询Hbase中数据时，由于Hbase无法像关系型数据库那样根据多种条件对数据进行筛选(类似于where)。一般的Hbase需要建立二级索引来
	满足根据复杂条件查询数据的需求，本案例中选用es存储Hbase索引数据。


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

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

		为了既能支持对数据的高效查询，同时也能支持通过条件筛选进行复杂查询，需要在hbase上构建二级索引，以满足对应的需求。本案例中选用es存储hbase
	的索引信息，以支持复杂高效的查询功能。	

		hbase数据存储数据的索引放在es中，实现了数据和索引的分离。

	3.4.3　工程化案例


3.5 小结
	Hive存储数据相关标签表、人群计算表的表结构设计以及ID-Mapping的一种实现方式；MySQL存储标签元数据、监控数据及结果集数据；Hbase存储线上接口
实时调用的数据；es 存储标签用于人群计算和人群多维度透视分析。