数据仓库建模
目录
数仓建模
为什么要对数据仓库进行分层
主题
主题的概念
维度建模：
模型的选择：
星形模式
雪花模型
星座模式
拉链表
维度表和事实表：
维度表
事实表
事实表设计规则
退化维度
事务事实表、周期快照事实表、累积快照事实表
四步维度建模
建模步骤
落地实施的具体步骤：
同步策略
基本原则
数仓建模
不以规矩，不能成方圆。火车之所以能奔驰千里，是因为它始终离不开两条铁轨；风筝之所以能飞翔万尺，是因为它总是情系着手中的线；大江东流，日月交替，大自然生生不息，用规则演绎着生命的轨迹。
先确认主题，然后是维度建模的四个步骤
为什么要对数据仓库进行分层
实现好分层架构，有以下好处：
-
清晰数据结构：每一个数据分层都有对应的作用域，在使用数据的时候能更方便的定位和理解。
-
数据血缘追踪：提供给业务人员或下游系统的数据服务时都是目标数据，目标数据的数据来源一般都来自于多张表数据。若出现目标数据异常时，清晰的血缘关系可以快速定位问题所在。而且，血缘管理也是元数据管理重要的一部分。
-
减少重复开发：数据的逐层加工原则，下层包含了上层数据加工所需要的全量数据，这样的加工方式避免了每个数据开发人员都重新从源系统抽取数据进行加工。
-
数据关系条理化：源系统间存在复杂的数据关系，比如客户信息同时存在于核心系统、信贷系统、理财系统、资金系统，取数时该如何决策呢？数据仓库会对相同主题的数据进行统一建模，把复杂的数据关系梳理成条理清晰的数据模型，使用时就可避免上述问题了。
-
屏蔽原始数据的影响：数据的逐层加工原则，上层的数据都由下一层的数据加工获取，不允许跳级取数。而原始数据位于数仓的最底层，离应用层数据还有多层的数据加工，所以加工应用层数据的过程中就会把原始数据的变更消除掉，保持应用层的稳定性。
主题
主题的概念
主题（Subject）是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。例如“销售分析”就是一个分析领域，因此这个数据仓库应用的主题就是“销售分析”。
主题域是对某个主题进行分析后确定的主题的边界。分析主题域，确定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库设计时，一般是一次先建立一个主题或企业全部主题中的一部分，因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。
主题域的确定必须由最终用户和数据仓库的设计人员共同完成的， 而在划分主题域时，大家的切入点不同可能会造成一些争论、重构等的现象，考虑的点可能会是下方的某些方面：
-
按照业务或业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；
-
根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题；
-
按照功能或应用划分：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等；
-
按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题；
维度建模：
在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。
模型的选择：
-
首先就是星座不星座这个只跟数据和需求有关系,跟设计没关系,不用选择。
-
星型还是雪花,取决于性能优先,还是灵活更优先。
-
目前实际企业开发中,不会绝对选择一种,根据情况灵活组合,甚至并存(一层维度和多层维度都保存)。但是整体来看,更倾向于维度更少的星型模型。尤其是Hadoop体系,减少Join就是减少Shuffe,性能差距很大。(关系型数据可以依靠强大的主键索引)
星形模式
星型模型是数据集市维度建模中推荐的建模方法。星型模型是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星型模型的特点是数据组织直观，执行效率高。因为在数据集市的建设过程中，数据经过了预处理，比如按照维度进行了汇总，排序等等，数据量减少，执行的效率就比较高
星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
-
维表只和事实表关联，维表之间没有关联；
-
每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
-
以事实表为核心，维表围绕核心呈星形分布；
雪花模型
雪花模型也是维度建模中的一种选择。雪花模型的维度表可以拥有其他维度表的，虽然这种模型相比星型模型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用。
星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。
星座模式
星座模型是星型模型延伸而来，星型模型是基于一张事实表的，而星座模型是基于多张事实表的，而且共享维度信息。 通过构建一致性维度，来建设星座模型，也是很好的选择。比如同一主题的细节表和汇总表共享维度，不同主题的事实表，可以通过在维度上互相补充来生成可以共享的维度。
拉链表
什么是拉链表
拉链表是针对数据仓库设计中表存储数据的方式而定义的，顾名思义，所谓拉链，就是记录历史。记录
一个事物从开始，一直到当前状态的所有变化的信息。
拉链表和流水表
流水表存放的是一个用户的变更记录，比如在一张流水表中，一天的数据中，会存放一个用户的每条修
改记录，但是在拉链表中只有一条记录。
维度表和事实表：
维度表
维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。例如：用户、商品、日期、地区等。
与事实表比较，维度表一般包含较少的行，但是可能列数较多
缓慢变化维
事实表
事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等）
每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。
事实表中的每行对应一个度量事件，每行中的数据是一个特定级别的细节数据，称为粒度，
粒度可划分为三类：事务、周期性快照、累积快照
事实表的事实数值可分为三种：可加性、半可加、不可加
事实表设计规则
-
尽可能包含所有与业务过程相关的事实；
-
只选择与业务过程相关的事实；
-
分解不可加性事实为可加的组件；比如订单的优惠率，应该分解为订单原价金额与订单优惠金额
-
在选择维度和事实之前必须先声明粒度；
-
在同一个事实表中不能有多种不同粒度的事实；粒度的声明是事实表设计中不可忽视的重要一步，粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性，在选择维度和事实之前必须先声明粒度，且每个维度和事实必须与所定义的粒度保持一致
-
在同一个事实表中不能有多种不同粒度的事实；
-
事实的单位要保持一致；
-
对事实的 null 值要处理；在数据库中null值对常用的大于或小于等SQL不生效，建议使用零值填充
-
使用退化维度提高事实表的易用性；目的主要是为了减少下游用户使用时关联多个表的操作。直接通过退化维度实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等
退化维度
有时，维度除了主键外没有其他内容。例如，当某一发票包含多个数据项时，数据项事实行继承了发票的所有描述性维度外键，发票除了外键外无其他项。但发票数量仍然是 在此数据项级别的合法维度键。这种退化维度被放入事实表中，清楚地表明没有关联的维 度表。退化维度常见于交易和累计快照事实表中。
事务事实表、周期快照事实表、累积快照事实表
-
·事务事实表：事务事实表描述业务过程事务层面的事实，每条记录代表一个事务事件，保留事务事件活动的原始内容。事务事实表中的数据在事务事件发生后记录，一般记录后数据就不再进行更改，其更新方式为增量更新。事务事实表相对其他事实表保存的数据粒度更细，可以通过事务事实表对事务行为进行详细分析。
-
·周期快照事实表：周期快照事实表以具有规律性、可预见的时间间隔产生快照来记录事实，每行代表某个时间周期的一条记录，记录的事实是时间周期内的聚集事实值或状态度量。周期快照事实表的内容一般在所表达的时间周期结束后才会产生，一般记录后数据就不再更改，其更新方式为增量更新。周期快照事实表一般是建立在事务事实表之上的聚集，维度比事务事实表少，粒度比事务事实表粗，但是由于对事实进行了多种形式的加工从而产生了新的事实，故一般事实会比事务事实表多。
-
·累计快照事实表：累积快照事实表覆盖一个事务从开始到结束之间所有的关键事件，覆盖事务的整个生命周期，通常具有多个日期字段来记录关键事件时间点。周期快速事实表涉及的多个事件中任意一个的产生都要做记录，由于周期快照事实表涉及的多个事件的首次加载和后续更新时间是不确定的，因此在首次加载后允许对记录进行更新，一般采用全量刷新的方式更新。
累计快照事实表一般用于追踪某个业务的全生命周期及状态转换，比如交易业务，涉及下单、支付、发货、确认收货，这些相关事件在不同的事务事实表中，通过事务事实表很难看到不同事件之间的转化及状态变化，通过累计快照事实表可把相关事件串起来放在一条记录中，这样就很容易解决了。
四步维度建模
不管哪种类型的事实表，设计方法都类似，事实表设计可以遵循以下步骤：
选择业务过程→声明粒度→确认维度→确认事实
-
第一步：选择业务过程
-
确定业务过程。企业业务是由一个个业务过程组成的，事实表就是为了记录这些业务过程产生的事实，以便还原任意时刻的业务运转状态。所以设计事实表，第一步就是确定实施所要表达的是哪一个或者几个业务过程。笔者理解业务过程是企业活动事件，比如注册、登录、下单、投诉等都是业务过程，最基本的是每一个业务过程对应一张事实表，这样最容易理解。但是实际开发过程中，业务过程和事实表会存在多对多的关系。
-
-
第二步：定义粒度。
-
不管事实表对应一个还是多个业务过程，粒度必须是确定的，每个事实表都有且只能有唯一的粒度，粒度是事实表的每一行所表示的业务含义，是事实的细节级别。在实际设计过程中，粒度与主键等价，粒度更偏向业务，而主键是站在技术角度说的。虽然粒度在最终的事实表中很难被体现，但是定义粒度是必不可少的步骤，这样可避免整个事实表的业务含义模糊。
-
-
第三步：确定维度。
-
定义粒度之后，事实表每一行的业务含义就确定了。那么业务人员会站在哪些角度来描述事实度量？这就要确定维度了，常见的维度有时间、区域、客户、产品、员工等。维度依附于粒度，是粒度的环境描述。
-
-
第四步：确定事实。
-
事实就是事实表度量的内容，也就是业务过程产生的事实度量的计算结果，比如注册量、登录次数、交易金额、退款量等。事实表的所有事实度量都与事实表所表达的业务过程相关，所有事实必须满足第二步所定义的粒度。
-
-
第五步：冗余维度属性。
-
事实表的设计要综合考虑数据来源和使用需求，在满足业务事实记录的同时也要满足使用的便利性和性能要求。大数据时代，事实表记录数动辄亿级，甚至数十亿、数百亿，维表也有可能达到亿级甚至更多。利用标准维度模型会经常出现维表与事实表关联的情况，这种对亿级表的关联计算，在性能上是灾难性的。为了满足业务需求，降低资源消耗，建议适当冗余维度属性数据到事实表，直接利用事实表就可以完成绝大部分业务的使用需求，这样下游使用时可减少大表关联，提升效率。所以大数据时代，适当进行维度冗余是可取的。
-
建模步骤
主要过程（自己归纳，可能部分有误）：
（1）了解业务流程：确定范围、收集业务和技术资料、模型设计研讨；
（2）分析源数据：分析整理数据结构，分析源系统样本数据；
（3）建立实体模型：框架设计、数据源主题划分、概念模型设计；
（4）模型详细设计：归纳映射、属性扩展、数据类型定义、实体间依赖关系、填写并完善实体属性；
（5）逻辑数据模型客户化：按主题规划，宽表设计；
（6）模型验证：命名、布局、划分是否规范，数据验证（准确性以及是否有遗漏），应用验证（是否满足下游应用系统和数据分析的要求），合理性验证（准入原则、数据关系）
落地实施的具体步骤：
1）按照命名规范创建表，包括维表和事实表；
2）开发生成维表和事实表的数据的逻辑代码；
3）进行代码逻辑测试，验证数据加工逻辑的正确性；
4）代码发布，加入生产调度，并配置相应的质量监控和报警机制；
5）持续任务运维监控。
同步策略
数据同步策略的类型包括：全量表、增量表、新增及变化表、拉链表
全量表：存储完整的数据。
增量表：存储新增加的数据。
新增及变化表：存储新增加的数据和变化的数据。
拉链表：对新增及变化表做定期合并。
1、实体表同步策略
实体表：比如用户，商品，商家，销售员等
实体表数据量比较小：通常可以做每日全量，就是每天存一份完整数据。即每日全量。
2、维度表同步策略
维度表：比如订单状态，审批状态，商品分类
维度表数据量比较小：通常可以做每日全量，就是每天存一份完整数据。即每日全量。
说明：
1）针对可能会有变化的状态数据可以存储每日全量。
2）没变化的客观世界的维度（比如性别，地区，民族，政治成分，鞋子尺码）
可以只存一份固定值。
3、事务型事实表同步策略
事务型事实表：比如，交易流水，操作日志，出库入库记录等。
因为数据不会变化，而且数据量巨大，所以每天只同步新增数据即可，所以可以做成 每日增量表，即每日创建一个分区存储。
4、周期型事实表同步策略
周期型事实表：比如，订单、请假、贷款申请等
这类表从数据量的角度，存每日全量的话，数据量太大，冗余也太大。如果用每日增量的话无法反应数据变化。
每日新增及变化量，包括了当日的新增和修改。一般来说这个表，足够计算大部分当日数据的。但是这种依然无法解决能够得到某一个历史时间点（时间切片）的切片数据。
所以要用利用每日新增和变化表，制作一张拉链表，以方便的取到某个时间切片的快照数据。所以我们需要得到每日新增及变化量。
基本原则
1.高内聚和低耦合
一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的 软件设计方法论的高内聚和低耦合原
则。主要从数据业务特性和访问特 性两个角度来考虑：将业务相近或者相关、粒度相同的数据设计为一
个 逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访 问的数据分开存储。
-
核心模型与扩展模型分离
建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核 心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩 展模型的字段过度侵入核心模型，以免破坏核心模型的架构简洁性与可 维护性。
-
公共处理逻辑下沉及单一
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装 与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多 处同时存在。
-
成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复 制。
-
数据可回滚
处理逻辑不变，在不同时间多次运行数据结果确定不变。
-
一致性
具有相同含义的字段在不同表中的命名必须相同，必须使用规范定 义中的名称。
-
命名清晰、可理解
表命名需清晰、一致，表名需易于消费者理解和使用。