标签存储与计算
Posted 宝哥大数据[离职找工作中，大佬帮内推下]
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了标签存储与计算相关的知识，希望对你有一定的参考价值。
文章目录
一、标签的管理
现在的用户画像，动不动就是 几千几万个标签 ，标签一多就出现了一些需要克服的难题，比如下面两个：
- 1）、如何解决频繁新增和删除标签；
- 2）、如何解决不同标签更新时间和频率不同的问题；
标签系统WEB Platform管理平台，主要创建标签、修改标签、删除标签及调度标签对应应用程序执行。
还有一个问题， 如果实现了这个管理系统，那么这个标签有可能是随着时间而发生变化的。比如 一个用户以前消费能力很弱，打了一个"屌丝"的标签，但一年之后这个用户消费能力提升 ，就需要对这个用户重新进行判定，如何实现？
二、标签的存储
在大数据领域接触比较多的的存储引擎有这几个：Hive、HBase、Elasticsearch/Solr，
这也在选择存储系统中几个主要的备选方案。
2.1、横表存储
以Hive为例，最常用的就是横表，也就是一个 key，跟上它的所有标签，比如下面是一个简单的横表。
可以看到每一列对应一个标签， 如果想生成这样的一张用户画像表， 其实要先找到每一列标签数据的计算应该需要哪些数据，如下：
1）、性别
2）、年龄
3）、学校
4）、订单和消费记录
这些字段可能来自于两张表：
1）、用户表（tbl_users)
2）、订单表(tbl_orders)
那现在的问题， 就是如何从这两张源表中得到用户画像表呢？ 可以通过 Hive SQL 来完成：
select gender, school from ods_tbl_user ；
当然，上面这段SQL是片面的， 并没有把所有字段计算出来，但是大家可以捕获到两点：
1）、数据从数仓来
ODS表示数据仓库中第一层
2）、可以使用 SQL 直接获取到目标表, 可以使用 CASE WHEN 或者 UDF 之类的方式计算指标
那么用横表有什么问题吗？
- 第一、由于用户的标签会非常多，而且随着用户画像的深入，会有很多细分领域的标签，这就意味着标签的数量会随时增加，而且可能会很频繁。
- 第二、不同的标签计算频率不同，比如说学历一周计算一次都是可以接收的，但是APP登录活跃情况却可能需要每天都要计算。
- 第三、计算完成时间不同，如果是以横表的形式存储，那么最终需要把各个小表的计算结果合并，此时如果出现了一部分结果早上3点计算完成，一部分要早上10点才能计算完成，那么横表最终的生成时间就要很晚（T+1）。
- 第四、大量空缺的标签会导致存储稀疏，有一些标签会有很多的缺失，这在用户画像中很常见。
上述的问题，主要是当标签数量开始快速增多的时候会遇到的问题。标签量少的时候其实是不用担心这些的。
2.2、竖表存储
竖表其实就是将标签都拆开，一个用户有多少标签，那么就会有多条数据 。
竖表能比较好地解决上面宽表的问题，但是它也会带来了新的问题，比如多标签组合的查询需求：“年龄在23-30，月薪在10-20k，喜欢听古典音乐的女性”，这种多标签查询条件组合情况在竖表中就不太容易支持。
2.3、横表+竖表存储
如前面所分析，竖表和横表各有所长和所短，那么能不能两者结合呢？这其实也要考虑横表和竖表的特性，整体来讲就是竖表对计算层支持的好，横表对查询层支持的好。那么设计的化就可以这样：
标签的计算可以使用Hive、Spark这些计算引擎，这个没什么问题，然后就是这些标签的单独存储可以以Hive或HBase为主来存储。
在导入标签竖表的时候可以考虑两种存储引擎：Hive（HDFS）和HBase，其实更倾向于HBase，因为如果存在HBase里的话会更方便查询。顺便再打上一个时间标签，用起来就更方便了。
标签宽表的话可以考虑Elasticsearch/Solr。另外需要注意的就是，从竖表往宽表到数据的时候需要做一层数据的加工，而且考虑到数据稀疏的情况的话，需要在宽表存储这里做一些优化。
三、Spark 计算标签
使用 Spark Application 的方式来计算， 每一个Application 计算一个标签，最终合并进一张画像表 ， 如下：
项目中每个标签对应一个模型，每个模型就是一个Spark Application，如下图目录结构：
以上是关于标签存储与计算的主要内容，如果未能解决你的问题，请参考以下文章