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

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

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

用户画像数仓建设过程

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

• 垂直数据中心：这是按照不同业务板块划分的数据中心，集中了各个业务领域的资产，并提供了相对标准化的数据，例如用户行为数据、用户注册数据等。目前，画像数仓涵盖了大多数业务的用户数据，日处理数据量约为 20 TB。
• 公共数据中心：这个中心是按照不同的主题进行划分的，构建了面向不同分析需求的主题数仓。它包含了一些公共汇总数据和明细数据。例如，面向用户行为分析的场景，建设流量数仓提供给业务使用。

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

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

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

• ER 模型（实体-关系模型）：这种模型要求满足三范式原则，即每一列、每一行以及整张表的数据都具有原子性。ER 模型的优点在于它极大地消除了数据冗余，并且能够快速满足实体更新和实体间关系的更新。然而，在面向数据分析场景时，它的缺点是关联查询较多，且难以适应业务的频繁变化。
• Data Vault 模型：这是在 ER 模型的基础上进一步规范化的模型，是一种中心辐射式模型，是 3NF 建模的衍生，其建模思想是围绕着业务键的集成模式。Data Vault 模型进一步消除了数据冗余，但在数据分析场景下，它也存在关联查询多和对数据建模要求高的问题。
• Anchor 模型：这是一种 KV（键值）结构化的模型，相对于 Data Vault 模型，它进一步整合了数据。Anchor 模型的设计思想是所有实体只添加扩展，不进行修改，这使得它最易于实体扩展和业务变更。不过，相对于前两种模型，在进行数据分析时，它的成本更高，关联查询也更多。
• 维度建模：这是一种反规范化设计方法，从数据需求出发，同时服务于数据分析需求。它能够满足大规模复杂查询的性能需求，产出指标时关联查询较少，建模成本也较低。然而，与泛式建模相比，它对数据更新不太友好。

• 事务事实表：在维度建模中，任何类型的事件都可以被视为事务。这类事实表用于定义和追踪业务过程中的个体行为，作为数仓的明细数据，提供了丰富的数据分析能力。在画像数仓中，用户行为事实表是一种特殊的事实表，其特点是没有度量。对于用户访问 58 同城 APP 来说，对于每次点击，其度量都为 1，这种度量通常不会在事实表中保存。
• 周期快照事实表：与事务事实表相比，这种类型的事实表将多个周期内的多个业务事件汇总到一行数据中。其事实是半可加的，意味着不能按照任意维度进行聚合。
• 累积快照事实表：主要用来度量实体的生命周期，表中每行数据记录实体一系列业务过程的进展情况，包含从业务开始到结束之间的各个业务事件，例如从用户创建订单到支付的时长，或者从卖家发货到买家收货的时长。
• 聚集事实表：这种表根据不同的分析维度汇总明细数据，主要作用是加速上层数据的查询速度，同时减少数仓中的数据存储量和计算量。

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

• 高内聚、低耦合：这是对模型设计的最基本要求。在建模时，需要考虑数据的业务特性和访问特性，将业务相关、粒度相近的数据存储在一起。
• 核心模型与扩展模型分离：这个规范要求核心模型的字段支持常用的核心业务，而扩展模型的字段支持个性化或临时性的数据分析需求。同时，要确保扩展模型的字段不会过度侵入核心模型，以维护模型的简洁性和可维护性。
• 公共处理逻辑下沉且单一：这个规范是指越是底层公用的处理逻辑越应该在数仓的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层来实现，避免公共逻辑多处同时存在。在画像数仓中为了让一些维度满足分析需求时就会按照这个规范来处理，例如常访问租房价格区间标签，在设计价格区间这个字段时就会放到数仓的明细层，而不是在应用层根据用户访问的不同租房价格归属对应的价格区间。
• 成本与性能平衡：在适当的情况下，通过反规范化方式将维度冗余到事实表中，以换取查询性能。但需注意不要过度冗余，以免增加存储成本和降低查询性能。
• 数据可回滚：在进行数据冗余时，应建立在不妨碍事实表的基础上，并确保数据可回滚。
• 数据一致性：在建模时，应确保同字同义或同数同表的数据构建成一致性的事实和维度，避免相同数据在数仓中的命名不一致。
• 减少代理键使用：由于代理键在分布式计算引擎中的生成代价较高，应尽量避免使用。
• 表、字段命名规范：表字段的命名应清晰且可理解，这是建模中的基本要求。

• 数据分层：根据数仓的分层名称来命名表。
• 业务表名：结合业务主题来为表命名。
• 后缀：根据数据的存储格式和更新频率来添加后缀。

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

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

成果和总结