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的对应关系，可以在用户登录、未登录设备时都能捕获其行为轨迹。

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