电商用户画像（下） http://sanwen.net/a/bawuobo.html
商品标签存储在hbase的product_tags表
格式为，
用户标签存储在hbase的user_tags表
格式为，
实际生产环境中，HBase会有不少坑，离线写可以通过bulkload等批量写的方式，但是对于在线读，应避免特别大的Scan,我们把画像的数据也写在了分布式索引的Solr，对于批量读，或者二级索引可以优先走Solr,其次再考虑HBase的二级索引，减少HBase的压力。
实践过程
3.3主题推荐标签、用户命名实体等新增标签补充进画像
主题推荐标签
主题和标签的映射关系：
使用标签表中的关键词列表，结合商品的评论、标题数据给商品打标签。
商品打标签公式为：
商品标签存储在hbase的product_tags表
格式为，
用户打标签公式为：
用户标签存储在hbase的user_tags表
格式为，
值得注意的是，在这一步需要统计平均每个用户被打上标签的数量。针对标签稀疏问题，我们在3.3中尝试使用CF对用户标签做平滑处理。
用户命名实体识别的标签
通过用户历史订单地址做地址结构化,再对结构化中的地址做用户命名实时识别,最后对每一个用户的地址做地址匹配,即可识别出用户的公司、小区、校园标签，具体实现方法见作者在2015年qcon上的分享，识别的命名实时数目如下：
3.4HBase的离线和在线分离、KV读和批量读分离
离线Hadoop任务会对数据库某段时间I/O频繁访问，影响实时的性能，把离线和实时的集群分开。在离线集群上应用bulkload生成HBase的元文件hfile，在实时线上集群上拉取离线集群的hfile：
Hadoop dfs -cp hftp://ip1:port/userProfileBulkLoad hdfs://ip2:port / userProfileBulkLoad
实时线上集群通过LoadIncrementalHFiles命令，补上丢失的增量数据：
HBase org.apache.Hadoop.HBase.mapreduce.LoadIncrementalHFiles / userProfileBulkLoad userProfile
这样做避免了对数据库频繁写入的压力，也避免了离线任务对实时任务的影响。
另外，实际生产环境中，HBase会有不少坑，离线写可以通过bulkload等批量写的方式，但是对于在线读，应避免特别大的Scan,我们把画像的数据也写在了分布式索引的Solr，对于批量读，或者二级索引可以优先走Solr,其次再考虑HBase的二级索引，减少HBase的压力。
3.5画像性能优化
处理逻辑和规则
a)离线部分的track解析迁移至统一的行为解析数据库，在加快运行速度的同时，还可以提高行为解析的准确率。
待商榷：
用户行为数据设计到userid和guid：
1)在同一sessionid中，若userid出现过，则该sessionid中的所有行为对应至该userid
2)在guid和userid的对应关系中，滤掉公用电脑和黄牛账户；
b)为了进一步提高离线部分的计算速度，用户的行为权重计算亦可以增量计算。
设Wh为用户对某个类目的历史行为权重，Wc为用户最新一天的行为权重，则总的行为权重
Wt = λWh + Wc, 0<λ<1
采用此权重，带入模型，计算偏好。
然后更新Wh = Wt。
如果采用上述方法，则不必遍历用户的所有的行为数据，每次更新时，只需遍历一天的数据即可。
3.6数据存储优化
画像离线与在线数据的存储结构
离线的数据结构采用Hive。
在线的数据存储：第一版画像的数据存储在Hbase中，每天可支撑数千万次的访问，时延10ms左右，性能尚可，并且存储的数据量是TB级，如果用传统的数据库，随着标签急速的增加，势必要不停的分表，存储的扩展性不是很好，新版画像的在线存储系统仍然使用HBase。考虑到类目偏好使用比较频繁，而导购属性偏好数据量远大于类目偏好，将两者分开存储。
类目偏好离线数据结构-Hive
离线的全量数据进行过滤之后，导入在线部分。过滤原则:
a)每个用户的偏好类目数量小于一个固定值
b)用户偏好得分大于下限，该下限可假设用户当天在某个类目只有一个加车行为，然后带入模型反推出来
类目偏好在线数据结构-HBase
Rowkey: userid,
ColumnFamily:category_level
Column:category_id
Value: weight
导购属性偏好离线数据结构-Hive
离线的全量数据进行过滤之后，导入在线部分。过滤原则:
属性偏好大于一个固定的下限
属性值的数量小于一个上限
属性值偏好大于一个固定下限
效果评价
画像系统使得公司广告投放ROI提升3%；
实时画像（意图）对猜你喜欢栏位的共享占比60%多
首页大轮播的GMV提升千分之三；
应用到首页猜你喜欢、团购、闪购、搜索、推荐、营销等栏位或者产品；
了解受众群体的变迁，适时推出适合的产品；
降低自营商品的采购数量，指导了厂商优化产品结构
基于标签画像的千人千面上线效果:
推广建议
提炼出该案例（或项目）的哲理、方法论。
算法准确度、数据规模、更新速度相互制衡，提高某些指标，必须牺牲其他指标
一个系统遇到性能瓶颈的时候，适度分解系统，以满足不同场景
系统给在线栏位用的时候，一定得考虑降级和延迟环境
数据流各个环节都可能出错，自动化检查各个节点的中间数据
系统演进的时候，有不同的方案，争取多数人支持，减少一个人拍板的方案
不同版本开发的时候，适度换些开发者，融入新的思路，避免少数人思维定式
避免运营驱动，不同时期，过来新的标签需求，如果研发团队只管添加，大部分标签会沉睡，后面基本用不到。研发团队首先确定自己的标准和规范，以筛选新需求的标签和排优先级
数据驱动，通过观察和研究数据，对数据有一定的敏感度，产生新的用户画像数据。
作者简介
陈敏敏
1号店精准化部门架构团队负责人，《Storm技术内幕与大数据实践》一书作者，在此之前曾服务于微软和三星电子等公司，长期从事大数据、搜索和推荐平台相关工作，目前主要关注于NoSQL、实时计算框架、推荐、大数据营销等相关技术。
