星型模型、雪花模型、星座模型：优缺点与选型
最近我发现，不少做数据仓库的朋友都在纠结一个问题： 星型模型长什么样？ 因为只有一层关联，写SQL简单，数据库跑起来也快。 你拿着模型图跟业务部门开会，指着图说“这张事实表存的是交易金额，这几张维度表是时间、产品、客户”，对方一眼就能看明白，沟通起来特别顺畅。 你看产品维度里，每个产品都带上产品类别名称，同一类别下有几千个产品，类别名称就被重复存几千次。不过话说回来，现在硬盘便宜，这点冗余真不是大问题。 如果你要做跨多个业务主题的复杂分析，星型模型可能需要调整。但我觉得，大部分单业务域的报表场景，星型模型完全够用。 雪花模型是什么？ 看到这里，你可能会问：那雪花模型到底有没有用？ 星座模型也叫事实星座模型，其实就是多个星型模型放在一起，共享一些公共的维度表。就像你有销售事实表、库存事实表、采购事实表，它们都用同一张时间维度表和同一张产品维度表，这就形成了星座模型。 我参与的几个中型项目，最后都走向了星座模型。 为了方便你选型，我把三种模型的核心差异再梳理一下： 其实在实际项目中，我们很少只用某一种模型，往往是混合着用。 希望今天的分享对你有帮助。
星型、雪花、星座这三种模型，到底该用哪个？
面试题背得滚瓜烂熟，可一到真正动手设计，就不知道怎么选了。一、星型模型
中间一张事实表，周围一圈维度表，事实表跟维度表直接关联，维度表之间谁也不连谁。
听着是不是很熟？几乎所有教材里都有它。星型模型最大的好处是查询快。
用过来人的经验告诉你，在海量数据的环境里，少一次关联，查询速度能快不少。我之前做过一个实时大屏项目，业务方要求三秒内出数据，我二话不说全用了星型模型，最后效果很稳。这个模型还特别好懂。
说白了，能让业务方看懂的模型，就是好模型。
当然，它也有缺点。最明显的就是数据冗余。
另一个缺点是灵活性差了点。
简单来说，除非你有特别强的存储限制，不然就优先选星型模型，尤其面向业务报表和仪表盘，用起来最顺手。二、雪花模型
就是把星型模型的维度表再拆细一点。比方说，把产品维度拆成产品表、类别表、品牌表，一层套一层，像雪花一样。雪花模型的优点：
但它的缺点往往更让人头疼：
我的答案是：有用，但要用对地方。
在数仓底层，比如数据清洗层，用雪花模型的思想做规范化处理是合理的，能保证数据质量。
但到了面向查询的上层，比如汇总层，我一定会把雪花模型拍回星型模型。说白了，把类别名称、品牌名称都冗余到产品宽表里，虽然多占点存储，但查询快了，维护简单了，这笔账怎么算都划算。三、星座模型
说实话，星座模型的设计难度比前两个高出一大截。你得有全局视野，提前想清楚哪些维度是各个业务都通用的，怎么保证口径一致。但它带来的好处也很明显：
不过对于它的缺点，你心里也得有数：
用过来人的经验告诉你，星座模型往往是企业数仓建设到一定阶段后的必然选择。
但我建议你不要一上来就搞大而全的星座模型，那样容易把自己绕进去。
正确做法是：从一个业务域的星型模型做起，等模型稳定了，再通过“一致性维度”的方式，慢慢把多个星型模型融合起来。
比方说，先把所有事实表的时间维度统一，再把产品维度统一，自然就形成星座模型了。
用过的朋友应该知道，星座模型最怕的就是ETL维护成本高，工具选对了能省不少事。
我常用的一个ETL工具是FineDataLink，它在处理这种复杂的调度依赖时比较顺手，能可视化配置任务流，不用写太多代码。四、那到底怎么选？
具体怎么选？
写在最后
