2. 数据模型设计对性能的影响：星型模型、雪花模型、宽表模型的选择与权衡

聊到数据仓库性能，很多人第一反应是调SQL、加索引、换硬件。但我做了十几年数仓，得说句实话：模型设计没搞对，后面再怎么优化都是事倍功半。模型就像房子的地基，地基歪了，装修再豪华也住不踏实。

这一章，咱们就掰开揉碎聊聊三种主流模型——星型、雪花、宽表。我会结合自己的踩坑经历，帮你理清什么时候该用谁，什么时候千万别用谁。

2.1 星型模型：最稳妥的选择

星型模型长什么样？说白了就是一张事实表在中间，周围围着好几张维度表，像星星一样辐射出去。事实表存度量（比如销售额、订单量），维度表存描述信息（比如时间、产品、客户）。

我个人的习惯是：只要没有特殊理由，默认就用星型模型。为什么？因为它把查询性能和解耦性平衡得最好。

举个例子，一个电商订单分析场景：

-- 星型模型示例
-- 事实表：fact_order
CREATE TABLE fact_order (
    order_id      BIGINT,
    date_key      INT,      -- 指向dim_date
    product_key   INT,      -- 指向dim_product
    customer_key  INT,      -- 指向dim_customer
    amount        DECIMAL(10,2),
    quantity      INT
);

-- 维度表：dim_product
CREATE TABLE dim_product (
    product_key   INT PRIMARY KEY,
    product_name  VARCHAR(100),
    category      VARCHAR(50),
    brand         VARCHAR(50)
);

-- 查询：按品类统计销售额
SELECT 
    p.category,
    SUM(f.amount) AS total_sales
FROM fact_order f
JOIN dim_product p ON f.product_key = p.product_key
GROUP BY p.category;

你看，查询只需要一次JOIN，逻辑清晰，执行计划也简单。我在项目中遇到过好几次，团队里新人上手星型模型基本没障碍，但换成雪花模型就经常写错JOIN条件。

2.2 雪花模型：存储换来的代价

雪花模型是星型的变种。它把维度表继续拆分成更细的层次。比如产品维度，星型里一张表搞定，雪花里可能拆成产品表、品类表、品牌表三张。

这样做的好处是啥？减少数据冗余。你想想看，如果1000万个产品都重复存品类名称，确实浪费空间。但代价也很明显——查询要多做几次JOIN。

-- 雪花模型示例
-- 维度表拆分成多层
CREATE TABLE dim_category (
    category_key  INT PRIMARY KEY,
    category_name VARCHAR(50)
);

CREATE TABLE dim_brand (
    brand_key     INT PRIMARY KEY,
    brand_name    VARCHAR(50)
);

CREATE TABLE dim_product (
    product_key   INT PRIMARY KEY,
    product_name  VARCHAR(100),
    category_key  INT,      -- 指向dim_category
    brand_key     INT       -- 指向dim_brand
);

-- 查询：按品类统计销售额（需要两次JOIN）
SELECT 
    c.category_name,
    SUM(f.amount) AS total_sales
FROM fact_order f
JOIN dim_product p ON f.product_key = p.product_key
JOIN dim_category c ON p.category_key = c.category_key
GROUP BY c.category_name;

我曾经在一个金融项目中接手过雪花模型。当时觉得设计挺精巧，冗余少，ETL也简单。结果上线后，一个跨多维度的大查询跑了20分钟还没出结果。后来我把它改造成了星型，查询时间降到了30秒。

2.3 宽表模型：极致的性能，极致的代价

宽表模型，说白了就是把所有维度字段全部塞进事实表里。一张表，几百个字段，查询时零JOIN。

性能确实好。我做过测试，同样一个聚合查询，宽表比星型快3-5倍，比雪花快10倍以上。但代价呢？

• 存储膨胀：维度字段重复存储，数据量可能翻几倍
• ETL复杂：维度变化时要更新大量行，处理缓慢变化维度（SCD）很痛苦
• 维护困难：加一个维度字段就要改表结构，几百个字段的表谁看了都头疼

-- 宽表模型示例
-- 所有维度字段平铺
CREATE TABLE wide_order (
    order_id        BIGINT,
    order_date      DATE,
    year            INT,
    month           INT,
    day             INT,
    product_name    VARCHAR(100),
    category_name   VARCHAR(50),
    brand_name      VARCHAR(50),
    customer_name   VARCHAR(100),
    customer_city   VARCHAR(50),
    customer_level  VARCHAR(20),
    amount          DECIMAL(10,2),
    quantity        INT,
    -- 可能还有几十上百个字段...
);

-- 查询：直接查，零JOIN
SELECT 
    category_name,
    SUM(amount) AS total_sales
FROM wide_order
GROUP BY category_name;

2.4 三种模型的对比总结

对比维度	星型模型	雪花模型	宽表模型
查询性能	高（1次JOIN）	中（多次JOIN）	极高（零JOIN）
存储成本	中	低（冗余少）	高（冗余多）
ETL复杂度	低	中	高
维度变化处理	容易	较容易	困难
可维护性	高	中	低
新人上手难度	低	中	低（但维护难）

2.5 我的选型建议

说了这么多，到底怎么选？我总结了几条经验：

1. 默认选星型。80%的场景它都够用，别为了炫技搞复杂。
2. 存储成本敏感时考虑雪花。但要做好性能测试，别省了存储丢了性能。
3. 实时查询要求极高时用宽表。但要做好数据同步和维度管理的预案。
4. 混合使用也是可以的。我做过一个项目，核心维度用星型，一些不常用的维度用雪花，实时模块用宽表。灵活搭配才是王道。