用户画像 | 标签数据存储之Hive真实应用

本文探讨了在用户画像系统中,如何利用Hive作为数据仓库存储用户标签数据。介绍了Hive数据仓库的概念,强调其面向主题、集成、非易失和随时间变化的特点。文章详细讲解了Hive的分区存储、标签汇聚和ID-MAP在用户画像中的应用,以及如何通过Hive进行ID-Mapping的数据清洗工作,以实现用户身份标识的统一。
摘要由CSDN通过智能技术生成

本文已收录github:https://github.com/BigDataScholar/TheKingOfBigData,里面有大数据高频考点,Java一线大厂面试题资源,上百本免费电子书籍,作者亲绘大数据生态圈思维导图…持续更新,欢迎star!

前言

        小伙伴们大家好呀,趁着年假的几天时间,我写了一篇 Elacticsearch 从0到1的“长篇大作”,现在还在排版,相信很快就会与大家见面了!关于系统学习用户画像,之前已经分享过2篇文章了,分别是《超硬核 | 一文带你入门用户画像》《用户画像 | 开发性能调优》,收到的读者反馈还不错!本期文章,我借《用户画像方法论》一书,为大家分享在用户画像系统搭建的过程中,数据存储技术基于不同场景的使用。考虑到 篇幅的文章,我会用4篇文章分别介绍使用 Hive、MySQL、HBase、Elasticsearch 存储画像相关数据的应用场景及对应的解决方案。本期介绍的是 Hive,如果对您有所帮助,记得三连支持一下!

Hive存储

        本期内容主要介绍使用Hive作为数据仓库的应用场景时,相应的库表结构如何设计。

Hive数据仓库

        建立用户画像首先需要建立数据仓库,用于存储用户标签数据。Hive是基于Hadoop的数据仓库工具,依赖于HDFS存储数据,提供的SQL语言可以查询存储在HDFS中的数据开发时一般使用Hive作为数据仓库,存储标签和用户特征库等相关数据。

        “数据仓库之父” W.H.Inmon 在《Building the Data Warehouse》一书中定义数据仓库是“一个面向主题的、集成的、非易失的、随时间变化的、用来支持管理人员决策的数据集合”。

  • 面向主题:业务数据库中的数据主要针对事务处理,各个业务系统之间是相互分离的,而数据仓库中的数据是按照一定主题进行组织的。
  • 集成:数据仓库中存储的数据是从业务数据库中提取出来的,但并不是对原有数据的简单复制,而是经过了抽取、清理、转换(ETL)等工作。业务数据库记录的是每一项业务处理的流水账。这些数据不适合进行分析处理,进入数据仓库之前需要经过一系列计算,同时抛弃一些无关分析处理的数据。
  • 非易失:业务数据库中一般只存储短期数据,因此其数据是不稳定的,记录的是系统中数据变化的瞬态。数据仓库中的数据大多表示过去某一时刻的数据,主要用于查询、分析,不像业务系统中的数据库一样经常修改,一般数据仓库构建完成后主要用于访问,不进行修改和删除。
  • 随时间变化:数据仓库关注的是历史数据,按时间顺序定期从业务库和日志库里面载入新的数据进行追加,带有时间属性。

        数据抽取到数据仓库的流程如下图所示。


        在数据仓库建模的过程中,主要涉及事实表和维度表的建模开发:

        事实表主要围绕业务过程设计,就应用场景来看主要包括事务事实表周期快照事实表累计快照事实表

  • 事务事实表:用于描述业务过程,按业务过程的单一性或多业务过程可进一步分为单事务事实表和多事务事实表。其中单事务事实表分别记录每个业务过程,如下单业务记入下单事实表,支付业务记入支付事实表。多事务事实表在同一个表中包含了不同业务过程,如下单、支付、签收等业务过程记录在一张表中,通过新增字段来判断属于哪一个业务过程。当不同业务过程有着相似性时可考虑将多业务过程放到多事务事实表中。
  • 周期快照事实表:在一个确定的时间间隔内对业务状态进行度量。例如查看一个用户的近1年付款金额、近1年购物次数、近30日登录天数等。
  • 累计快照事实表:用于查看不同事件之间的时间间隔,例如分析用户从购买到支付的时长、从下单到订单完结的时长等。一般适用于有明确时间周期的业务过程。


        维度表主要用于对事实属性的各个方面描述,例如,商品维度包括商品的价格、折扣、品牌、原厂家、型号等方面信息。维度表开发的过程中,经常会遇到维度缓慢变化的情况,对于缓慢变化维一般会采用:①重写维度值,对历史数据进行覆盖;②保留多条记录,通过插入维度列字段加以区分;③开发日期分区表,每日分区数据记录当日维度的属性;④开发拉链表按时间变化进行全量存储等方式进行处理。在画像系统中主要使用Hive作为数据仓库,开发相应的维度表和事实表来存储标签、人群、应用到服务层的相关数据。

分区存储

        如果将用户标签开发成一张大的宽表,在这张宽表下放几十种类型标签,那么每天该画像宽表的ETL作业将会花费很长时间,而且不便于向这张宽表中新增标签类型。

        要解决这种ETL花费时间较长的问题,可以从以下几个方面着手:

  • 将数据分区存储,分别执行作业;
  • 标签脚本性能调优;
  • 基于一些标签共同的数据来源开发中间表。

        下面介绍一种用户标签分表、分区存储的解决方案。

        根据标签指标体系的人口属性、行为属性、用户消费、风险控制、社交属性等维度分别建立对应的标签表进行分表存储对应的标签数据。如下图所示。

评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

大数据梦想家

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值