数仓建模的原因目前的数据处理大致可以分为在线事务处理OLAP (在线翻译处理)、在线分析处理OLAP (在线分析处理) on-lineanalyticalprocessing OLTP是传统关系数据库的主要APP应用，主要是银行交易等基本日常事务处理。 OLAP是数据仓库系统的主要APP应用程序，支持复杂的分析操作，侧重于决策支持，提供直观易懂的查询结果。 两者的主要区别例如下表所示。
创建数据仓库主要满足OLAP的业务需求并将原始数据导入ODS层后，需要将原始数据的关系建模转换为维建模
数仓建模的好处数仓建模的好处可以从关系模型和维度模型的对比中看出
关系建模
关系模型如图所示，严格遵循第三范式(3NF )，从图中可以看出，比较松散、零碎，物理表数量多，数据冗馀度低。 由于数据分布在许多表中，因此这些数据可以更灵活地应用，功能性更强。 在关系模型的主要应用和OLTP系统中，大多数业务系统的表遵循第三范式，以保证数据完整性和避免冗馀。
在OLTP系统中，数据往往存储在关系数据库(Mysql )中，数据冗馀使得数据库难以存储，而表太大不利于Mysql的快速响应，导致多个碎片化小表中的
维度建模
维度模型如图所示，主要应用于OLAP系统，是一种通常以事实表为中心进行表格的组织，主要面向业务，可能有数据冗馀，但其特点是容易获得数据。
关系模型虽然冗馀少，但在跨大数据、表分析统计查询的过程中，会引起多个表的关联，大大降低执行效率。 使用hive进行数仓项目的数据管理时，由于地层使用了FDFS分布式存储，因此磁盘空间充足，冗馀的数据并不困难。 另一方面，由于hive查询引擎的原因，过多的表的直接连接会使spark产生过多的shuffle过程，导致性能下降
在维度建模的基础上，数仓建模中模型的分类和选择可以分为星形模型、雪花模型和星座模型三种模型
明星型
标准星形模型的维度只有一层，中间是事实表，周边是维度表。 尽可能将维度表缩小到一层，在大大提高查询性能的同时，还提供了更多的数据冗馀。
雪花模型
中心事实表的外周有一个或多个维度表。 也就是说，雪花模型在性能上比星形模型弱，但某些数据的冗馀会相应降低
星座模型
星座模型与上述两种模型不属于同一纬度，星座模型表示多个事实表的纬度模型。
星座模型是许多数仓的常态，主要反映数仓模型有多个事实表，同时它们共享一些维度表
模型的选择在星形模型和雪花模型的选择中，主要取决于性能优先还是灵活性优先。 在众多的数仓中绝对不会选择一个，根据情况灵活组合或并存。 总体上看，倾向于维度更少的星形模型。
在hive中，减少连接可以大幅减少shuffle，性能差异较大，因此推荐星形模型。
数仓建模的表类型介绍ODS层的表，保留Mysql中导入的原始字段和数据，属于关系模型，不存在维模型的表类型。
在DWD层中，要创建维模型，需要两种类型的表：维表和组成事实表
维度表维度表：一般是事实的说明信息。 每个维度表对应于现实世界中的一个对象或概念。 例如，用户、商品、日期、地区等。
维度表特征：(相对于事实表)
维度表范围广(具有多个属性，列多) )。
与事实表相比，行数相对较小：通常为10万条
内容的相对固定：编码表
事实表中每行的数据表示业务事件(订单、付款、退款、评估等)。 术语“事实”表示业务事件的度量，如可统计次数、数量和金额。
每个事实表中的行都包含可相加的数字类型度量值、连接到维表的外键(通常是两个或多个外键)和表示外键之间多对多关系的外键。
事实表特征：(相对于维表)
数据量非常大(行数)。
相对狭窄：列数少。 主要是外键id和测量值)
总是会发生变化，每天都会增加很多。
1）事务型事实表
对于每个事务或事件，例如，将一个订单记录、一个支付记录等设置为事实表中的一行数据。 提交事务并插入事实表中的数据后，数据不再更改，而是每天递增更新。
2）周期型快照事实表
周期快照事实表并不保存所有数据，而是仅保存一定间隔的数据，如每日或每月销售额或每月帐户馀额。
例如，购物车有加减商品，随时都有变化的可能性，但每天结束时会在意这里面有多少商品，便于事后统计分析。 因此，周期性快照事实表的更新方法是每天进行总量更新，即每天创建数据的快照。
3）累积型快照事实表
累积快照事实表用于跟踪业务事实的变化。 例如，数据仓库可能需要存储或存储从订购到订购商品包装、运输和批准的每个业务阶段的时间点数据，以跟踪订单生命周期的进度。 这个业务流程一进行，事实表的记录也要不断更新。
p> 数仓建模的步骤维度建模一般按照以下四个步骤：
选择业务过程→声明粒度→确认维度→确认事实
在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
如果是中小公司，尽量把所有业务过程都选择。
如果是大公司（1000多张表），选择和需求相关的业务线。
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
典型的粒度声明如下：
订单当中的每个商品项作为下单事实表中的一行，粒度为每次。
每周的订单次数作为一行，粒度为每周。
每月的订单次数作为一行，粒度为每月。
如果在DWD层粒度就是每周或者每月，那么后续就没有办法统计细粒度的指标了。所以建议采用最小粒度。
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。
维度表：需要根据维度建模中的星型模型原则进行维度退化。
此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。如何判断是否能够关联上呢？在业务表关系图中，只要两张表能通过中间表能够关联上，就说明能关联上。
一 、尽量选择更细的粒度
在保留数据时间的情况下,如果选择较粗的力度,后续再想进行查分,会非常麻烦。而选择较细的粒度,合并统计为较粗的粒度比较简单操作
二 、尽量保留更多的纬度表信息
如果后续新添加的需求所需要的字段没有在DWD层保留,在进行重新的建模添加会非常麻烦。
三、以需求为主导确定度量值
度量值是主要的统计信息,直接对应业务需求,所以要按照需求倒退事实表的度量值。