ClickHouse物化视图能否从多个其他物化视图填充？对应架构是否可行？

你当前的架构有基础可行性，但存在明确的适用边界，不能覆盖所有场景：

• 可行的前提：你的业务仅要求最终一致性，可容忍数据同步窗口期内的不一致查询结果。ReplacingMergeTree（简称RMT）通过主键去重的逻辑，刚好匹配上游多视图不定时同步导致的重复写入、旧数据残留问题，只要配置正确的排序键与版本字段，后台合并完成后会自动保留最新版本数据，开发和运维成本都很低。
• 存在的隐患：RMT的去重是异步触发的，合并完成前查询仍会读到多版本重复数据，即使查询时加FINAL关键字，大表场景下会严重拖慢查询性能，本质上只是缩小了不一致的时间窗口，并没有解决不一致的问题。如果你的最终层需要做多表关联、预聚合计算，多版本重复数据还会直接导致聚合结果错误，并非你预想的“不会引发严重问题”。

根据不同的一致性要求可选择对应优化方案：

可接受最终一致性的场景 #

可在现有方案基础上做优化，不用完全重构：

• 给最终层表新增update_version字段作为RMT的版本列，每次上游同步触发写入时全局递增该版本号，查询时固定添加WHERE update_version = 已发布的最大版本号过滤条件，配合定期执行OPTIMIZE TABLE 最终层表 FINAL手动触发合并，降低日常查询加FINAL的性能损耗。
• 如果最终层存储的是预聚合结果，建议改用AggregatingMergeTree/SummingMergeTree引擎搭配AggregateFunction类型存储，存储效率和查询性能远高于RMT方案。

要求严格快照一致性的场景 #

如果业务要求每次查询结果都是完整的、无中间状态的数据，建议换用以下方案：

• 分区版本切换方案：给最终层表按版本号做分区，每次上游所有物化视图都完成一轮同步后，再将新版本的全量汇总数据写入新分区，写入完成后再删除旧版本分区，全程对外提供的都是完整版本的数据，完全消除不一致窗口。
• 增量水位校验方案：如果全量写入成本过高，可给每个上游物化视图配置同步完成的水位标记，最终层查询时只过滤所有上游都已同步完成的水位区间的数据，从查询层面避免读取半同步的中间数据。

内容的提问来源于stack exchange，提问作者Ivan Kolyhalov