数仓-指标-建模方法论

最新推荐文章于 2024-12-28 16:25:23 发布

docsz

最新推荐文章于 2024-12-28 16:25:23 发布

阅读量813

点赞数 19

分类专栏：数据分析文章标签：大数据数据分析

本文链接：https://blog.csdn.net/docsz/article/details/143892067

版权

数据分析专栏收录该内容

9 篇文章

订阅专栏

1.数仓建模定义
数据建模的主要目的是降低成本，提高数据的利用效率。尤其是大数据时代的到来，数据的多样化，巨量，更需要有效的有针对性数据建模方法。

大数据的数仓建模正是通过建模的方法，更好的组织、存储数据，以便在性能、成本、效率和数据质量之间找到最佳平衡点，一般我们会从以下面四点考虑：

性能：能够快速查询所需的数据，减少数据I/O的吞吐。
成本：减少不必要的数据冗余，实现计算结果的复用，降低大数据系统中的存储成本和计算成本。
效率：改善用使用数据的体验，提高使用效率。
质量：改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台。
因此，毋庸置疑，大数据系统、数据平台都需要数据模型方法来帮助更好的组织和存储数据，数据建模的工作，也正是围绕上述四个指标取得最佳的平衡而努力。

2.数仓建模方式
范式建模

范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由Inmon所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法，主要用于业务系统，所以范式建模主要是利用关系型数据库进行数仓建设，目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。

三范式：

第一范式：属性值不可再分，说直白点就是一列里面不能包含多个小列

第二范式：每张表只能有一个主键，其他字段需完全依赖主键，不能存在间接依赖。

第三范式：每张表只能有一个主键，其他字段需直接依赖主键，不能存在传递依赖。

ER实体建模

将事务抽象为"实体"（Entity）、“属性”（Property）、“关系”（Relationship）来表示数据关联和事物描述，这种对数据的抽象建模通常被称为ER实体关系模型。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体， “上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。

维度建模

数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。具体如下：
适配大数据的处理方式：维度模型的非强范式的，可以更好的利用大数据处理框架的处理能力，避免范式操作的过多关联操作，可以实现高度的并行化
自下而上的建设现状：表已经存在，业务已经开发完毕，需求直接提过来了，这几乎是一个普遍现状，因为很少有公司会提前成立数据部门，让数据部门跟随着业务从头开始一直成长，都是当业务发展到一定的阶段了，想通过数据来提高公司的运营效果
简单的模型使用简单：维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。

维度建模是面向分析场景而生，针对分析场景构建数仓模型，重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。

针对性强，主要应用于数据仓库构建和OLAP引擎底层数据模型

优点

方便使用，模型简单

适合大数据下的处理操作(其实就是shuffle)

适合OLAP操作(上钻下钻)

维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。

可扩展，维度模型是可扩展的。由于维度模型允许数据冗余，因此当向一个维度表或事实表中添加字段时，不会像关系模型那样产生巨大的影响，带来的结果就是更容易容纳不可预料的新增数据。

缺点

数据冗余，维度补全后造成的数据浪费

灵活性差，维度变化造成的数据更新量大(例如刷数据的时候，需要刷大量的表)
与典型的范式理论差异很大，如数据不一致，比如用户发起购买行为的时候的数据，和我们维度表里面存放的数据不一致

3.从零到一建模
各类建模方法都有自己的优点和局限性，方法论仅仅停留在理论层面上，落地实现的才真正决定了数仓设计的好坏，当然再好的方法，只有在合适的阶段使用，才有意义，才能发挥它最大的价值。本文结合维度建模及阿里OneData体系浅谈数仓建模过程。

规范定义
规范定义指以维度建模作为理论基础，构建总线矩阵，划分和定义数据域、业务过程、维度、度量／原子指标、修饰类型、修饰词、时间周期、派生指标。

数据域（主题域）

面向业务分析，将业务过程或者维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为事件，在业务过程之下，可以定义指标；维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。

常见主题域：用户、渠道、营销、流量、交易、财务、商品

业务过程

指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件，通俗地讲，业务过程就是企业活动中的事件。

时间周期

用来明确数据统计的时间范围或者时间点，如最近 30天、自然周、截至当日等。

修饰类型

是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖无线端、 PC 端等修饰词。

修饰词

指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型，如在日志域的访问终端类型下，有修饰词 PC 端、无线端等。

度量/原子指标

原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。

维度

维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包括国家、地区、省以及城市等级别的内容)、时间维度(其中包括年、季、月、周、日等级别的内容）。

维度属性

维度属性隶属于一个维度，如地理维度里面的国家名称、国家 ID、省份名称等都属于维度属性。

派生指标

派生指标=一个原子指标+多个修饰词(可选)+时间周期+粒度。可以理解为对原子指标业务统计范围的圈定。如原子指标：支付金额，最近 1 天海外买家支付金额则为派生指标(最近1天为时间周期，海外为修饰词，买家作为维度，而不作为修饰词)。

数仓分层
关于层级的命名大同小异，一般会使用如下命名：ODS-DWD-DIM-DWM-DWS-ADS，若公司业务线较多，可使用project_前缀命名数据库。
ods层：贴源数据层
dwd层：明细事实数据
dim：维表数据
dws：汇总数据层
ads：应用数据层
DWD 层和 DWS 层，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性；同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。其主要功能如下

组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描。

公共指标统一加工：基于 OneData体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标建立逻辑汇总宽表。

建立一致性维度:建立一致的数据分析维表，降低数据计算口径、算法不统一的风险。

应用层

应用数据层（ADS）：存放数据产品个性化的统计指标数据，根据 CDM 层与 ODS 层加工生成。
个性化指标加工：不公用性、复杂性(指数型、比值型、排名型指标)。

基于应用的数据组装 : 大宽表集市、横表转纵表、趋势指标串。