获课：xingkeit.top/6591/

ClickHouse 物化视图：让 Flink 的上层统计轻装上阵

实时数仓的架构里，Flink 负责"算"，ClickHouse 负责"存和查"。但很多团队把 Flink 当成万能选手——聚合、去重、Top N、多维统计全塞进 Flink 作业里，结果作业越来越重，延迟越来越高，故障恢复时间越来越长。

ClickHouse 物化视图的出现，恰恰解决了这个问题。它不是 Flink 的替代品，而是 Flink 的减负器。

核心逻辑：把"计算"后移到"写入"

Flink 的强项是流式计算，但它的弱点也很明显——状态管理吃内存，窗口聚合吃 CPU，故障恢复吃时间。如果把本可以在写入时就完成的预聚合，硬塞给 Flink 做，无异于让短跑选手去跑马拉松。

ClickHouse 物化视图的设计哲学完全不同：数据写入时就完成计算，查询时直接读结果。 它本质上是一个 INSERT 触发器——源表每写入一批数据，物化视图自动执行预设的 SELECT 查询，把聚合结果写入目标表。整个过程不占用 Flink 任何计算资源。

举个实际场景：电商大促需要实时统计每分钟各品类的 GMV。传统做法是 Flink 开窗口做聚合，结果写 Redis 或 ClickHouse。但如果用 ClickHouse 物化视图，Flink 只需要把原始订单流写入 ClickHouse 的源表，聚合逻辑交给物化视图自动完成。查询时直接读聚合表，响应时间从秒级降到毫秒级。

三层架构：Flink 做清洗，物化视图做聚合，ClickHouse 做查询

最成熟的实践是三层分工：

第一层，Flink 负责数据清洗和轻度计算。 比如 JSON 解析、字段提取、异常数据过滤、维度补全。这些逻辑复杂且需要状态管理的工作，交给 Flink 最合适。

第二层，ClickHouse 物化视图负责预聚合。 Flink 清洗后的数据写入 ClickHouse 源表，物化视图自动按分钟、按小时、按品类完成聚合，结果存入 SummingMergeTree 或 AggregatingMergeTree 表。这一步完全不需要 Flink 参与，写入即计算，计算即存储。

第三层，查询层直接读聚合表。 前端看板、BI 工具、API 接口，全部查询物化视图的目标表。因为数据已经预聚合过，十亿级数据的 COUNT 查询也能在亚秒级返回。

这套架构的精妙之处在于：Flink 作业变轻了，只做清洗不做聚合，状态规模大幅缩小，故障恢复从分钟级降到秒级。而聚合能力并没有丢失，只是从 Flink 转移到了 ClickHouse。

物化视图 vs Flink 聚合：什么该放哪边

不是所有计算都适合放进物化视图。判断标准很简单：

适合放物化视图的： 单表聚合、简单 GROUP BY、固定时间窗口统计、UV 去重。这些计算确定性强，写入时就能完成，且结果不会频繁变更。

必须留在 Flink 的： 多表 JOIN、需要精确一次语义的去重、复杂事件处理（CEP）、需要回溯修正的逻辑。物化视图对源表的 UPDATE、DELETE 不会触发更新，这些场景只能靠 Flink 的状态管理来保证正确性。

一个经验法则：如果一个聚合查询能用一条 SQL 写清楚，就交给物化视图；如果需要多步状态流转，就留在 Flink。

实战中的关键细节

写入节奏要控制。 Flink 往 ClickHouse 写数据时，必须用批量提交机制，比如每 5000 条或每 2 秒触发一次写入。否则小文件爆炸会直接拖垮查询性能。Flink 的背压机制在这里能自动调节流速，ClickHouse 写不动时 Flink 会主动减速。

目标表引擎要选对。 聚合场景用 SummingMergeTree 或 AggregatingMergeTree，去重场景用 ReplacingMergeTree 加 FINAL 关键字。引擎选错，聚合结果要么不准，要么查不到。

别滥用 POPULATE。 创建物化视图时如果加了 POPULATE，会把历史数据全部重新插入，源表已有数据的情况下会导致重复。正确做法是先创建空视图，再用 INSERT INTO ... SELECT 补历史数据。

本质：让每个组件做它最擅长的事

Flink 擅长流式计算和状态管理，ClickHouse 擅长列式存储和极速查询，物化视图则是连接两者的桥梁——它让 ClickHouse 在数据写入时就完成 Flink 本该做的聚合工作。

这不是谁替代谁的问题，而是分工明确后的效率飞跃。当 Flink 不再需要扛着聚合的重担跑流式作业，整个实时数仓的稳定性、可维护性和查询性能都会上一个台阶。

架构设计的最高境界，不是让一个组件无所不能，而是让每个组件只做一件事，但做到极致。