目录
本文介绍数据建模的基础方法论,并通过建模实例的建模实践,输出对模型结构、设计模式的经验技巧与自我理解。
如何将数据有序、有结构地分类组织和存储是数据建设者面临的一个挑战,如果把数据看作图书馆里的书,我们希望看到它们在书架上分门别类地放置。数据模型就是数据组织和存储的方法,合适的数据模型能获得以下好处:
因此,大数据系统需要数据模型方法来帮助更好地组织和存储数据,以便在性能、成本、效率和质量之间取得最佳平衡。
维度建模从需求出发,重点关注快速完成需求分析,围绕性能和易理解性构建模型,以事实表与维度表的形式重新组织数据。
维度数据模型的代表有:星型模型、雪花模型。星型模型是非规范化的设计,在设计与建设过程中不受关系数据库范式规则的约束,简单的关联逻辑便可以支持高度复杂的维度组合需求,在查询性能方面具有明显的优势;雪花模型是将一个维度规范化成多个关联的表,规范化的过程就是将维表中冗余的数据进行解耦从而分离出一些新表,以减少数据冗余。
在OLAP应用中主要有两大优势:
① 前期建模成本较低,从业务需求出发,快速迭代;
② 查询性能高,通过数据冗余降低查询的复杂度。
主要的劣势表现在:
① 通过降低规范化、尽可能多的冗余维度信息在一张“大宽表”之中,使整个模型臃肿,当遇到不断变化的业务时,数据的维护成本大;
② 由于数据的大量冗余,如何保证数据一致性也是一个问题,无疑增加了模型的管理成本。
因此,从整体来说维度建模的开发和使用成本较低,但是维护成本较高,比较适合在接近业务分析的数据集市层、分析层来使用。
关系数据模型的基本假设是数据仓库的需求会发生变化,因此关系模型设计所要求的高度抽象、独立性,在面对频繁变化时体现出了其优势。另外,关系数据模型所遵循的三范式在减少数据冗余方面有天然优势,在数据量不断膨胀增长的背景下,规范化的数据模型对于降低不必要的数据存储十分有意义。
关系模型在OLAP应用中,主要存在2大问题:
① 关系数据模型对数仓建模者的视野有较高要求,需要对企业的业务系统和架构充分理解,因此模型构建在学习成本方面有一定的劣势。
② 对于分析型需求来说,关系模型需要进行大量的关联、查询的性能问题也很凸显。
因此,关系模型在OLAP建设体系中更适合基础数据层的建设,目的是将各个系统中的数据以整个企业角度按主题进行相似性组合和合并,并进行一致性处理。
ER模型在实践中最典型的代表是 Teradata 公司基于金融业务发布的 FS-LDM (Financial Services Logical Data Model),它通过对金融业务的高度抽象和总结,将金融业务划分为10大主题,企业基于此模型做适当调整和扩展就能快速落地实施。
Data Vault 是ER模型的衍生,设计的出发点是为了实现数据整合,但不能直接用于数据分析决策,它强调建立一个可审计的基础数据层,也就是强调数据的历史性、可追溯性和原子性,而不要求对数据进行过度的一致性处理和整合 ,同时它基于主题概念将企业数据进行结构化组织,并引入了更进一步的范式处理来优化模型,以应对源系统变更的扩展性。 Data Vault 模型由以下几部分组成。
• Hub:是企业的核心业务实体,由实体key、数据仓库序列代理键、装载时间、数据来源组成。
• Link:代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象,可以提升模型的扩展性。它可以直接描述 1:1、 l:n 和 n:n 的关系,而不需要做任何变更。它由 Hub的代理键、装载时间、数据来源组成。
• Satellite:是Hub的详细描述内容,一个Hub可以有多个Satellite。它由 Hub 的代理键、装载时间、来源类型、详细的Hub描述信息组成。
优势:① 保留数据来源与装载时间的信息,保证数据的历史性与数据源系统的可追溯。
② 模型设计结合3NF及维度模型的理念,其灵活性、可扩展性、一致性更好满足企业数仓要求。
劣势:① 对于数据开发工作者的模型设计要求更高,需把握不同模块的设计思路并形成统一的方法论。
② 模型更高的解耦程度会提高业务分析的使用开发成本,需要不断加强企业内部对于的模型认知。
Data Vault 模型在灵活性、可扩展性以及降低数据冗余方面展现出了一定的优势,但是查询成本较高,理论上来看这是一种适用于企业级数据仓库或数据中台的建模方式,Data Vault模型比ER模型更容易设计和产出,它的ET加工可实现配置化。
Anchor模型的提出者认为数据仓库需要提供稳定性高且具有一致性的服务,但是面对外部业务环境不断变化的矛盾,数仓的维护将变得十分复杂且耗时,为了应对这些变化和挑战,数据模型的设计必须具备模块化、灵活性、可追溯历史的特性。
Anchor数据模型是对 Data Vault 数据模型的进一步标准化,将模型规范到 6NF 的抽象程度,这样高度规范化的模型其优势和劣势变得更加凸显。
优势:① 模型的扩展机制保障了其变更管理的健壮性与灵活性,能够达到高度可扩展性。
② 6NF 的规范化程度使得模型以k-v 的结构存储数据,数据的冗余性得到极大的降低。
劣势:① 获取极大扩展性的同时,统计分析的查询需求便会存在大量的关联多表操作,计算性能方面有所影响。
② 模型的复杂度较高,对于元数据管理及后续的数据治理带来更大的挑战。
③ 过度的规范化对于模型设计者、使用者来说提高了门槛。
Anchor 模型具有极大的可扩展性与复用度,按照这种方式建设数仓后能够大大降低模型的维护成本,这种模型通常适用于基础明细层的设计,但是这种高度规范化的建模方法对于建模者的要求也是难以衡量的,因此在企业数仓中很少展开实际应用。
阿里的数据仓库建设经历了多个发展阶段。
第一个阶段 : 完全应用驱动的时代,构建在Oracle/mysql上,以满足报表需求为目的,将数据以与源结构相同的方式同步到 Oracle (称作ODS 层),基于ODS数据进行统计,基本没有系统化的模型方法体系,完全基于Oracle/mysql数据库特性进行数据存储和加工,部分采用一些维度建模的缓慢变化维方式进行历史数据处理,这时候的数据架构只有两层,即ODS+DSS。
第二个阶段 : 随着业务的快速发展,数据量也在飞速增长,开始尝试工程领域比较流行的ER模型+维度模型方式,构建出一个四层的模型架构,即ODL (操作数据层) +BDL (基础数据层) +IDL (接口数据层) +ADL(应用数据层)。 ODL和源系统保持一致 : BDL引入ER模型,加强数据的整合,构建一致的基础数据模型, IDL基于维度模型方法构建集市层,ADL完成应用的个性化和基于展现需求的数据组装。
第三个阶段 :阿里的业务和数据飞速发展,自主研发的分布式计算平台MaxCompute发布,开始建设自己的第三代模型架构,选择了以维度建模为核心理念的模型方法论,同时对其进行了一定的升级和扩展,构建了阿里的公共层模型数据架构体系。
阿里公共层建设的指导方法是一套统一的集团数据整合及管理的方法体系(在内部这一体系称为“OneData”),以OneModel统一数据构建及管理方法论为主干,OneID核心商业要素资产化为核心,oneService提供统一数据接入和数据查询服务。
其包括一致性的指标定义体系 、模型设计方法体系以及配套工具,把表数据模型分为三层 :操作数据层( ODS)、公共维度模型层( CDM )和 应用数据层( ADS), 其中公共维度模型层包括明细数据层( DWD )和汇总数据层( DWS )。
OneModel方法论是以维度建模为理论基础,构建总线矩阵,划分和定义业务板块、数据域、业务过程、维度、度量/原子指标、业务限定、时间周期、派生指标,设计出维度表、明细事实表、汇总事实表的过程。
业务板块:由于阿里生态庞大,根据业务的属性划分出了几个相对独立的业务板块,业务板块之间的指标或业务重叠性较小。如电商业务板块涵盖淘系、 B2B系和AliExpress系等。
规范定义:结合行业的数据仓库建设经验和阿里数据自身特点,设计出的一套数据规范命名体系,规范定义将会被用在模型设计中。
模型设计:以维度建模理论为基础,基于维度建模总线架构,构建一致性的维度和事实,同时在落地表模型时,基于阿里自身业务特点, 设计出一套表规范命名体系。
规范定义指以维度建模作为理论基础 , 构建总线矩阵,划分和定义数据域、业务过程、维度、度量 / 原子指标、修饰类型、修饰词、时间周期、派生指标。
名词术语 | 解释 |
---|---|
业务板块 | 业务板块定义了数据仓库的多种命名空间,是一种系统级的概念对象。当数据的业务含义存在较大差异时,可以创建不同的业务板块,数据仓库的建设将按照业务板块进行划分。同一个业务板块中可能包含多个不同的项目,所以业务板块与项目的关系为1:N |
数据域 | 指面向业务分析,将业务过程或者维度进行抽象的集合。 数据域是需要抽象提炼,并且长期维护和更新的,但不轻易变动。在划分数据域时,既能涵盖当前所有的业务需求,又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。 |
业务过程 | 指企业的业务活动事件,如下单、支付、退款都是业务过程。 业务过程是一个不可拆分的行为事件。 |
维度 | 维度即进行统计的对象,用来反映业务的一类属性,这类属性的集合构成一个维度 ,也可以称为实体对象。 |
度量/原子指标 | 原子指标和度量含义相同,基于某一业务事件行为下的度量,是业务定义中不可再拆分的指标,具有明确业务含义的名词 ,如支付金额。 |
业务限定 | 统计的业务范围,指除了统计维度以外指标的业务场景限定的抽象,用于筛选出符合业务规则的记录(类似于SQL中where后的条件,不包括时间区间)。原子指标是计算逻辑的标准化定义,业务限定则是条件限制的标准化定义。 |
派生指标 | 即基于原子指标、时间周期和维度,圈定业务统计范围并分析获取统计指标的数值。派生指标=原子指标+业务限定+统计周期+维度或维度的组合(统计粒度) |
统计粒度 | 统计分析的对象或视角,用于圈定数据的统计范围,也可以理解为聚合运算时的分组条件(类似于SQL中Group By的对象)。例如,某个指标是某个卖家在某个省份的成交额,则粒度就是卖家、省份这两个维度的组合。如果需要统计全表的数据,则粒度为全表。 |
OneModel的一个核心内容是派生指标的构建方法,派生指标由原子指标、时间周期、业务限定、统计粒度统一定义。
首先,在建设数据仓库时,要进行充分的业务调研和需求分析,业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功;其次,进行数据总体架构设计,主要是根据数据域对数据进行划分,按照维度建模理论,构建总线矩阵、抽象出业务过程和维度;再次,对报表需求进行抽象整理出相关指标体系,依据工具完成指标规范定义和模型设计;最后,就是代码研发和运维。
数据仓库的建设是要涵盖所有业务领域,还是各个业务领域独自建设,业务领域内的业务线也同样会面临着这个问题,所以构建大数据仓库,就需要了解各个业务领域、业务线的业务有什么共同点和不同点 ,以及各个业务线可以细分为哪几个业务模块,每个业务模块具体的业务流程又是怎样的。在数仓建设项目启动前,可以请相关的业务人员介绍具体的业务,以便明确各个团队的分析、运营人员的需求。可以详细了解以下信息:
以电商业务为例,公司的电商业务板块分为招商、供应链、营销、服务四个板块,梳理出各业务板块的需求数据框架如下图所示。
此外,还需要进一步了解各业务板块中已有的业务流程,业务流程通常与业务板块紧密耦合,对应一个或多个表及其所属数据源,可以作为构建数仓的原始数据来源。
在未考虑数据分析师、业务运营人员数据需求的情况下,单纯根据业务调研建设的数据仓库,可能可用性较差。完成业务调研后,需要进一步收集数据使用者的需求,进而对需求进行深度思考和分析,并改进数据仓库。
需求分析的途径有两种:
数据域是指面向业务分析,将业务过程或者维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为事件,如下单、支付、退款。为保障整个体系的生命力,数据域需要抽象提炼,并且长期维护和更新,但不轻易变动。在划分数据域时,既能涵盖当前所有的业务需求,又能在新业务进入时无影响地被包含进已有的数据域中或者扩展新的数据域。例如:零售事业群的业务行态分两大块,线上自营电商和线下商超,所涉及的主要业务流程有:
功能模块/业务线 | 业务动作 |
---|---|
交易 | 下单、支付、退货、退款 |
供应链 | 采购、运输、仓储(入库、上架、拣选、出库、盘点等) |
会员 | 新增会员、会员登录、会员信息修改 |
履约 | 接单、发货、配送、签收 |
商品管理 | 商品上架、下架、类目修改 |
用户行为跟踪 | 商品浏览、店铺浏览、网页区块点击 |
售后服务 | 投诉、举报 |
评价 | 好评、改评价、打分 |
构建总线矩阵
在进行充分的业务调研和需求调研后,就要构建总线矩阵了。需要做两件事情 :明确每个数据域下有哪些业务过程;业务过程与哪些维度相关,并定义每个数据域下的业务过程和维度。
规范定义主要定义指标体系,包括原子指标、修饰词、时间周期和派生指标。
模型设计主要包括维度及属性的规范定义,维表、明细事实表和汇总事实表的模型设计。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。