用户画像数据仓库建设实践

吵吵叭火

已于 2024-06-15 10:25:46 修改

阅读量1.4k

点赞数 13

分类专栏： # 用户画像文章标签：数据仓库大数据

于 2024-06-14 20:41:21 首次发布

本文链接：https://blog.csdn.net/SHWAITME/article/details/139689726

版权

用户画像专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、数据仓库

1.1 简介

简而言之，数据仓库是一个集成的、面向主题的、相对稳定的数据集合，它能够反映数据的历史变化。在构建数据仓库时，我们会根据不同的主题域对数据进行分类，并通过数据建模技术对数据进行重新组织和抽象，以便从更高的层次对分析对象进行一致且完整的描述，清晰地刻画出各种分析场景，涵盖企业各个方面的数据。

以流量主题域为例，我们可以清楚地知道这个主题域包含了企业所有系统的用户行为数据。数据仓库的集成性特性体现在它能够整合来自不同业务系统的数据。通过大数据采集框架和抽取工具，数据被统一存储在数据仓库中，并利用数据建模技术将一些同字同义、同数同表的数据组织成一致性事实与维度。

数据仓库的相对稳定性特性意味着数据一旦入库，通常会被长期保留。与关系型数据库相比，数据仓库中的新增、修改和删除操作较少，因为大部分操作都是查询。这种稳定性使得数据仓库能够记录历史数据和事件环境的变化，从而帮助企业对未来发展趋势做出合理的预测和判断。

1.2 价值

数据仓库的价值主要体现在以下几个方面：

快速存取数据：数据仓库统一了数据出口，使得业务人员无需访问各个业务系统来获取数据，从而大幅提升了数据获取和使用的效率。
高质量数据输出：数据仓库通过数据建模和数据质量保障措施，能够过滤掉业务系统中异常的数据，确保输出数据的质量。
响应业务变化：数据仓库的模型能够快速迭代，以满足不同业务场景的分析需求，适应业务的变化。
保障数据安全：对于企业敏感或隐私数据，数据仓库通过去脱敏或加密等手段确保数据安全，并控制数据的使用范围，实现对企业核心数据的细致管理。
及时数据服务：数据仓库能够根据不同需求提供不同粒度的数据服务，如天级、小时级甚至实时级数据，并在 OLAP 引擎的支持下实现数据的即席查询。
提高决策能力：企业可以通过数据仓库输出的核心指标来预测未来的发展趋势，做出合理的决策。

二、用户画像

2.1 简介

用户画像是对用户信息进行标签化处理的过程，它通过收集用户的社会属性、行为特征等信息来对用户进行描述，并对这些特征进行统计分析，以挖掘用户的潜在价值。为了快速收集用户行为数据并挖掘其价值，需要建立一个完善的大数据应用体系。

许多公司在构建大数据应用体系时投入了大量精力，不仅在基础平台建设上取得了进展，还产出了许多报表。然而，这些数据应用体系往往仅停留在报表阶段，仅供产品运营人员进行分析。

用户画像的作用在于，它可以帮助大数据走出数据仓库，通过精准化运营工具为用户提供个性化推荐、精准营销等多样化的数据服务。这样的服务不仅能够提升用户的体验，还能够增强数据的价值，使大数据真正成为推动业务发展的有力工具。

2.2 标签类型&标签体系

用户画像从生产者的角度来看，本质上是对用户进行打标签的过程。根据打标签的方法，可以将标签划分为两类：统计类标签和算法类标签。

统计类标签是最基础和最常见的标签类型，例如用户的访问城市区域商圈、访问天数等。这些标签是基于用户行为和预定义的计算口径生成的。
算法类标签是通过机器学习或者深度学习挖掘产生，用于对用户的某些属性或者某些行为进行预测判断。例如：根据用户行为特征预测用户的性别、年龄等。

58 同城的画像平台，按品牌划分，涵盖了 58 同城、安居客等品牌下的各类标签。根据每个品牌下不同的业务板块进一步细化标签体系，其中的统计类标签就是通过用户画像数仓来生成的。

三、用户画像数仓建设过程

3.1 画像数仓—背景&现状

首先，介绍一下数仓建设的背景。起初，接收的标签是由历史部门交接过来的，总共有大约 3000 个标签。这些标签涉及的计算口径和数据等信息，流失的非常严重。此外，标签生产流程主要是基于 MapReduce（MR）实现的，整个计算过程相当复杂，存在许多冗余的 ETL 任务，且对新的需求支持速度和问题处理效率都较低，再者，标签数据的产出时间非常晚，通常要到下午 2 点左右才能完成当天的 t+1 标签。

为了解决上述问题，进行了标签生产流程的重构，实施步骤主要包括以下两个阶段：

标签计算口径和数据源梳理：从梳理标签的计算口径开始，收集涉及的数据源信息，沉淀出一套完善的标签知识库。在这个过程中，我们还总结出了一套面向数据开发的指标定义规范。、
基于标准化数仓建设规范升级流程：根据标准化的数仓建设规范，升级整个标签生产流程，并沉淀了一套相对通用的数仓研发规范。

3.2 画像数仓—整体架构

画像数仓的整体架构如上图所示，自下而上分为三个层级：

3.2.1 垂直数据中心

这是按照不同业务板块划分的数据中心，集中了各个业务领域的资产，并提供了相对标准化的数据，例如用户行为数据、用户注册数据等。目前，画像数仓涵盖了大多数业务的用户数据，日处理数据量约为 20 TB。

3.2.2 公共数据中心

这个中心是按照不同的主题进行划分的，构建了面向不同分析需求的主题数仓。它包含了一些公共汇总数据和明细数据。例如，面向用户行为分析的场景，建设流量数仓提供给业务使用。

3.2.3 应用数据中心

位于公共数据中心之上，它面向不同的需求，产出个性化的指标。在用户画像分析场景中，会根据不同的标签需求和应用主题域产出相应的标签数据。

在整个数仓建设的生命周期，实施了一系列数据规范，包括建模规范、研发规范、指标定义规范等，以确保数仓架构的稳定性和健康性。

3.3 画像数仓—研发流程

画像数仓的研发流程，从需求沟通到数据验收，分为六个阶段：

需求沟通：这是流程的起始阶段，主要进行需求讨论和分析。
设计：这是流程中最重要的阶段，包括数据源信息的质量探查与分析、数据主题域划分、指标定义以及模型和 ETL 的设计。在这个阶段，数据开发团队需要输出设计文档，以便进行后续的技术评审。
技术评审：通过评审后，进入开发阶段。
开发：这一阶段主要是面向SQL编程的工作。
测试：开发完成后，进行测试以确保数据的准确性和完整性。
上线与验收：最后阶段，数据开发团队主要以辅助角色支持上线和验收工作。

3.4 画像数仓—指标定义

用户画像数仓是为了生产统计类标签而建设的数仓。指标定义的目的是为了快速辅助模型的设计，同时避免指标二义性以及重复建设的问题。

根据指标的性质可以将其分为三类：原子指标、派生指标和衍生指标。

原子指标：是基于某个业务事件的不可拆分的度量，构成要素：原子指标= 业务过程+度量值+聚合逻辑。例如支付金额、商品库存等，它们具有明确的业务含义。
派生指标：是在原子指标基础上增加了修饰词的指标，如时间类型的修饰词和与业务事件发生环境相关的修饰词。构成要素：派生指标 = 原子指标+ 统计周期+业务限定+统计粒度。例如，“近一天用户访问二手车类目的次数”中，访问次数是原子指标，近一天是时间周期类型的修饰词，二手车是类目相关的修饰词。
衍生指标：是基于派生指标复合而成的指标，如比例型、均值型指标等。

在处理数仓接收到的需求时，我们发现大部分是派生指标和衍生指标，原子指标本身并没有具体的业务分析价值，它们是与业务过程相关的一些度量。

在定义派生指标时，需要清晰定义派生指标所涉及的业务板块、所用数据的主题域、来源的业务过程，以及由哪些原子指标和修饰词组成。这样的定义有助于我们更准确地理解和处理数据仓库中的指标需求。

在建设画像数仓的过程中，还会遇到一类特殊的指标，例如“最近访问的终端类型”和“长访问房产类目”等标签。这些标签的特殊之处在于它们的计算结果是非数值类型的。这类指标通常根据它们的计算结果来定义，如果计算结果是单值文本类型，就将其定义为排名性指标；如果是多值文本类型，则定义为对象集合类型指标。

对于这两种特殊指标，我们在定义时会引入一些特殊的原子指标，并增加一些额外的修饰词，以便清晰地描述指标的计算口径。例如，“常访问房产类目”这个标签，其计算口径是“近 90 天内浏览时长 top5 的房产类目”。在这种情况下，我们会将类目集合定义为原子指标，并增加“统计方法”、“排名名次”、“排名范围”和“排名方式”等修饰词，以清晰地描述这个指标的计算口径。

3.5 画像数仓—建模方法论

常见的建模方法有以下四种：

3.5.1 ER模型

实体-关系模型，这种模型要求满足三范式原则，即每一列、每一行以及整张表的数据都具有原子性。ER 模型的优点在于它极大地消除了数据冗余，并且能够快速满足实体更新和实体间关系的更新。然而，在面向数据分析场景时，它的缺点是关联查询较多，且难以适应业务的频繁变化。

3.5.2 Data Vault 模型

这是在 ER 模型的基础上进一步规范化的模型，是一种中心辐射式模型，是 3NF 建模的衍生，其建模思想是围绕着业务键的集成模式。Data Vault 模型进一步消除了数据冗余，但在数据分析场景下，它也存在关联查询多和对数据建模要求高的问题。

3.5.3 Anchor 模型

这是一种 KV（键值）结构化的模型，相对于 Data Vault 模型，它进一步整合了数据。Anchor 模型的设计思想是所有实体只添加扩展，不进行修改，这使得它最易于实体扩展和业务变更。不过，相对于前两种模型，在进行数据分析时，它的成本更高，关联查询也更多。

3.5.4 维度建模

这是一种反规范化设计方法，从数据需求出发，同时服务于数据分析需求。它能够满足大规模复杂查询的性能需求，产出指标时关联查询较少，建模成本也较低。然而，与泛式建模相比，它对数据更新不太友好。

在选择建模方法时，用户画像作为一种分析数据场景，为了低成本、高效率地完成用户标签生产，选择维度建模作为方法论是最合适的。维度建模适用于那些需要快速、频繁地读取数据的分析场景，正好符合用户画像数仓的需求。

3.6 画像数仓—事实表

在维度建模中，事实表是关键的表类型，主要用于记录业务过程中的具体事件。事实表可以分为以下四种类型：

3.6.1 事务事实表

在维度建模中，任何类型的事件都可以被视为事务。这类事实表用于定义和追踪业务过程中的个体行为，作为数仓的明细数据，提供了丰富的数据分析能力。在画像数仓中，用户行为事实表是一种特殊的事实表，其特点是没有度量。对于用户访问 58 同城 APP 来说，对于每次点击，其度量都为 1，这种度量通常不会在事实表中保存。

3.6.2 周期快照事实表

与事务事实表相比，这种类型的事实表将多个周期内的多个业务事件汇总到一行数据中。其事实是半可加的，意味着不能按照任意维度进行聚合。

3.6.3 累积快照事实表

主要用来度量实体的生命周期，表中每行数据记录实体一系列业务过程的进展情况，包含从业务开始到结束之间的各个业务事件，例如从用户创建订单到支付的时长，或者从卖家发货到买家收货的时长。

3.6.4 聚集事实表

这种表根据不同的分析维度汇总明细数据，主要作用是加速上层数据的查询速度，同时减少数仓中的数据存储量和计算量。

3.7 画像数仓—维度表

维度建模中，维度表是用来描述事实表中各个维度的属性和关系的表。维度表主要包括以下几种：

退化维度：这类维度表除了主键之外没有任何内容，是没有关联的维度表。
雪花/支架维度：雪花维度可以精确表示程式化数据，但使用较少，因为它影响查询效率并对下游使用不友好。支架维度与雪花维度类似，包含对维度的引用关系，也应尽量少用。
角色扮演维度：用于解决事实表中对某个维度多次引用的问题，可以通过表别名或数组的方式扮演不同的维度。
杂项维度：通常指枚举字段，如在事实表中同时存在时，将这些字段单独建立一张维表，并在事实表中保存一个外键。
桥接维度：用于解决事实表与维度或维度之间的一对多或多对多关系。
微型维度：用于解决维表数据量过大或维度变化频率过快的问题，将分析频率较高或变化频率较快的字段单独建立一张维表。
缓慢变化的维度：这类维度有多种处理方式，包括直接更新、增加新行、历史拉链等，需要根据不同的业务分析场景选择合适的处理方式。

在用户画像数仓中，针对缓慢变化维度的处理，通常采用直接更新的方式，因为许多标签的计算口径只关注最新的用户行为数据。对于关心历史数据变化的场景，可以采用增加新行的方式，需要借助代理键或历史拉近的方式。这些维度表的类型在维度建模中各有其用途和适用场景，对于构建高效、可维护的数据仓库至关重要。

3.8 画像数仓—建模规范

下面介绍画像数仓在建模时遵循的一些规范：

3.8.1 高内聚、低耦合

这是对模型设计的最基本要求。在建模时，需要考虑数据的业务特性和访问特性，将业务相关、粒度相近的数据存储在一起。

3.8.2 核心模型与扩展模型分离

这个规范要求核心模型的字段支持常用的核心业务，而扩展模型的字段支持个性化或临时性的数据分析需求。同时，要确保扩展模型的字段不会过度侵入核心模型，以维护模型的简洁性和可维护性。

3.8.3 公共处理逻辑下沉且单一

越是底层公用的处理逻辑越应该在数仓的底层进行封装与实现，不要让公用的处理逻暴露给应用层来实现，避免公共逻辑多处同时存在。在画像数仓中为了让一些维度满足分析需求时就会按照这个规范来处理，例如常访问租房价格区间标签，在设计价格区间这个字段时就会放到数仓的明细层。

3.8.4 成本与性能平衡

在适当的情况下，通过反规范化方式将维度冗余到事实表中，以换取查询性能。但需注意不要过度冗余，以免增加存储成本和降低查询性能。

3.8.5 数据可回滚

在进行数据冗余时，应建立在不妨碍事实表的基础上，并确保数据可回滚。

3.8.6 数据一致性

在建模时，应确保同字同义或同数同表的数据构建成一致性的事实和维度，避免相同数据在数仓中的命名不一致。

3.8.7 减少代理键使用

由于代理键在分布式计算引擎中的生成代价较高，应尽量避免使用。

3.8.8 表、字段命名规范

表字段的命名应清晰且可理解，这是建模中的基本要求。

这些数仓建模规范有助于确保用户画像数仓的模型设计合理、高效，并且易于维护和扩展。

3.9 画像数仓—表命名规范

画像数仓的表命名规范，主要由三个部分组成：数据分层、业务表名和后缀。

数据分层：根据数仓的分层名称来命名表。
业务表名：结合业务主题来为表命名。
后缀：根据数据的存储格式和更新频率来添加后缀。
这样的命名规范有助于清晰地表示表的属性和来源，便于理解和维护数据仓库中的表结构。

3.10 画像数仓—分层规范

整个数仓分为四层：

ODS 层（原始数据层）：包含业务系统中的原始数据，数据相对标准化。
DWD 层（明细数据层）：根据不同的主题建设，以业务过程为驱动建模，通过反规范化的方式将维度冗余到实时表中，构建最细粒度的明细数据。
DWS 层（汇总数据层）：这一层根据不同的标签需求和面向的分析主题对象，构建不同粒度的汇总数据。
APP 层（应用数据层）：位于 DWS 层之上，根据不同的标签需求产出对应的标签数据。

这样的分层规范有助于组织和管理画像数仓中的数据，确保数据的层次清晰和有序

3.11 画像数仓—标签生产流程

接下来通过具体某个品牌的标签生产流程，来看一下是如何分层构建的。如上图所示。

ODS 层（原始数据层）：包含业务系统的用户行为原始数据和相关维度数据。
DWD 层（明细数据层）：通过反规范化方案，将用户行为日志和维度数据处理成一张用户行为明细表。
DWS 层（汇总数据层）：根据不同标签所属的分析主题域构建不同维度的汇总数据，并按照标签的统计周期构建不同数据粒度的汇总数据。例如，对于关注过去 90 天用户行为的标签，如果一次性汇总 90 天的数据，会导致执行速度非常慢。为了解决这个问题，可以增加一张轻度聚集的每日任务行为数据事实表。此外，DWS 层还包括一张 ID Mapping 维度表，用于将基础数据中的用户 ID 转换为标签的主体 ID。
APP 层（应用数据层）：根据标签所属的应用主题域产出对应的标签表。

这样的标签生产流程确保了数据从原始数据到标签数据的逐层汇总和处理，优化了数据的存储和查询效率。

3.12 画像数仓—技术实现

阐述完标签生产流程之后，再来介绍标签生产过程中 ETL（提取、转换、加载）任务的具体技术实现。

起初使用 Hive SQL 来设计标签 ETL 任务。然而，随着标签数据的不断增加，尤其是在任务高峰阶段，Hive SQL 的执行效率变得非常低，任务的执行时长也显著增长。这主要有两个原因：一是计算资源不足，二是 Hive SQL 对 Yarn 调度服务的压力较大。Hive SQL 的底层是通过 MapReduce（MR）来执行 ETL 任务的，每个 task 在启动时都会向 Yarn 申请计算资源。当 task 数量达到一定规模时，会导致 Yarn 的调度服务性能下降，从而使 task 长期处于 pending 状态，无法获取计算资源。

反之，Spark 通过 executor 来申请和分配计算资源，每个 task 在 executor 内部完成资源分配。这种资源调度方式对 Yarn 来说更为轻量级。基于这种调度方式的差异，我们将标签的 ETL 任务升级到了 Spark。与 Hive SQL 相比，Spark 向 Yarn 申请的 container 数减少了近 90%，并且数仓各层任务的运行时长也有显著缩短。

3.13 画像数仓—数据质量保障体系

数仓建设中，数据质量的保障至关重要。整个质量保障体系围绕数据的完整性、一致性、准确性、即时性和规范性等特性构建。

在实践中发现数仓中大约 80% 的数据质量问题源于数据源的脏数据。因此，对数据源进行质量探查与分析变得尤为关键。为此，我们开发了一个专门的数据质量探查工具，通过这个工具可以快速了解表中的数据质量情况，并输出每个字段的分析指标。例如，对于字符串类型的字段，会输出空值或 null 值的条目数以及唯一值 TOP10 等探查指标。这些指标有助于判断数据源中是否存在脏数据，并据此快速制定异常数据规避措施和数据监控策略。

在数仓内部，还会针对核心数据增加服务级别协议（SLA）监控，对一些核心指标进行同比和环比监控。对于产出的标签，我们会制定相应的覆盖率和准确率监控。通过这套完整的数据质量保障体系，确保画像数仓产出的标签稳定且准确，为下游使用提供可靠的数据。