维度建模和指标体系构建.docx

维度建模和指标体系构建01 数仓建模综述数据建模是数据开发工作中的核心与基石，好的模型体系好处很多：降低成木：优秀的模型设计能够提升数据复用性，减少计算/存储 资源浪费 提升开发效率：优秀的模型设计能够降低数据使用门槛，减少工作量提升质量：优秀的模型设计能够保证数据□径一致，降低bug率数据建模的实现方式有很多，常用的比如ER模型，Data Vault模型等目 前业界使用最多的模型是Ralph Kimball在《数据仓库工具》中提出的维度建模 模型，其中典型的代表如星型模型，雪花模型一个 典型的维度建模一般需要 经过如下几个步骤：1. 业务调研：调研需要建模的业务形态，划分基木的业务线/数据域2. 层次设计：定义数仓层级，保证各层级之间职责明确，划分清晰3. 规范设计：定义数仓中表/字段的命名规范，建立统一的指标体系4. 事实表设计：根据单一/复合业务过程确定事实表主题，确定最小粒度5. 维度表设计：根据业务确定实体，补充实体属性字段优秀的层次设计可以保证数仓表数量在可控范围内增长，同时保证数据产出流 逻辑清晰，便于后期维护和扩展良好的规范设计规定了统一的命名规则，保 证各个业务过程的实体/指标的完备和唯一性。

02设计原则按照《大数据之路一一阿里巴巴大数据实战》，维度建模应该符合 以下几 个规范1. 高内聚，低耦合：从业务流程和数据访问特性两个角度考虑，针 对业务粒 度相近，业务流程相近的数据应该放在同一个表中（例如广 告数仓中通常 会把广告的点击/曝光/转化多个业务过程数据放在同 一个宽表中），针对 经常要在同一个场景下访问的数据，也应该放在 同一个表内2. 公共处理逻辑下沉和单一：公用的逻辑应该封装在底层表中，避 免公用逻 辑直接暴露给上层，同一个公共逻辑需要收敛，避免在多个 地方同时存在3. 适当冗余：考虑到mr/rdd计算框架下join运算的资源损耗，可以通过适当 冗余字段处理减少 join 操作4. 命名一致/可理解：同一个业务含义的字段命名必须相同，且直观 可读03 层次设计腾讯视频数据中心团队把数据模型分成了五层：操作数据层（0DS）,主题明细层（DWD），主题聚合层（DWS），应用数据层（ADS）,维度数据层（DIM）操作数据层（0DS）:最接近数据源的一层，主要负责以下工作：数据清洗：过滤 H 志或者上游中的脏数据结构化：将数据中的json等非结构化字段结构化处理保留原始数据：根据业务或者系统要求保留历史切片，方便溯源主题明细层（DWD） /主题聚合层（DWS）:采用维度退化的方法将维度指标退化到事实表中，减少下游维度表和事实表的关联，同时在DWS层采用更多的宽表化操作构建公共指标，提高指标复用性，主题层通常是数仓中的核心数据层，主要工作如下：复用逻辑：维度退化：宽表化处理，复用关联逻辑统一公共指标/公共维度：保证公共指标，公共维度的数据一致性,减少因数据来源不一致带来的数据问题应用数据层（ADS）:面向分析和产品的数据层，灵活多变，数据会存储到多种查询引擎，常见的如HIVE, mysql, es等中便与业务使用，降低查询门槛，提高应用中的查询响应速度维度数据层（DIM）:贯穿数据模型各个层次，保留业务过程中的实体信息，用来关联事实表将数据宽表化其他团队也有各自的分层方式，例如字节跳动的ODS （操作数据层），DWD （主题明细层），DW （主题聚合层），DM （宽表层），ADS （应用 层）。

阿里巴巴数据团队把数据模型分为ODS （操作数据层），DWD （主题明 细层），DWS （主题聚合层），ADS （应用层）04规范设计为了保证数仓中同一个业务含义字段命名一致，需要通过某种方式约束/规定字段的命名，以阿里巴巴的命名规范为例在阿里的数据体系中的每个指标都可以通过如下的规则描述DW业务板块：业务形态差距较大的多个业务可以通过业务板块来区分，例如广告业务和电商业务属于两个业务板块时间周期：时间粒度，常见的如每天，每月，每个季度数据域：多个业务过程的抽象，例如广告效果相关业务可以整合 成一个 数据域（点击/曝光/展示），电商行业的交易业务可以整合成 一个数据域 （下单/成交/退款）修饰类型：一系列修饰词的集合，比如终端类型 修饰词：除了维度以外的对指标的限定，比如移动端的广告点击, 这里的移动端就是修饰词业务过程：业务中的一个原子的业务行为，特点是不可拆分，比 如点击广 告这个业务行为原子指标：业务过程下某一个行为的度量，特点是不可拆分，比 如广告点 击量，每个原子指标有确定的数据类型，算法说明以及命名维度：维度是用来描述业务过程中的环境（参与方）集合，比如广告点击 这个业务行为中的维度有用户，广告订单，广告位，广告所 处的页而等属性：属性是用来描述维度的内容，比如用户的名称，用户的性 别，用户 的年龄等。

派生指标：通过一个派生指标描述业务过程，派生指标二1个原子指标+n 个修饰词（n〉=0，也可以没有，全部通过维度来描述）+时间周期，例如移动 端最近 3天的广告点击量二点击量（原子指标） +移动端（修饰词） +3天（时 间周期） =yidong_r3d_click从上图可以看出，派生指标由原子指标，修饰词和时间周期组合得 到，并 且遵循以下几个原则:1. 原子指标，修饰词归属到某一个数据域下2. 派生指标只能完全归属到同一个原子指标下而，相应的也会继承 对应原子 指标的数据域，数据类型，算法说明3. 派生指标可以由多个修饰词共同修饰，不同修饰词之间的逻辑关 系是/或/ 否ps:对于每一个原子指标，修饰词以及时间周期都需要设定一个词根，常见的 命名方式通常为英文缩写/英文全称/中文缩写，这些词根应该 具备较强的可读性，并且在部门内外部有统一的命名方式（通过工具或 者文档构建原子指标库 /修饰词库）05 模型实施业务调研和架构设计在构建数仓模型之前首先要分析建模的业务过程，主要包含以下三块工 作：1. 调研业务场景和数据需求，划分业务板块和数据域2. 设计数仓架构：构建总线矩阵，抽象数据域下的业务过程和维度 主体，构 建总线矩阵3. 根据数据需求整理指标体系，规范指标定义和命名构藝总拔距阵明确垢标开发症邂业务调研业务调研主要从两方面出发:1. 分析各个业务线/业务模块的异同点，具有相同业务形态的业务应 该配置为同一个业务板块。

例如字节跳动的抖音，抖音国际版(Tiktok),不难看出两者除了多语言模块以外，其他功能几乎一样因此在数仓建 模的时候应该考虑将两 者维护在同一个数据仓库之下，减少重复开发功能樓块用户视频广告主广告订单跳转页广告点击◎◎◎◎◎广告转化◎◎◎◎◎广告曙光◎◎◎◎2. 分析业务的分析需求，具有交叉分析需求的业务应该配置为同一个 业务板 块数仓服务于数据查询/分析，通过下沉复杂逻辑减少数据查 询/分析的代 价对于数仓开发同学来说，理想的数仓开发是业务分析 的产品具有完全一致 的业务过程，但是产品之间形态千差万别才是常 态这种情况下应该尽量以查 询需求为准，抽象共同的业务过程，将不 同的业务线融合，统一维护例如在 字节跳动的商业化部门数仓中， 为了分析整个公司收入，会将各个业务线(星图，穿山甲，DOU+，即合 等）的收入数据，进行统一维护当然业务线融合也 会在很大程度上提高了数仓开发难度，主要体现在SLA维护，维度属性字段产 岀/维护， 指标统一性维护，在介绍事实表建设/维度表建设两章时会详细描 述业务类型新闻应用产品名称 今日头条抖音短视频应用履视频应用短视频应用火山小视频 西瓜小视频联盟广告y应用架构设计1. 明确了模型中的业务领域之后首先需要将整个业务领域划分成多 个业务过 程，业务过程可以概括为不可以拆分的行为（原子性），每 个行为由维度 （实体）+度量（指标）组成，同一个业务步骤中具有 相似维度的的业务过 程可以组成一个数据域。

初次开发时不需要将当 前业务域中的所有业务过 程都拆分出来,可以根据使用方的分析需求 逐步扩展如广告业务中的，广 告点击/曝光/转化这几个行为事件2. 规定了数据域之后就要开始构建总线矩阵了明确每个数据域中 有哪些业 务过程，每个业务过程中有哪些维度和指标注意，在明确 维度的时候需 要和业务方提前沟通，将有分析需求的维度尽可能包含 进来需要注意的 时有些分析的维度不直接包含在业务过程中，例如广告主不直接包含在该广告点击的业务过程中,但是为了满足业务分析需求，也应该作为维度包含进来业务过程广告受众广告订单广告位播放视频為化操作广告主广告点击◎◎◎ ◎X◎广告環光◎◎◎ ◎X◎广告转化◎◎◎ ◎◎◎规范定义 根据定义的总线架构获得了业务过程中的实体和业务过程，我们可以 构 建出命名的规范图例如广告业务的效果域总线架构可以产出如下的规 范 定义图通过上图可以构建出一致性的维度属性和一致性的指标，例如衍生指标 最近三天 pc 平台曝光数 =recent_3_d_pc_exposureo 唯一归属在 广 告业务一一效果域 下，其中 exposure 原子指标规定了唯一的曝光的口 径（例如广告业务中的曝光 为广告海报整体露出大于 1/3 且持续 3 秒） 和单位（次）06 维度表建设维度是分析业务过程中的环境信息，维度表的列值被称为维度属 性，维度 属性通常被用来作为分析的过滤/排序/聚合条件。

因此在分析 需求中作为约束 条件的字段应该构建成维度属性在确定了需要构建的维度实体之后通常按照以下流程设计1. 确定维度全局唯一，同一个业务下有且只允许一个维度定义2. 确定维度主键，维度的主键包括代理键和自然键两种，前者可以 通过系统自动生成（例如mysql的自增id）,自然键通常由业务提供，例如每个广告订单 id 都是唯一的，并且对应前台的业务系统来 说，每一个自然键都具有 唯一的业务定义3. 确定主维表与主维表属性，主维表是业务前台直接同步的数据， 属性字段 由业务系统维护4. 确定相关维表和相关维表属性，数仓的主要工作是对不同系统的 交叉分 析，因此在构建维表时除了填充业务前端的属性以外还需要根 据业务的分 析需求补齐相关属性字段，例如广告订单的广告主行业信 息除此之外，在设计过程中，开发人员还需要注意以下几个主题：反规范 化，维 度一致性处理，维度整合和拆分反规范化传统的联机事务处理系统（OLTP）通常采用规范化技术来设计数据模型，一种常见的规范化模型是雪花模型，这种模型的优势最大化的减 少数据冗余，同时针对更新的数据，雪花模型能够将数据更新操作控制 在少数的几个表记录 中，从而减少系统更新压力但是不同于传统的分析事务，在联机分析处理系统（OLAP）中主要面临的业务场 景是数据追加数据查询操作，系统中保存的是海量的快照数 据，同时根据 mr/spark计算引擎可知，数仓系统的性能瓶颈在集中在表JOIN。

因此对于维度数 据，需要采用反规范化处理，将多个维度属性 尽量存放在同一张表内减少 JOIN 操作，相应的数据模型被称为星型 模型维度一致性处理保持维度一致性是数仓分析需求的前提和基石，数仓分析中的很多 需求都 是将不同业务领域的业务过程或者同一业务领域下的不同业务 过程合并起来分 析的，如果存在维度不一致的情况（例如针对同一个广 告位，维度一中。