clickhouse 物化视图数据查询不稳定分析

wending-Y2025-12-20 8:21

文章目录

问题记录

查询MATERIALIZED VIEW 有时能查到结果，有时查不到结果

创建语句类似

bash 复制代码

CREATE MATERIALIZED VIEW test.test_local on cluster clicks_cluster
engine = ReplicatedMergeTree('/clickhouse/tables/{shard}/test_local', '{replica}')
PARTITION BY toYYYYMMDD(capture_time)
ORDER BY (file_object_id,update_time)
SETTINGS index_granularity = 8192
AS
SELECT
    file_object_id String,
    zone_id Int64
    from 
    table_dis
    
CREATE TABLE test.test_mv on cluster clicks_cluster
(
    file_object_id String,
 
    zone_id Int64
   
)
ENGINE = Distributed('clicks_cluster', 'test', 'test_mv_local', zone_id);

问题分析

有时能查到，有时查不到，感觉可能是副本的问题，有的副本上有数据，有的副本没有数据

导致查询时有时无

为了验证这个猜想，我调整了load_balancing 这个参数的值,从random 换成了这个

SET load_balancing = 'in_order';

果然数据直接查询不出来，是一直稳定复现

修复方案

找了很多线索，最后发现应该和这个建表语句有关

bash 复制代码

//先创建本地表


//创建view ，然后to 表
CREATE MATERIALIZED VIEW IF NOT EXISTS test.test_mv ON CLUSTER clicks_cluster
TO test.test_local
AS
select * xx from yy

解释

为什么普通物化视图（旧写法）在分布式集群上极容易出"数据时有时无"？

ClickHouse 官方文档和大量生产事故都证明了：

当你写：

SQLCREATE MATERIALIZED VIEW xxx_mv AS SELECT ...

ClickHouse 会自动在每个节点创建一个内部表，名字大概是 .inner.xxx_mv 或 .inner_id.xxxx

这个自动创建的内部表路径是 ClickHouse 自己生成的 UUID 形式，例如：

text/clickhouse/tables/{shard}/.inner_id.8a9f1b2c-...

这个路径在集群每次重启、升级、DDL 同步异常、ZooKeeper 短暂失联等情况下，极容易出现不同节点生成的内部表路径不一致！

一旦路径不一致，就会导致：

部分节点认为自己是这个物化视图的副本

部分节点认为自己没有这个表，或者路径对不上，无法参与复制

复制队列彻底乱掉 → 某些 shard 永远收不到新数据 → Distributed 表查出来就是空的