1. StarRocks 数据模型概述
1.1 StarRocks 是什么？
先聊聊 StarRocks 的定位。它是一款 MPP 架构的极速全场景 OLAP 数据库。说白了，就是专门用来做「大屏秒开、报表即查、Ad-hoc 分析」这类事情的。
我最早接触 StarRocks 是在 2021 年，当时团队正被 ClickHouse 的 Join 性能和物化视图维护搞得焦头烂额。StarRocks 给我的第一印象是：向量化执行引擎 + CBO 优化器 + 物化视图透明改写，这三板斧确实能解决很多实际问题。
它的核心能力可以概括为三点：
- 极速查询：单表聚合秒级响应，多表 Join 也能在秒级完成
- 实时更新：支持高频写入，数据可见性延迟控制在秒级
- 高并发：单集群能支撑数千 QPS 的并发查询
一句话总结：StarRocks 不是万能的，但在「大宽表聚合 + 实时更新 + 高并发」这个三角区域里，它是我目前用过最顺手的引擎。
1.2 数据模型概念
数据模型，其实就是你告诉 StarRocks：「我的数据长什么样，我要怎么查它，你该怎么存。」
StarRocks 提供了三种数据模型：
| 数据模型 | 核心特点 | 适用场景 |
|---|---|---|
| 明细模型 (Duplicate Key) | 保留所有原始数据，不做任何聚合 | 日志、交易流水、行为轨迹 |
| 聚合模型 (Aggregate Key) | 按维度列聚合，预计算指标 | 报表、大屏、KPI 看板 |
| 更新模型 (Unique Key) | 按主键去重，支持行级更新 | 订单状态、用户画像、维表 |
每种模型背后，对应着不同的存储结构和查询优化策略。选错了模型，轻则查询慢几倍，重则数据不准、内存爆掉。
⚠️ 注意：数据模型在建表时确定，一旦创建就不能修改。我见过不少团队上线后才发现模型选错了，只能重建表、重导数据，代价非常大。
1.3 为什么需要选择合适的数据模型？
这个问题，我用一个真实案例来回答。
去年有个客户做用户行为分析，每天几亿条埋点数据。他们一开始用了聚合模型，想着预计算 PV/UV 能快一些。结果发现：
- 业务方经常要查「某个用户在某天的完整行为路径」—— 聚合模型把明细丢了，查不了
- 埋点字段经常变，聚合模型改 Schema 很麻烦
- 预计算粒度固定，业务想下钻到小时级，得重建表
后来改成明细模型，配合物化视图做预聚合，问题全解决了。
反过来，另一个做实时报表的客户，用了明细模型存订单数据。每次查「当天各渠道 GMV」都要扫描全量数据，一个 10 亿行的表，查询耗时 30 秒以上。改成聚合模型后，同样的查询降到 0.5 秒。
所以，选模型的核心原则就三条：
- 先看查询场景：是查明细还是查聚合？是点查还是范围查？
- 再看更新方式：数据是只追加，还是需要更新/删除？
- 最后看数据量：每天增量多大？历史数据怎么处理？
💡 我的习惯：拿到需求后，先画一张「查询场景 × 更新模式」的矩阵图，再选模型。这样不容易漏掉边界情况。
1.4 本章知识体系总览
下面这张图，把三种数据模型的核心差异和选择逻辑串起来了。你可以把它当作后续章节的导航图。
这张图里，我把三种模型的核心特征、适用场景和选择建议都标出来了。你可以看到：
- 明细模型在左上角，适合需要保留原始数据的场景
- 聚合模型在中间，适合固定维度的预计算场景
- 更新模型在右上角，适合需要行级更新的场景
后面的章节，我会逐一深入每种模型的建表语法、存储原理、查询优化和真实案例。嗯，咱们先从明细模型开始聊起。