原文链接： https://blog.csdn.net/winterPassing/article/details/105929303
概念
根据事实表和维度表的关系，可将常见的模型分为星型模型和雪花模型。在数据仓库的建设中，一般都会围绕着这两种模型来设计表关系或者结构。那么什么是事实表和维度表呢？在维度建模中，将度量称为“事实” ，将环境描述为“维度”。维度是用于分析事实所需要的多样环境。例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。事实则紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。例如订单作为交易行为的核心载体，直观反映了交易的状况。订单的流转会产生很多业务过程，而下单、支付和成功完结三个业务过程是整个订单的关键节点。获取这三个业务过程的笔数、金额以及转化率是日常数据统计分析的重点，事务事实表设计可以很好地满足这个需求。
当所有维表都直接连接到事实表上时，整个图解就像星星一样，故将该模型称为星型模型。
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一点的冗余。如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。
星型模型强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。
当有一个或多个维表没有直接连接到事实表上，而是通过其他维度表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。
雪花模型是对星型模型的扩展，它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如将地域维表分解为国家，省份，城市等维表。它的优点是：通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能，去除了数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。
区别及优缺点
星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花模型要高。
星型模型不用考虑很多正规化的因素，设计与实现都比较简单。
雪花模型由于去除了冗余，有些统计就需要通过表的连接才能产生，所以效率不一定有星型模型高。
正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。
什么时候使用雪花模型
Ralph Kimball，数据仓库大师，讲述了三个例子。对于三个例子，使用雪花模型不仅仅是可接受的，而且可能是一个成功设计的关键。
1、一个用户维度表且数据量较大。其中，80%的事实度量表是匿名访问者，仅包含少数详细信息。20%的是可靠的注册用户，且这些注册用户有较为详细的信息，与多个维度表中的数据相连。
2、例如一个金融产品维度表，且这些金融产品有银行类的，保险类等等区别。因此不同种类的产品有自己一系列的特殊属性，且这些属性并非是所有产品共享的。
3、多个企业共用的日历维度表。但每个企业的财政周期不同，节假日不同等等。在数据仓库的环境中用雪花模型，降低储存的空间，到了具体某个主题的数据集市再用星型模型。
雪花模型使得维度分析更加容易，比如“针对特定的广告主，有哪些客户或者公司是在线的?”，星形模型用来做指标分析更适合，比如“给定的一个客户他们的收入是多少?”
总结
通过上面的对比我们可以发现，在数据仓库建设中大多时候比较适合使用星型模型构建底层数据Hive表，通过大量的冗余来提升查询效率，星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin中比较能体现。而雪花模型在关系型数据库中如MySQL，Oracle中非常常见，尤其像电商的数据库表。在数据仓库中雪花模型的应用场景比较少，但也不是没有，所以在具体设计的时候，可以考虑是不是能结合两者的优点参与设计，以此达到设计的最优化目的。
参考文档：
《数据仓库工具箱》
什么时候用雪花模型：https://blog.csdn.net/rav009/article/details/70666289
星型模型和雪花型模型比较：https://blog.csdn.net/nisjlvhudy/article/details/7889422
理解数据仓库中星型模型和雪花模型：https://www.iteye.com/blog/qindongliang-2383473