|
|
|
|
移动端

聊一聊用户画像如何存储

从个人角度来讲,在大数据领域接触比较多的的存储引擎有这几个:Hive(Hdfs)、Hbase、ES。这也会是我们在选择存储系统中几个主要的备选方案。

作者:木东居士来源:木东居士|2018-05-16 08:58

【新品产上线啦】51CTO播客,随时随地,碎片化学习

0x00 前言

随便聊一下用户画像的存储。

现在的用户画像,动不动就是几千几万个标签,标签一多就出现了一些需要克服的难题,比如下面两个:

  1. 如何解决频繁新增和删除标签的场景
  2. 如何解决不同标签更新时间和频率不同的问题

0x01 数据模型设计

从个人角度来讲,在大数据领域接触比较多的的存储引擎有这几个:Hive(Hdfs)、Hbase、ES。这也会是我们在选择存储系统中几个主要的备选方案。

优缺点就不再分析了。我们切入正题:数据模型该怎么设计?

一、横表

以Hive为例,我们最常用的就是横表,也就是一个 key,跟上它的所有标签。比如下面是一个简单的横表。

那么用横表有什么问题吗?有的,其实也就是前言里面提到的:

  1. 由于用户的标签会非常多,而且随着用户画像的深入,会有很多细分领域的标签,这就意味着标签的数量会随时增加,而且可能会很频繁。
  2. 不同的标签计算频率不同,比如说学历一周计算一次都是可以接收的,但是APP登录活跃情况却可能需要每天都要计算。
  3. 计算完成时间不同,如果是以横表的形式存储,那么最终需要把各个小表的计算结果合并,此时如果出现了一部分结果早上3点计算完成,一部分要早上10点才能计算完成,那么横表最终的生成时间就要很晚。
  4. 大量空缺的标签会导致存储稀疏,有一些标签会有很多的缺失,这在用户画像中很常见。

嗯,上述的问题,主要是当标签数量开始快速增多的时候会遇到的问题。标签量少的时候其实是不用担心这些的。

那么这些问题该怎么解决呢?这就是下面要聊得竖表。

二、竖表

竖表长下面这个样子:

这里就不再列举全部内容了,大概介绍一下,竖表其实就是将标签都拆开,一个用户有多少标签,那么在这里面就会有几条数据。

竖表能比较好地解决上面宽表的问题。但是它也会带来了新的问题,比如说多标签组合的查询需求:“我们想看年龄在23-30之间,月薪在10-20k之间,喜欢听古典音乐的女性”,这种多标签查询条件组合情况在竖表中就不太容易支持。

三、横表+竖表

如前面所分析,竖表和横表各有所长和所短,那么能不能两者结合呢?

这其实也要考虑横表和竖表的特性,整体来讲就是竖表对计算层支持的好,横表对查询层支持的好。那么设计的化就可以这样:

0x02 如何存储?

关于存储,我们以前文说的第三种方案为例。

标签的计算我们可以使用Hive、Spark这些计算引擎,这个没什么问题,然后就是这些标签的单独存储可以以Hive为主来存储。

那么在导入标签竖表的时候可以考虑两种存储引擎:Hive(Hdfs)和Hbase,其实笔者更倾向于Hbase,因为如果存在Hbase里的话会更方便查询。顺便再打上一个时间标签,用起来就更方便了。

最后,标签宽表的话可以考虑ES。另外需要注意的就是,从竖表往宽表到数据的时候需要做一层数据的加工,而且考虑到数据稀疏的情况的话,需要在宽表存储这里做一些优化。

【编辑推荐】

  1. spark 自己的分布式存储系统 - BlockManager
  2. Docker五种存储驱动原理及应用场景和性能测试对比
  3. 大话存储系列之磁盘娶亲(RAID)
  4. MySQL数据库存储IP地址的方法
  5. SSD硬盘成为数据中心主要存储的6个原因
【责任编辑:武晓燕 TEL:(010)68476606】


点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多

读 书 +更多

Java编程思想 第4版

本书共22章,包括操作符、控制执行流程、访问权限控制、复用类、多态、接口、通过异常处理错误、字符串、泛型、数组、容器深入研究、Java I...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊