物化视图 + ReplacingMergeTree ===＞＞ 自动去重 + 聚合

在 ClickHouse 的实际应用中，数据去重 是一个非常常见的需求，尤其是在处理日志、事件流、用户行为等可能存在重复写入或状态更新的场景中。

结合 物化视图（Materialized View） 与 ReplacingMergeTree 表引擎，是实现 自动去重 + 聚合 的经典且高效方案。本篇将深入详解这一组合的原理、配置、使用场景和最佳实践。

---

🎯 一、为什么需要“物化视图 + ReplacingMergeTree”？

典型场景

• 用户行为日志可能因重试机制被重复写入
• 状态类数据（如用户等级、订单状态）会多次更新
• 需要“最终一致性”的聚合结果（如每个用户的最新行为）

传统方式的问题

• 手动 GROUP BY ... argMax() 复杂且慢
• DISTINCT 性能差，不适合大数据
• UPDATE 不支持，无法原地更新

✅ 解决方案：
物化视图监听源表 → 写入 ReplacingMergeTree 表 → 合并时自动去重

---

🏗️ 二、核心组件解析

1. ReplacingMergeTree —— 自动去重的表引擎

✅ 原理

• 基于 主键（或版本列） 合并重复行
• 后台 Merge 任务会保留 最新版本 的数据
• 不是实时去重，而是“最终一致性”

✅ 语法

ENGINE = ReplacingMergeTree([version])
ORDER BY (key1, key2)

• version：可选，用于决定哪条记录更新（如时间戳、版本号）
• 若无 version，则保留任意一条（通常为最后插入）

---

2. 物化视图（Materialized View）—— 自动写入管道

• 监听源表的插入
• 自动将数据转换并写入目标表（即 ReplacingMergeTree 表）
• 实现“写入即处理”

---

🔗 三、架构设计：整体流程

[原始数据表] 
     │
     ↓ (INSERT)
[物化视图] → 过滤/转换
     │
     ↓
[ReplacingMergeTree 表] → 按主键去重，保留最新
     │
     ↓
[查询] → 使用 FINAL 或 GROUP BY 获取去重结果

---

📦 四、实战：实现用户行为去重聚合

1. 创建原始表（原始日志）

CREATE TABLE user_log_raw (
    user_id UInt32,
    event_date Date,
    action String,
    device_id String,
    update_time DateTime  -- 用于去重版本
) ENGINE = MergeTree()
ORDER BY (event_date, user_id);

✅ 假设数据可能重复写入（如客户端重试）

---

2. 创建去重目标表（ReplacingMergeTree）

CREATE TABLE user_log_dedup (
    user_id UInt32,
    event_date Date,
    action String,
    device_id String,
    update_time DateTime
) ENGINE = ReplacingMergeTree(update_time)  -- 以 update_time 为版本列
ORDER BY (user_id, event_date);

✅ 合并时会保留 update_time 最大的那条记录

---

3. 创建物化视图（自动写入去重表）

CREATE MATERIALIZED VIEW mv_user_log_to_dedup
TO user_log_dedup
AS SELECT
    user_id,
    event_date,
    action,
    device_id,
    update_time
FROM user_log_raw;

✅ 效果：每插入一条原始数据，物化视图自动写入 user_log_dedup

---

4. 插入测试数据（模拟重复）

-- 第一次写入
INSERT INTO user_log_raw VALUES 
(1001, '2024-04-01', 'login', 'dev123', '2024-04-01 10:00:00');

-- 重复写入（如重试）
INSERT INTO user_log_raw VALUES 
(1001, '2024-04-01', 'login', 'dev123', '2024-04-01 10:00:00');

-- 更新状态
INSERT INTO user_log_raw VALUES 
(1001, '2024-04-01', 'logout', 'dev123', '2024-04-01 10:05:00');

---

5. 查询去重结果

方式 1：使用 FINAL（强制合并查询）

SELECT * FROM user_log_dedup FINAL WHERE user_id = 1001;

⚠️ 注意：FINAL 性能差，不推荐用于大表或高频查询

方式 2：使用 GROUP BY + argMax（推荐）

SELECT
    user_id,
    event_date,
    argMax(action, update_time) AS action,
    argMax(device_id, update_time) AS device_id
FROM user_log_dedup
GROUP BY user_id, event_date;

✅ 输出：

1001 | 2024-04-01 | logout | dev123

---

🔄 五、后台合并机制（Merge）

• ClickHouse 后台会自动合并数据片段（Part）
• 在合并过程中，ReplacingMergeTree 会根据 ORDER BY 键和 version 列去重
• 不是实时去重，而是“最终一致性”

查看合并状态

SELECT 
    table,
    name,
    rows,
    modification_time
FROM system.parts 
WHERE table = 'user_log_dedup';

---

📊 六、适用场景

场景	是否适用
日志去重（相同 ID 多次写入）	✅
用户状态更新（如登录/登出）	✅
订单状态变更（created → paid → shipped）	✅
实时数仓 CDC 数据处理	✅（配合 Kafka）
高频点查最新状态	⚠️（需配合 argMax 查询）

---

⚠️ 七、注意事项与陷阱

问题	解决方案
FINAL 性能极差	改用 GROUP BY + argMax
去重不是实时的	依赖后台合并，延迟可能几秒到几分钟
version 列必须单调递增	否则可能保留旧数据
物化视图只响应 INSERT	UPDATE/DELETE 不触发
小 Parts 过多影响性能	批量写入，避免高频小写

---

✅ 八、最佳实践建议

项目	推荐做法
主键设计	ORDER BY (business_key, partition_key)
版本列	使用 DateTime 或 UInt64 时间戳
查询方式	优先 GROUP BY + argMax，避免 FINAL
写入批次	每批 > 1000 行，减少 Parts
监控	监控 system.parts 和 system.merges
替代方案	超高频更新 → 考虑 AggregatingMergeTree + state/merge

---

🎯 九、总结：物化视图 + ReplacingMergeTree 的核心价值

能力	说明
🔄 自动去重	后台合并时保留最新版本
📥 实时摄入	物化视图自动写入，无需外部 ETL
🧩 结构转换	可在物化视图中做字段映射、过滤
⏳ 最终一致性	适合“最终正确”的业务场景
🚀 高性能查询	去重后数据量减少，查询更快

🎯 这套组合拳是 ClickHouse 处理“状态流”数据的“标准答案”。

---