ClickHouse中ReplicatedMergeTree与ReplacingMergeTree表引擎的去重机制深度对比
1. 从实际案例看两种表引擎的去重差异
去年我在一个物联网项目中遇到了一个典型场景：设备每隔15秒上报一次状态数据，但由于网络波动，经常出现重复上报的情况。当时我分别用ReplicatedMergeTree和ReplacingMergeTree建了两张测试表，结果发现了很有意思的现象。
用ReplicatedMergeTree建表后插入重复数据，查询时居然看到了完全相同的两条记录。而换成ReplacingMergeTree后，相同主键的记录自动合并成最新的一条。这个现象让我开始深入研究两者的去重机制，发现它们虽然名字相似，但去重逻辑完全不同。
最核心的区别在于去重粒度：ReplicatedMergeTree是在数据块(block)级别去重，而ReplacingMergeTree是在行(row)级别去重。这就好比整理衣柜，前者是把相同的衣服包裹整个扔掉，后者是只留下最新的一件同款衣服。
2. ReplicatedMergeTree的去重机制详解
2.1 数据块级别的去重原理
ReplicatedMergeTree的去重发生在数据同步过程中，主要依赖两个关键参数：
replicated_deduplication_window：默认100，表示保留最近100个数据块的hash值non_replicated_deduplication_window：用于非副本表的去重窗口
我做过一个测试：连续写入100条相同数据，发现只有前几条能成功写入。这是因为ClickHouse会为每个数据块生成唯一的hash值，当发现新数据块的hash值与ZooKeeper中记录的重复时，就会直接丢弃。
-- 创建副本表示例 CREATE TABLE metrics ( timestamp DateTime, device_id String, value Float32 ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/metrics', '{replica}') ORDER BY (device_id, timestamp);2.2 副本同步中的去重流程
在实际写入过程中，主节点会先将数据写入临时目录，然后：
- 计算数据块的checksum
- 将元数据写入ZooKeeper的/log目录
- 副本节点监听ZK变更，拉取新数据
- 检查数据块hash是否已存在
- 若存在则跳过，否则写入本地存储
这里有个容易误解的点：主节点本身不进行hash校验，去重只发生在副本同步阶段。这就是为什么有时候主节点会有重复数据，而副本却没有。
3. ReplacingMergeTree的去重特性解析
3.1 行级去重的实现方式
ReplacingMergeTree通过在合并(Merge)时替换相同排序键的行来实现去重。建表时需要指定版本列：
CREATE TABLE metrics_replacing ( timestamp DateTime, device_id String, value Float32, version UInt32 ) ENGINE = ReplacingMergeTree(version) ORDER BY (device_id, timestamp);我做过性能测试：对于1000万条有10%重复率的数据，ReplacingMergeTree的存储空间比ReplicatedMergeTree节省约15%。但要注意的是，去重不是实时的，只有在后台合并时才会触发。
3.2 最终一致性特点
这里有个重要知识点：ReplacingMergeTree的去重是最终一致的。我曾在生产环境踩过坑——刚写入的数据立即查询，发现重复记录还存在。后来通过以下方式解决：
-- 强制触发合并 OPTIMIZE TABLE metrics_replacing FINAL; -- 查询时去重 SELECT * FROM metrics_replacing FINAL;FINAL关键字会让查询引擎在读取时执行合并操作，但会显著增加查询负载。建议在需要精确去重的查询中使用。
4. 两种引擎的适用场景对比
4.1 ReplicatedMergeTree的最佳实践
根据我的经验，以下场景适合使用ReplicatedMergeTree：
- 需要高可用的监控数据存储
- 日志分析系统
- 数据量巨大且允许少量重复的场合
在某个电商项目中，我们用ReplicatedMergeTree存储用户行为日志，配合TTL实现自动过期，即使有少量重复也不影响分析结果。
4.2 ReplacingMergeTree的典型用例
ReplacingMergeTree更适合这些场景：
- 设备状态表（需要保持最新状态）
- 需要严格去重的维度表
- 数据更新频繁但历史版本不重要的业务
比如在物联网平台中，我们用ReplacingMergeTree存储设备在线状态，确保每个设备只保留最新的一条记录。
5. 高级配置与性能调优
5.1 关键参数优化建议
对于ReplicatedMergeTree，我建议调整：
<merge_tree> <replicated_deduplication_window>500</replicated_deduplication_window> <max_replicated_merges_in_queue>16</max_replicated_merges_in_queue> </merge_tree>对于ReplacingMergeTree，要注意：
-- 合并操作的内存限制 SET max_bytes_to_merge_at_max_space_in_pool = 10737418240;5.2 常见问题排查
遇到过最棘手的问题是ZooKeeper压力过大导致副本同步延迟。通过以下方法解决：
- 增加
replicated_deduplication_window减少ZK写入 - 调整
background_pool_size增加合并线程 - 监控
system.replication_queue表
另一个常见误区是认为ReplacingMergeTree能完全替代唯一约束。实际上它只保证最终一致性，需要实时去重的场景还是要配合FINAL关键字使用。