星型模型、雪花模型、星座模型:优缺点与选型

0 阅读6分钟

最近我发现,不少做数据仓库的朋友都在纠结一个问题:

星型、雪花、星座这三种模型,到底该用哪个?

面试题背得滚瓜烂熟,可一到真正动手设计,就不知道怎么选了。

  • 选星型,怕以后扩展麻烦;
  • 选雪花,担心查询太慢;
  • 选星座吧,又觉得太复杂搞不定。

今天我就把这三种模型的优缺点讲清楚,希望能帮你建模时少走弯路。

一、星型模型

星型模型长什么样?

中间一张事实表,周围一圈维度表,事实表跟维度表直接关联,维度表之间谁也不连谁。

听着是不是很熟?几乎所有教材里都有它。

星型模型最大的好处是查询快。

因为只有一层关联,写SQL简单,数据库跑起来也快。

用过来人的经验告诉你,在海量数据的环境里,少一次关联,查询速度能快不少。 我之前做过一个实时大屏项目,业务方要求三秒内出数据,我二话不说全用了星型模型,最后效果很稳。

这个模型还特别好懂。

你拿着模型图跟业务部门开会,指着图说“这张事实表存的是交易金额,这几张维度表是时间、产品、客户”,对方一眼就能看明白,沟通起来特别顺畅。

说白了,能让业务方看懂的模型,就是好模型。

当然,它也有缺点。

最明显的就是数据冗余。

你看产品维度里, 每个产品都带上产品类别名称,同一类别下有几千个产品,类别名称就被重复存几千次。不过话说回来,现在硬盘便宜,这点冗余真不是大问题。

另一个缺点是灵活性差了点。

如果你要做跨多个业务主题的复杂分析,星型模型可能需要调整。但我觉得,大部分单业务域的报表场景,星型模型完全够用。

简单来说,除非你有特别强的存储限制,不然就优先选星型模型,尤其面向业务报表和仪表盘,用起来最顺手。

二、雪花模型

雪花模型是什么?

就是把星型模型的维度表再拆细一点。 比方说,把产品维度拆成产品表、类别表、品牌表,一层套一层,像雪花一样。

雪花模型的优点:

  • 减少数据冗余, 类别名称只在类别表存一次,节省存储空间。
  • 数据一致性高, 修改类别名称只改一处,不会出现改漏的情况。

但它的缺点往往更让人头疼:

  • 查询性能会下降。 以前关联两张表就能出的报表,现在可能要关联四五张表。多一层关联,就多一分性能损耗,数据量大的时候特别明显。
  • 模型变复杂了。 业务方看着一堆拆开的子表,完全搞不清怎么关联,开发人员也容易写错SQL。
  • ETL依赖关系也变复杂了, 数据加载顺序得小心翼翼。

看到这里,你可能会问:那雪花模型到底有没有用?

我的答案是:有用,但要用对地方。

在数仓底层,比如数据清洗层, 用雪花模型的思想做规范化处理是合理的,能保证数据质量。

但到了面向查询的上层,比如汇总层, 我一定会把雪花模型拍回星型模型。说白了,把类别名称、品牌名称都冗余到产品宽表里,虽然多占点存储,但查询快了,维护简单了,这笔账怎么算都划算。

三、星座模型

星座模型也叫事实星座模型,其实就是多个星型模型放在一起,共享一些公共的维度表。 就像你有销售事实表、库存事实表、采购事实表,它们都用同一张时间维度表和同一张产品维度表,这就形成了星座模型。

说实话,星座模型的设计难度比前两个高出一大截。 你得有全局视野,提前想清楚哪些维度是各个业务都通用的,怎么保证口径一致。

但它带来的好处也很明显:

  • 维度可以复用, 所有事实表都用同一套时间、产品维度,跨业务分析时指标不会打架。
  • 能支撑多主题分析, 如果你要同时看销售和库存的关系,这种场景只有星座模型能优雅搞定。
  • 整体结构还是清晰的, 虽然事实表多了,但因为共享维度,架构不乱。

不过对于它的缺点,你心里也得有数:

  • 设计复杂, 需要提前规划总线矩阵,对架构师要求高。
  • ETL维护成本高, 表之间依赖关系复杂,数据加载顺序必须严格把控。
  • 查询性能可能不稳定, 如果关联的表太多或者维度表没设计好,很容易变慢。

用过来人的经验告诉你,星座模型往往是企业数仓建设到一定阶段后的必然选择。

我参与的几个中型项目,最后都走向了星座模型。

但我建议你不要一上来就搞大而全的星座模型,那样容易把自己绕进去。

正确做法是: 从一个业务域的星型模型做起,等模型稳定了,再通过“一致性维度”的方式,慢慢把多个星型模型融合起来。

比方说,先把所有事实表的时间维度统一,再把产品维度统一,自然就形成星座模型了。

用过的朋友应该知道,星座模型最怕的就是ETL维护成本高,工具选对了能省不少事。

我常用的一个ETL工具是FineDataLink,它在处理这种复杂的调度依赖时比较顺手,能可视化配置任务流,不用写太多代码。

四、那到底怎么选?

为了方便你选型,我把三种模型的核心差异再梳理一下:

具体怎么选?

  • 看性能要求。 如果业务方要求秒级响应,优先选星型。少关联就是快。
  • 看团队能力。 团队经验足,可以尝试星座模型;团队新手多,就先从星型做起,快速交付,以后再优化。
  • 看业务广度。 单部门用星型足够;全公司多业务联动,必须上星座模型,但要一步步来。

写在最后

其实在实际项目中,我们很少只用某一种模型,往往是混合着用。

  • 底层用雪花模型清洗数据,保证一致性;
  • 上层用星型模型建宽表,保证查询速度;
  • 最后通过共享维度把多个星型串起来,形成星座模型。

希望今天的分享对你有帮助。