数据仓库设计与开发-0-数仓建模基础

转载 https://blog.csdn.net/qq_35318838/article/details/102968992?utm_medium=distribute.pc_relevant.none-task-blog-utm_term-3&spm=1001.2101.3001.4242
转载 https://blog.csdn.net/zhaodedong/article/details/54174011?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522160436897119724838530992%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=160436897119724838530992&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2 _blogfirst_rank_v1~rank_blog_v1-10-54174011.pc_v1_rank_blog_v1&utm_term=%E5%85%83%E6%95%B0%E6%8D%AE&spm=1018.2118.3001.4450

数据仓库建模的意义

如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。

数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，最能够说明数据模型的重要性。

只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。

• 性能： 帮助我们快速查询所需要的数据，减少数据的I/O吞吐，提高使用数据的效率，如宽表。
• 成本： 极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低存储和计算成本。
• 效率： 在业务或系统发生变化时，可以保持稳定或很容易扩展，提高数据稳定性和连续性。
• 质量： 良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。数据模型能够促进业务与技术进行有效沟通，形成对主要业务定义和术语的统一认识，具有跨部门、中性的特征，可以表达和涵盖所有的业务。

大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡！

下图是个示例，通过统一数据模型，屏蔽数据源变化对业务的影响，保证业务的稳定，表述了数据仓库模型的一种价值：

数据仓库分层的设计

为了实现以上的目的，数据仓库一般要进行分层的设计，其能带来五大好处：

• 清晰数据结构： 每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
• 数据血缘追踪： 能够快速准确地定位到问题，并清楚它的危害范围。
  减少重复开发： 规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
• 把复杂问题简单化： 将复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。当数据出现问题之后，不用修复所有的数据，只需要从有问题的步骤开始修复。
• 屏蔽原始数据的异常： 不必改一次业务就需要重新接入数据。

以下是我们的一种分层设计方法

• 数据缓冲区（ODS）的数据结构与源系统完全一致。
• 基础数据模型(DWD)和融合数据模型（DWI与DWA）是大数据平台重点建设的数据模型。
• 应用层模型由各应用按需自行建设，其中基础数据模型一般采用ER模型，融合数据模型采用维度建模思路。
  

两种经典的数据仓库建模方法

维度建模

维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。
典型的代表是我们比较熟知的星形模型。

维度退化
星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。
这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。

建模方法
通常需要选择某个业务过程，然后围绕该过程建立模型，其一般采用自底向上的方法，从明确关键业务过程开始，再到明确粒度，再到明确维度，最后明确事实，非常简单易懂。

以下是阿里的OneData的建模工作流，可以参考。

优点： 技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能

缺点： 维度表的冗余会较多，视野狭窄

关系建模

是数据仓库之父Inmon推崇的、从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象。
它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。
雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 “层次 ” 区域，这些被分解的表都连接到主维度表而不是事实表。
雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。

关系建模常常需要全局考虑，要对上游业务系统的进行信息调研，以做到对其业务和数据的基本了解，要做到主题划分，让模型有清晰合理的实体关系体系，以下是方法的示意：

以下是中国移动的概念模型的一种示例，如果没有自顶向下的视野，基本是总结不出来的：

优点： 规范性较好，冗余小，数据集成和数据一致性方面得到重视，比如运营商可以参考国际电信运营业务流程规范（ETOM），有所谓的最佳实践。

缺点： 需要全面了解企业业务、数据和关系；实施周期非常长，成本昂贵；对建模人员的能力要求也非常高，容易烂尾。

比较

企业建模的三点经验

维度建模就不说了，只要能理解业务过程和其中涉及的相关数据、维度就可以，但自顶向下的关系建模难度很大，以下是关系建模的三个建设要点。

1. 业务的理解： 找到企业内最理解业务和源系统的人，梳理出现状，比如运营商就要深刻理解三域（O/B/M），概念建模的挑战就很大，现在做到B域的概念建模已经很不容易
   
2. 数据及关系的理解： 各个域的系统建设的时候没有统一文档和规范，要梳理出逻辑模型不容易，比如运营商的事件主题下的逻辑模型就非常复杂。
   
3. 标准化的推进： 数据仓库建模的任何实体都需要标准化命名，否则未来的管理成本巨大，也是后续数据有效治理的基础，以下是我们的一个命名规范示例：
   

漫谈数据仓库之维度建模-实践

下面我们将以电商为例，详细讲一下维度建模的建模方式，并举例如果使用这个模型，假设我们在一家电商网站工作，比如某宝、某东。我们需要对这里业务进行建模。下面我们分析几点业务场景：

• 电商网站中最典型的场景就是用户的购买行为。
• 一次购买行为的发起需要有这几个个体的参与：购买者、商家、商品、购买时间、订单金额。
• 一个用户可以发起很多次购买的动作。

下面就是我们设计出来的数据模型

首先，我们想一下，如果我们不这样设计的话，我们一般会怎么做？
如果是我，我会设计下面这张表。你信不信，我能列出来50个字段！其实我个人认为怎么设计这种表都有其合理性，我们不论对错，单说一下两者的优缺点。

先说我们的维度模型：

数据冗余小（因为很多具体的信息都存在相应的维度表中了，比如用户信息就只有一份）
结构清晰（表结构一目了然）
便于做OLAP分析（数据分析用起来会很开心）
增加使用成本，比如查询时要关联多张表
数据不一致，比如用户发起购买行为的时候的数据，和我们维度表里面存放的数据不一致
再说我们这张大款表的优缺点：

业务直观，在做业务的时候，这种表特别方便，直接能对到业务中。
使用方便，写sql的时候很方便。
数据冗余巨大，真的很大，在几亿的用户规模下，他的订单行为会很恐怖
粒度僵硬，什么都写死了，这张表的可复用性太低。

维度建模是一种十分优秀的建模方式，他有很多的优点，但是我们在实际工作中也很难完全按照它的方式来实现，都会有所取舍，比如说为了业务我们还是会需要一些宽表，有时候还会有很多的数据冗余。