ClickHouse ReplacingMergeTree去重与版本列实践

概述 - 目标：通过ReplacingMergeTree与版本列实现行级更新与去重，避免重复写入影响查询与统计。 - 适用：事件数据修正、订单状态更新、幂等写入场景。 核心与实战 - 建表（版本列`ver`）： ``` CREATE TABLE orders_rt ( id UInt64, status String, amount Float64, ver UInt32, ts DateTime ) ENGINE = ReplacingMergeTree(ver) ORDER BY (id) PARTITION BY toDate(ts); ``` - 写入更新： ``` INSERT INTO orders_rt VALUES (1, 'PENDING', 10.5, 1, now()); INSERT INTO orders_rt VALUES (1, 'PAID', 10.5, 2, now()); ``` - 查询去重视图： ``` -- 使用 FINAL 强制去重（开销较大，谨慎） SELECT id, status, amount FROM orders_rt FINAL WHERE id = 1; ``` - 物化视图生成去重结果（推荐）： ``` CREATE MATERIALIZED VIEW mv_orders_dedup ENGINE = ReplacingMergeTree(ver) ORDER BY (id) AS SELECT id, anyLast(status) AS status, anyLast(amount) AS amount, max(ver) AS ver FROM orders_rt GROUP BY id; ``` 示例 - 批量统计（避免FINAL）： ``` SELECT status, count() FROM mv_orders_dedup GROUP BY status; ``` - 检查重复： ``` SELECT id, count() AS c FROM orders_rt GROUP BY id HAVING c > 1 ORDER BY c DESC LIMIT 10; ``` 验证与监控 - 合并与去重： - 观察`system.mutations`与`system.parts`合并；确认物化视图数据与源表一致。 - 查询性能： - 避免在大数据量上频繁使用`FINAL`；优先使用预聚合/视图。 - 写入策略： - 确保版本列单调递增；在上游保证幂等与正确顺序。 常见误区 - 未设置版本列导致替换行为不可控；需明确版本列。 - 在高并发下大量使用`FINAL`导致查询慢；应使用视图或离线去重。 - 主键设计不合理导致去重失败；`ORDER BY`需覆盖唯一键。 结语 - 通过ReplacingMergeTree与版本列可在ClickHouse实现高效去重与更新，结合视图与查询策略保证性能与正确性。