数据仓库建模方法论

建模方法论

数仓的建模或者分层，其实都是为了更好的去组织、管理、维护数据,因此当你站在更高的维度去看的话，全部的划分都是为了更好的管理。小到JVM 内存区域的划分，JVM 中堆空间的划分(年轻代、老年代、方法区等)，大到国家的省市区的划分，无一例外的都是为了更好的组织管理

1. 访问性能：可以快速查询所需的数据，减小数据I/O。
2. 数据成本：减小没必要要的数据冗余，实现计算结果数据复用，下降大数据系统中的存储成本和计算成本。
3. 使用效率：改善用户应用体验，提升使用数据的效率。
4. 数据质量：改善数据统计口径的不一致性，减小数据计算错误的可能性，提供高质量的、一致的数据访问平台。

须要注意的建模实际上是和公司的业务、公司的数据量、公司使用的工具、公司数据的使用方式密不可分的，由于模型是概念上的东西，须要理论落地至于落地到什么程度，就取决于公司的现状了

范式建模(关系型数据库)

范式建模法实际上是咱们在构建数据模型经常使用的一个方法，该方法的主要由Inmon所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法，主要用于业务系统，因此范式建模主要是利用关系型数据库进行数仓建设

目前，咱们在关系型数据库中的建模方法，大部分采用的是三范式建模法。

符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。

三范式

第一范式

属性值不可再分，说直白点就是一列里面不能包含多个小列，就像下面这样

1NF是全部关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中建立数据表的时候，若是数据表的设计不符合这个最基本的要求，那么操做必定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，必定是符合1NF的

第二范式

这里咱们先说一下，为何有了第一范式，还须要第二范式，那是应为第一范式，不能消除重复，存在数据冗余过大，致使插入异常，删除异常，修改异常的问题

因此要求每张表都要有一个主键，其它字段(列)彻底依赖主键，也就是说要求实体的属性彻底依赖于主关键字。也就是说表只描述一个事实，由于这帐号表描述了3个事实，学生、课程、和系

例如，若是花名册里只有名字，没有学号，则重名的话会很麻烦。
所谓彻底依赖是指不能存在仅依赖主关键字一部分的属性，若是存在，那么这个属性和主关键字的这一部分应该分离出来造成一个新的实体，新实体与原实体之间是一对多的关系，例如上面的系主任和系名 就是不依赖学号的，因此这里应该单独拆出来

第三范式

全部字段只能直接依赖主键，不得依赖于其它字段(非主属性) 消除依赖传递。所谓传递函数依赖指的是若是存在"A-->B-->C"的决定关系，则C传递函数依赖于A。也就是说表中的字段和主键直接对应不依靠其余中间字段，说白了就是，决定某字段值的必须是主键，而不是一个依赖于主键的其余字段

范式建模的优缺点

优势

节约存储(尤为是利用数据库进行数仓建设的时候)

规范化带来的好处是经过减小数据冗余****提升更新数据的效率，同时保证数据完整性。

结构清晰，易于理解

缺点

构建比较复杂

查询复杂(须要不少的关联)

不适合在大数据环境下构建(1 查询复杂 2 存储很便宜)

因为建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，须要进行必定的变通才能知足相应的需求。

为何要学习范式建模

上游数据源每每是业务数据库，而这些业务数据库采用的实范式建模，因此了解范式建模能够帮助咱们去合理的建设数仓

若是了解范式建模，从er 模型能够了解到数据架构，例如一个电商系统，从er模型就能够知道哪些涉及到商品的管理、用户的管理、订单管理，拿到这些关系以后，咱们就能够更好的进行数仓管理与建
数据源的规范定义须要咱们了解范式理论，能够更好的和业务系统进行对接

数仓的稀有系统，如报表系统设计的时候也会使用到范式建模

ER实体建模

将事务抽象为"实体"（Entity）、"属性"（Property）、"关系"（Relationship）来表示数据关联和事物描述，这种对数据的抽象建模一般被称为ER实体关系模型。

实体建模法并非数据仓库建模中常见的一个方法，它来源于哲学的一个流派。

从哲学的意义上说，客观世界应该是能够细分的，客观世界应该能够分红由一个个实 体，以及实体与实体之间的关系组成。咱们在数据仓库的建模过程当中彻底能够引入这个抽象的方法，将整个业务也能够划分红一个个的实体，而每一个实体之间的 关系，以及针对这些关系的说明就是咱们数据建模须要作的工做。

在平常建模中，"实体"用矩形表示，"关系"用菱形，"属性"用椭圆形。ER实体关系模型也称为E-R关系图

虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即咱们能够将任何一个业务过程划分红 3 个部分，实体，事件和说明。

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

应用场景

ER模型是数据库设计的理论基础，当前几乎全部的OLTP系统设计都采用ER模型建模的方式。

Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模。

BI架构提出分层架构，数仓底层ods、dwd也多采用ER关系模型进行设计。

因为实体建模法，可以很轻松的实现业务模型的划分，所以，在业务建模阶段和领域概念建模阶段，实体建模法有着普遍的应用。

业务概括

使用的抽象概括方法其实很简单，任何业务能够当作 3 个部分：

1. 实体，主要指领域模型中特定的概念主体，指发生业务关系的对象
2. 事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程
3. 说明，主要是针对实体和事件的特殊说明

维度建模

概念和背景

维度模型是数据仓库领域大师Ralph Kimball 所倡导，他的《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，所以它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。

维度建模源自数据集市，主要面向分析场景 Ralph Kimball 推崇数据集市的集合为数据仓库，同时也提出了对数据集市的维度建模，将数据仓库中的表划分为事实表、维度表两种类型。

通常也称之为星型结构建模，有时也加入一些雪花模型在里面。维度建模是一种面向用户需求的、容易理解的、访问效率高的建模方法

维度模型一般以一种被称为星型模式的方式构建。所谓星型模式，就是以一个事实表为中心，周围环绕着多个维度表。

还有一种模式叫作雪花模式，是对维度作进一星型模型作OLAP分析很方便

为何选择维度建模

适配大数据的处理方式

维度模型的非强范式的，能够更好的利用大数据处理框架的处理能力，避免范式操做的过多关联操做，能够实现高度的并行化。

数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表，经过大量的冗余来提高查询效率，星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin中比较能体现。

雪花模型在关系型数据库中如MySQL，Oracle中很是常见，尤为像电商的数据库表。

自下而上的建设现状

表已经存在，业务已经开发完毕，需求直接提过来了，这几乎是一个广泛现状，由于不多有公司会提早成立数据部门，让数据部门跟随着业务从头开始一直成长，都是当业务发展到必定的阶段了，想经过数据来提升公司的运营效果

简单的模型 使用简单

这个模型相对来讲是比较简单的，简单主要体如今两个方面

1. 维度建模很是直观，牢牢围绕着业务模型，能够直观的反映出业务模型中的业务问题。不须要通过特别的抽象处理，便可以完成维度建模。这一点也是维度建模的优点。
2. 星型结构的实现不用考虑不少正规化的因素，设计与实现都比较简单。

分层和建模的关系

明细层的范式模型

明细层采用传统的三范式关系模型。这一层次的数据模型要将业务过程描述清楚，将源数据（即业务系统）中隐含的、有歧义的概念进行清晰化，如活跃用户、VIP用户等。该层次的数据模型追求的目标是灵活地表达业务过程，要保证数据一致性、惟一性、正确性，以尽可能少的代价与源数据保持数据同步，同时该层次的数据模型不建议开给不懂技术的业务人员直接使用，所以，采用关系型的三范式模型是最佳的选择。

集市层的维度模型

集市层是按照业务主题、分主题构建出来的、面向特定部门或人员的数据集合，该层次的数据模型会开放给业务人员使用，进行数据挖掘及业务分析。因为业务员多数不懂数据库技术，缺乏将业务需求转换为关系型数据结构的逻辑思惟，更写不出复杂的SQL语句，所以，越简单的数据模型，越能被他们所接受，所以，这个层次所构建出来的数据模型，要按照业务过程进行组织，每一个事实表表明一个独立的业务过程，事实表之间不存在直接的依赖关系，这样业务人员能够很容易地将分析需求对应到事实表上，利用工具或手工写出简单的SQL，将统计数据提取出来进行分析。

模型实现

模型的实现主要指的是在维度建模过程当中，须要对维度表和事实表进行关联设计，而这里咱们对维度表的设计，就决定了咱们最终与事实表关联的以后的形态。也就是说咱们能够根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型

星型模型和雪花模型的主要区别在于对维度表的拆分，对于雪花模型，维度表的设计更加规范，通常符合3NF；而星型模型，通常采用降维的操做，利用冗余来避免模型过于复杂，提升易用性和分析效率。

星型模型

核心是一个事实表及多个非正规化描述的维度表组成，维度表之间是没有关联的，维度表是直接关联到事实表上的，只有当维度表极大，存储空间是个问题时，才考虑雪花型维度，简而言之，最好就用星型维度便可

当全部维表都直接链接到“ 事实表”上时，整个图解就像星星同样，故将该模型称为星型模型

星型架构是一种非正规化的结构，多维数据集的每个维度都直接与事实表相链接，不存在渐变维度，因此数据有必定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。

雪花模型

星形模式中的维表相对雪花模式来讲要大，并且不知足规范化设计。雪花模型至关于将星形模式的大维表拆分红小维表，知足了规范化设计。然而这种模式在实际应用中不多见，由于这样作会致使开发难度增大，而数据冗余问题在数据仓库里并不严重

能够认为雪花模型是星型模型的一个扩展，每一个维度表能够继续向外扩展，链接多个子维度。

当有一个或多个维表没有直接链接到事实表上，而是经过其余维表链接到事实表上时，其图解就像多个雪花链接在一块儿，故称雪花模型

星座模型

前面介绍的两种维度建模方法都是多维表对应单事实表，但在不少时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

能够认为是多个事实表的关联或者是星型模型的关联，其实到了业务发展后期都是星座模型

应用场景

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

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

优势

方便使用，模型简单

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

适合OLAP操做(上钻下钻)

维度建模很是直观，牢牢围绕着业务模型，能够直观的反映出业务模型中的业务问题。不须要通过特别的抽象处理，便可以完成维度建模。

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

缺点

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

灵活性差，维度变化形成的数据更新量大(例如刷数据的时候，须要刷大量的表)

与典型的范式理论差别很大，如数据不一致，好比用户发起购买行为的时候的数据，和咱们维度表里面存放的数据不一致

既然如此为何还要使用范式建模呢，其实和咱们使用的工具备关系

因为在构建星型模式以前须要进行大量的数据预处理，所以会致使大量的数据处理工做。并且，当业务发生变化，须要从新进行维度的定义时，每每须要从新进行维度数据的预处理。而在这些与处理过程当中，每每会致使大量的数据冗余。

若是只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，并且在数据仓库的底层，不是特别适用于维度建模的方法。

维度建模的领域主要适用与数据集市层，它的最大的做用实际上是为了解决数据仓库建模中的性能问题。维度建模很难可以提供一个完整地描述真实业务实体之间的复杂关系的抽象方法

总结

上述的这些方法都有本身的优势和局限性，在建立本身的数据仓库模型的时候，能够参考使用上述的三种数据仓库得建模方法，在各个不一样阶段采用不一样的方法，从而可以保证整个数据仓库建模的质量。

方法论仅仅停留在理论层面上，落地实现的才真正决定了数仓设计的好坏，固然再好的方法，只有在合适的阶段使用，才有意义，才能发挥它最大的价值