用户画像项目笔记3

用户画像标签的设计

需求简单明了: 用户标签的数量多少(以权重来表示) 
为方便管理 不同的标签分类(以模块来表示)
字段 gid, 模块名,标签名,标签值,权重

主题分类

人口属性模块、注册信息、终端设备、消费订单属性、消费商品退拒属性、生命周期、活跃属性、事件行为属性、商品偏好属性、价值属性、DSP属性、APP属性、兴趣类关键字、活跃地域标签

• 主题和标签由字典表构成

商城系统行为日志数据

用户终端属性、访问行为属性、活跃属性、偏好属性

商城系统业务数据

消费订单类属性、消费商品类、价值属性、注册信息

DSP系统竞价日志数据

广告栏位名称、广告平台商、兴趣关键词标签、终端属性、App属性

移动运营商流量日志

终端属性、购物类兴趣关键字、App属性

标签的抽取

每个值都是一个标签
不同日志抽取的标签合并用union合并标签

功能：将当日的标签计算结果，整合历史（前一日）标签结果

要考虑的点：
1. 当日可能有新的人
2. 历史记录中的人，当日可能没出现
3. 历史记录中的人，当日有新标签
4. 历史记录中的人，当日出现出现过的标签
5. 历史记录中的人，有标签当日没有出现
总结出来就是：
-- 对有权重的数据
历史标签  full join  当日标签
2. 历史有，当日有，权重累加
3. 历史有，当日无，权重衰减  (应该有衰减系数字典)
4. 历史无，当日有，取当日
-- 对无权重的数据
无权重标签，都是数仓报表中出来的，而数仓报表的数据，每天抽过来其实都是历史以来积累到当日的全量结果！
直接取当日数据！

----知识库构建------------
1. 地理位置字典构建
	-- geohash
	-- 高德地图开发api使用
	
2. app信息知识库构建
3. url内容知识库构建
	-- java爬虫
	-- css选择器
	-- jsoup  selenium  chromedriver
	-- 反爬：检查useragent/检查一个ip上的请求量/重要数据用ajax异步请求/登录拦截
	-- 应对反爬-- useragent设置/切换代理服务器/控制爬取速度/selenium即所得/设置cookie
	
4. idmp字典构建
	-- 图计算（为了不借助外部存储直接找出id之间的关联关系）
	-- 最大连通子图
	-- 注意点：过滤弱关联
	
-----数据预处理--------
1. 商城系统用户行为日志
2. dsp竞价日志
3. cmcc流量日志
	清洗、过滤  -- 脏数据的处理（filter，字段数不够，某些字段为空的，数据解析失败的）
	解析  -- （切字段、json解析）
	集成  -- （根据日志中的一个字段，去外部匹配更多的信息，追加到结果中： skuid->sku信息）
	格式转换  -- （最终结果统一成parquet格式）

-----事实标签提取--------
******《标签主题体系》******
1. 商城系统用户行为日志
2. dsp竞价日志
3. cmcc流量日志
4. 用户订单统计报表
5. 用户商品统计报表
6. 用户注册信息（注册手机、注册账号、注册性别、注册年龄、注册时间、注册方式（app上注册、pc上注册、微信小程序注册）、注册渠道（自发、百度搜索、x广告推广来的、x活动推广来的））

提取的标签有哪些？
*人口属性信息
*注册信息
*终端属性信息
*商品偏好信息
	- 品类偏好
	- 品牌偏好
	- 价格偏好 :  30天内的商品消费价格区间偏好: 2   -9999.9
	    rangeid,rangename
	 	1,       0-50
	 	2,       50-100
	 	3,       100-200
	 	4,       200-400
	 	5,       400-600
	 	6,       600-800
	 	7,       800-1000
    - 颜色等商品属性偏好：
	- 商品相关关键字偏好：瀑布屏:89   黑科技：10   

*活跃属性	
	- 第一次访问时间
	- 最近一次访问时间
	- 30天内总访问次数
	- 30天内总访问时长
	- 30天内总访问深度
	- 7天内
	- .....
	- 30天内的平均访问间隔
	- ......
	- 30天内收藏总次数
	- 30天内点赞总次数
	- 30天内好评总次数
	- 30天内差评总次数
	- 30天内分享总次数
	
*消费属性
	- 首单时间
	- 末单时间
	- 累计消费总额
	- 累计客单价
	- 累计消费笔数
	- 最大单笔消费额
	- 最小单笔消费额
	- 30天内消费总额
	- 30天内客单价
	- 30天内消费笔数
	- 30天内单笔消费额
	- 30天内单笔消费额
	- 14天内消费总额
	- 14天内客单价
	- 14天内消费笔数
	- 14天内单笔消费额
	- 14天内单笔消费额
	- 7天内消费总额
	- 7天内客单价
	- 7天内消费笔数
	- 7天内单笔消费额
	- 7天内单笔消费额
	- .........
	- 0-2点下单次数
	- 2-4点下单次数
	- 4-6点下单次数
	- 6-8点下单次数
	- 8-10点下单次数
	- .....
	

*兴趣关键词	（主要来自于dsp日志和cmcc日志）
	- 新闻类
	- 体育类
	- 娱乐类
	- 影视类

*DSP广告业务标签
	广告栏位
	广告平台
	.....
	
******《标签统一计算模型》******
一条数据，n个字段对画像有意义，每个字段变成一个标签，然后横表变竖表，就可以用统一的计算方式来计算（wordcount）
标签 ==》   模块名(id)：标签名(id)：标签值：权重



-----事实标签当日聚合--------
有权重：对相同人的相同标签，分组累加聚合
无权重：


-----事实标签T-1日和T日聚合--------
有权重： 跟T-1日的full join，该累加累加，该衰减衰减（引用外部的系数字典表及衰减算法，不同标签有不同衰减速度）
无权重： 跟T-1日的full join，有新的就用新的，没有新的保留旧的


-----模型（挖掘）标签 --------
-- 价值指数
-- 流失率
-- 退拒风险
-- 黄牛预测

/*****************************************标签明细层******相当于数仓的DWD层*******************************************/




-----画像数据的运营系统（精准营销、精细化运营的分析平台、驾驶舱）---------相当于数仓的DWS和ADS层-------



-----数据入库 -----------------------------
画像标签明细数据入库 -- hbase  （bulkloader导入）
各类画像运营分析报表的入库 -- 写入mysql  

画像结果入库

可能需要根据一个用户的某个标识，查询到这个人的整条或者某些标签数据！

而且，数据量比较庞大（画像数据中人数千万级、亿级）
（假如公司有用户1千万,标签有： 1000 w * 15模块 *10标签 * 3个值 = 45亿个标签）

那么，我们可以选择什么样的数据库来支撑这些需求呢？
mysql是否可以？ 数据量小一点可以（百万级别-千万级别），数据量大不合适
	优点：查询功能特别强大，速度快，可以写各种复杂sql查询
	缺点：数量规模不能太大，而且不便于动态增长！不太适合半结构化数据！（明细标签数据是一个稀疏表）

hbase是否可以？ 可以！
	优点：数据规模可以很庞大，而且支持动态增长！非常适合存储稀疏表！
	缺点：支持的查询功能简单！对复杂查询的支持非常弱！
缺点的改善方案：
创建二级索引！
或者使用phoenix（可以支持创建二级索引，可以支持复杂sql查询，而且查询性能在hbase原生api基础上还有提升！）
	
elastic search(不是数据库，全文检索引擎)是否可以？ 可以！
	优点：  数据规模可以比较大（亿级别，10亿就需要深入优化）！
条件查询很方便（全文索引）！
聚合统计查询也能支持！（相比hive、mysql来说，还是很弱的）
	缺点： 对复杂查询分析的支持不够强！