Clickhouse聚合合并树表重复加载后查询行数不一致问题

1. 源表app_events.events_v2数据在两次插入间发生变更 #

这是最常见的诱因：两次执行INSERT SELECT时，events_v2中event_date='2025-01-01'的数据不一致，导致GROUP BY后的结果行数不同。比如源表可能发生了数据删除、新增、TTL过期，或是分区合并带来的隐式数据变更。

• 验证方式：在两次插入前分别执行以下语句，对比结果行数：

SELECT COUNT(*)
FROM (
    SELECT event_date,
           user_pseudo_id,
           event_params_ga_session_id,
           event_params_ga_session_number
    FROM app_events.events_v2
    WHERE event_date = '2025-01-01'
    GROUP BY event_date, user_pseudo_id, event_params_ga_session_id, event_params_ga_session_number
)

如果两次结果不同，直接坐实源表数据发生了变化。

2. 分布式表插入时出现分片异常（数据丢失） #

用rand()做分片键时，若插入过程中某个分片节点不可用，ClickHouse会跳过该分片，导致部分数据没写入成功。两次插入时分片的可用性不一样，最终数据行数就会有差异。

• 验证方式：
  1. 插入后在每个分片节点上执行以下语句，查看本地表行数，再把所有分片的行数相加，对比两次插入后的总和：

  SELECT COUNT(*) FROM app_events.events_v2_b_local WHERE event_date = '2025-01-01'
  

  若总和不同，说明存在数据丢失。
  2. 查看ClickHouse日志，检查插入过程中是否有分片连接失败、写入错误等记录。

3. 截断表操作未在副本间完全同步 #

因为本地表是ReplicatedAggregatingMergeTree，TRUNCATE TABLE操作需要在所有副本间同步，若同步没完成就执行插入，可能残留旧数据或导致新数据写入异常（不过这种情况通常会让行数增加，而非减少，但仍需排查）。

• 验证方式：
  1. 截断后，在所有副本节点上执行以下语句，确认数据已清空：

  SELECT COUNT(*) FROM app_events.events_v2_b_local WHERE event_date = '2025-01-01'
  

  2. 等待1-2分钟再执行插入，确保截断操作同步完成。

4. 查询时的分布式聚合异常 #

在Distributed表上执行GROUP BY时，若某个分片的查询结果异常（比如网络波动、节点负载过高导致部分数据未返回），会导致最终行数不准。两次查询时集群状态不同，就会出现差异。

• 验证方式：
  1. 直接在每个分片的本地表上执行查询，手动汇总所有分片的结果行数：

  SELECT event_date,
         user_pseudo_id,
         event_params_ga_session_id,
         event_params_ga_session_number,
         minMerge(min_time) as min_time
  FROM app_events.events_v2_b_local
  WHERE event_date = '2025-01-01'
  GROUP BY event_date, user_pseudo_id, event_params_ga_session_id, event_params_ga_session_number
  

  若手动汇总的行数和Distributed表的查询结果一致，说明分布式聚合正常；若不一致，说明存在集群通信或节点异常。

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