首页/数据/NoSQL 速查/分析建模:星型模型与预聚合落地
选型与架构50 条

分析建模:星型模型与预聚合落地

分析库建模先决定事实表粒度与常用过滤维度,再决定预聚合程度:ClickHouse 等列式库不支持高频 join,常把维度冗余进宽表(大宽表),并用物化视图维护聚合结果;牺牲存储与写入复杂度换查询延迟。

NoSQL 速查数据更新于 2026-10-12

物化视图预聚合(ClickHouse 示例)

物化视图预聚合(ClickHouse 示例)
-- 明细表:按 (tenant, ts) 排序,支撑明细查询
CREATE TABLE logs.events (
  tenant String, ts DateTime, service LowCardinality(String),
  ok UInt8, latency_ms UInt32
) ENGINE = MergeTree ORDER BY (tenant, ts);

-- 物化视图:写入时增量维护分钟级聚合
CREATE MATERIALIZED VIEW logs.events_1m
ENGINE = SummingMergeTree ORDER BY (tenant, service, minute)
AS SELECT tenant, service, toStartOfMinute(ts) AS minute,
          count() AS cnt, sum(ok) AS ok_cnt, avg(latency_ms) AS latency_avg
   FROM logs.events GROUP BY tenant, service, minute;
宽表把维度冗余进事实表,查询不做 join;更新维度要回填
星型模型维表独立、更新简单;查询 join 成本高,适合能缓存 join 结果的场景
预聚合物化视图/汇总表;查询快,口径要与明细保持一致并版本化
预聚合的口径要写清楚(去重方式、时区、含不含迟到数据):口径含糊的汇总表会在对账时与明细打架。

易错点

  • 物化视图只对插入生效:历史数据要手动 INSERT SELECT 回填,否则聚合结果缺一段
  • 汇总表与明细表口径不一致且无版本记录:对账差异时无法定位是谁算错

数据来源与参考

  • ClickHouse Docs: Materialized view
  • ClickHouse Docs: MergeTree
  • ClickHouse Docs: SummingMergeTree
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌