1.星型模式
星型模式是维度模型中最简单的形式，也是数据仓库以及数据集市开发中使用最广泛的形式。
星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。
星型模式的物理模型像一颗星星的形状，中心是一个事实表， 围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。
星型模式将业务流程分为事实和维度。事实包含业务的度量，是定量的数据，如销售价格、销售数量、距离、速度、重量等是事实。维度是对事实数据属性的描述，如日期、产品、客户、地理位置等是维度。一个含有很多维度表的星型模式有时被称为蜈蚣模式，显然这个名字也是因其形状而得来的。蜈蚣模式的维度往往只有很少的几个属性，这样可以简化对维度表的维护，但查询数据时会有更多的表连接，严重时会使模型难于使用，因此在设计中应该尽量避免蜈蚣模式。
2.雪花模式
雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。
与星型模式相同，雪花模式也是由事实表和维度表所组成。所谓的“雪花化”就是将行星模型中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为中心的雪花型结构，即雪花模式。将维度表进行规范化的具体做法是，把低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如主键列具有唯一值， 所以有最高的基数，而像性别这样的列基数就很低。
在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表，而事实表作为雪花模式里的字表，存在具有层次关系的多个父表。
3.星座模式
数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。
4.模型的选择
在数据仓库建模时，会涉及到模式的选择，我们要根据不同模式的特点选择适合具体业务的模式：
冗余：雪花模型符合业务逻辑设计，采用 3NF 设计，有效降低数据冗余；星型模型的维度表设计不符合 3NF（如果是雪花模型改造成了星型模型，那么肯定不符合 3NF，因为一定发生了表的整合，即降维，一定有传递依赖，但是，并不是所有的星型模型都不符合
3NF，很多星型模型的表是符合 3NF 的），反规范化，维度表之间不会直接相关，牺牲部分存储空间。（雪花模型的维度之间是有关联的）
性能：雪花模型由于存在维度间的关联，采用 3NF 降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能较雪花模型高。（ 星型表的数据冗余大，是用存储空间换取效率 ）（ BI 的一些工具对于星型模型的支持更规范化 ）
ETL：雪花模型符合业务 ER 模型设计原则，在 ETL 过程中相对简单，但是由于附属模型的限制，ETL 任务并行化较低（由于雪花模型中有很多的维度依赖，在 ETL 的时候， 需要在保持 3NF 的前提下对数据进行清洗，即对数据一致性/规范化的处理，例如数据来自于多个业务系统，各个系统对于用户的定义不一致，此时要对每个业务定义的用户数据进行规范化处理，在 3NF 的限制下必然会降低并行度）；星型模型在设计维度表时反范式设计，所以在 ETL 过程中整合业务数据到维度表有一定难度，但由于避免附属维度，可并行化处理（不用关注太多的关联关系，避免了维度表之间的关联关系，并行度较高，注意，一般场景下星型模型的并行化程度更高，并不是所有场景）。
Hive 的分析通过 MapReduce 实现，每多一个 Join 就会多出一个 MapReduce 过程，对于雪花模型，由于存在着很多维度表之间的关联，这就会导致一次分析对应多个 MapReduce 任务，而星型模型由于不存在维度表的关联，因此一个 MapReduce 就可以实现分析任务。
MapReduce 本身是一个支持高吞吐量的任务，它的每个任务都要申请资源、分配容器、节点通信等待，需要 YARN 的调度，由于相互关联的维度表本身会很小，join 操作用时很少，
YARN 调度的时长可能都大于实际运算的时长，因此我们要尽可能减少任务个数，对于 Hive 来说就是尽可能减少不必要的表的关联。还有一点，雪花模型中拆分出的维度表，每个表对应至少一个文件，这就涉及到 I/O 方面的性能损耗。
因此，我们要采用适当的数据冗余，避免不必要的表之间的关联。
在实际项目中，不会刻意地去考虑雪花模型，而是刻意地去考虑星型模型，特别是大数据领域的建模，倾斜于使用数据冗余来提高查询效率，倾向于星型模型；雪花模型只会应用在一些我们要求模型的灵活性，要求保证模型本身稳定性的场景下，但是雪花模型并不是首选。
文章出处登录后可见！
