/tags/aggregatingmergetree/ Recent content in AggregatingMergeTree on Hugo -- gohugo.io en Sun, 11 Oct 2026 08:20:00 +0800 /posts/clickhouse-report-materialized-view/ Sun, 11 Oct 2026 08:20:00 +0800 /posts/clickhouse-report-materialized-view/ 背景 交易明细一天两三亿行，报表要按不同时区出日报、周报、月报。每次都从明细现算，读的是整天甚至整月的明细；明细表换成 ReplacingMergeTree 之后还要带 FINAL（查询路径那篇）。常见的做法是在写入时就把明细增量聚合进一张小得多的报表表，查询只读报表，官方最佳实践的说法是写入时增量计算之后，查询面对的数据小得多（Use materialized views）。 Aiven 上现有集群的聚合表按写入时间 create_time 的窗口增量累加，不按业务键去重。这篇写的是改过的报表链路：明细表 → 物化视图 → 报表表，桶按业务时间切。它在 clickhouse-lab 的实验 24、25 里跑过（25.3.14.14，三副本），还没部署到现有集群。报表会因为哪些重复多算、怎么对账和重算，放在报表的对账和重算那篇。 物化视图是插入时的触发器 ClickHouse 的增量物化视图，文档原话是「just a trigger that runs a query on blocks of data as they’re inserted into a table」（Incremental materialized view）。源表每插入一个块，就拿这个块跑一遍视图的 SELECT，结果写进目标表。 它只看得到这一次新插入的块，看不到源表里已有的数据，也看不到之后发生的合并、mutation 和删除。好处是代价和写入量成正比，不用回头扫明细；代价是明细后来被折叠、被修改，报表不会跟着变。这一点决定了报表必须能对账、能重算。 三张表怎么建 层 引擎 键 为什么这样建 明细 ReplicatedReplacingMergeTree(create_time) 和现表一致：按结算日分区，ORDER BY (settle_ms, id, rev) 现有集群上见过的三种重复都是除 create_time 外整行相同，排序键相同，合并或 FINAL 时折成一行 报表 ReplicatedAggregatingMergeTree UTC 的 30 分钟桶加维度，PARTITION BY toYYYYMMDD(bucket) 按天分区，和明细的日分区一一对应，修一天只换报表的一个分区 物化视图 CREATE MATERIALIZED VIEW … TO 报表表 — 显式写目标表：重算时要往报表表换分区；报表表本身可以单独 ALTER，不用连带重建视图 实验 25 里报表表和物化视图是这样建的，events 是明细表，表名换成了这个系列里统一的名字，引擎参数按现有集群的 Replicated 库省略：