星型、雪花、星座，到底怎么选
分析师想按“渠道”看放款。他的 SQL 要沿着 订单 → 渠道 → 渠道组 → 渠道大类，连着关联四张表。
隔壁同事做了一张大表，一次关联就能拿到渠道的全部层级。那张大表，其实就是把渠道的上下层级铺平进一张维度表——正是星型的思路。
两种做法，哪种对？
代价两边都有，关键看你在哪边吃亏。
三种形态，先定位
星型。 维度表一层，直接挂事实表。
雪花。 维度表按层级往下拆，拆成多层。
星座。 多张事实表，共用同一批维度表。
▲ 星型和雪花比的是维度怎么挂，星座比的是事实表共用维度
星座不是星型和雪花的对手。它说的是另一件事：放款、还款、催收几张事实表，共用同一份客户、日期、产品维度。这其实是多个业务过程的常态，也正是“一致性维度”的落地样子。
所以真正需要选的，是星型还是雪花。
画出来：三种形态长什么样
光看名字容易想成玄学，画出来一眼就懂。
星型最直白：一张订单事实表摆在正中间，客户、日期、产品、渠道这些维表，直接挂在它四周，像车轮的辐条。每张维表到事实表就一条关联，取数一跳就到；维表内部也不再拆，一层就够。
雪花是把维表接着往下拆。还是那张订单事实表，渠道维表里不直接存“渠道大类”，而是再挂一张渠道组表，渠道组再挂大类——开头那位分析师连的四张表，正是一条雪花路径：从事实表到大类，要跳三次。层级拆得越深，关联就多一跳，查询路径越长。
星座是多了一个中心。放款事实表、还款事实表，两个中心共用同一批客户和日期维表。维表只存一份，两个事实表都往它这里连——一个房间不止一盏灯，才谈得上“星座”。
一句话：星型是一层，雪花是多层，星座是多中心。
剩下的所有差别，都是这个形状差别带出来的。
▲ 一层、多层、多中心：三种形态的差别，就是连线的形状
星型和雪花，各自的代价
星型为了少关联，把层级信息铺进维度表，多占空间。雪花为了少冗余，把层级拆开，多一次关联。
什么时候才值得反过来选雪花？无非三种情况：层级特别深、上层变化频繁；维度本身很大，冗余的空间不可忽视；某一层信息必须全公司只在一处维护。当时这三条我们一条都不占，而存储相对便宜，关联既耗算力、又容易写错——所以选了星型。
还有一层原因：关联路径越多，新人和 AI 越容易选错路径。面向取数的那一层，倾向星型，让常用的维度尽量一次关联就到位。
顺带纠正两个容易想岔的地方：一是别把星型等同于“一张宽表”，它仍然是事实表加多张维度表，只是维度表内部不再拆——把层级铺平的代价，聊宽表那篇会专门说；二是别为了“规范”而用雪花。
规范不是目的，查询的人少踩坑才是。
哪天会把雪花请回来
把星型当成一辈子的承诺，也是想多了。下面三种信号，出现任何一个，就该重新考虑雪花：
1. 层级特别深，而且上层变化频繁。 比如组织架构，每次调整都要在大量行里改一遍，一不小心就改漏，出现不一致。
2. 维度本身很大。 把一长串层级名在上亿行的维表里重复存，空间占用不可忽视。
3. 一致性要求极高。 某一层的信息，必须全公司只在一处维护。
这三条信号当初一条都不占，不代表永远不占——条件变了，随时把雪花请回来。
▲ 满足三条之一才考虑雪花，否则默认星型
星座里最容易出的事
星座靠“共用维度”成立。一旦出现下面的情况，它就散了：
两份客户维表。 放款用的客户维表，和催收用的客户维表，是两份各自维护的。
一个渠道，两个版本。 同一个“渠道”，有的事实表关联的是旧版，有的是新版。
没查过就新建。 新增一个业务过程，没先看有哪些现成的维度，直接新建一张。
办法最早讲建模两派那篇提过：画一张总线矩阵——行是业务过程，列是维度——每个维度只许有一份定义，新增业务过程先查矩阵。
三个问题，帮你选
1. 谁在写 SQL？ 如果大量是业务同事、新人或者 AI，选星型。
2. 层级会不会常变？ 常变且很深，才考虑雪花。
3. 有几个业务过程？ 两个以上，就一定是星座，重点放在管住共用维度。
▲ 三个问题，帮你选模型
三个问题问完，答案通常就有了。
星型还是雪花，从来不是站队表态。 而是把存储、算力、写错查询的代价放上同一杆秤——哪边更疼，就往反方向让一点。
现实里也常常混用：大维度雪花，小维度星型，同一套数仓里两种都有。
