ClickHouse Replicated表搭配Buffer表的块级去重与写入可靠性问题

「仅能保证at least once语义」的推论判定 #

你的推论完全成立。
Replicated MergeTree系列表的原生块级去重能力，核心依赖写入块的唯一哈希标识——这个哈希会基于单次写入块的行顺序、数据内容、块大小共同计算，副本节点收到写入请求时会对比已经提交过的块哈希列表，哈希重复的写入请求会被直接跳过，以此实现exactly once写入保障。
但写入目标为Replicated表的Buffer表时，Buffer引擎不会将客户端每次提交的原始写入块直接透传给下游目标表，而是会按照预设的刷盘阈值（时间、累计行数、累计数据量）将多个写入批次的数据在内存中攒批重组后再刷入，这个重组过程会直接打破原始写入的块边界：

• 攒批合并时行顺序会发生随机调整
• 最终刷入下游的块大小、数据组合和客户端原始提交的批次没有对应关系
  这种情况下原生块级去重的判断依据完全失效：如果发生客户端超时重传、节点故障重试等场景，重试写入的数据进入Buffer后会和其他批次数据重新组合，最终生成的块哈希和之前可能已经写入成功的块哈希完全不同，去重逻辑无法识别重复写入，必然会出现重复数据，因此该场景下确实只能提供*至少一次（at least once）*写入语义，无法实现可靠的精确一次写入。

极端场景下的数据丢失可能性 #

该组合使用场景下确实存在数据丢失的风险，核心风险来自Buffer引擎本身的内存设计特性，主要包含几类典型场景：

• Buffer表中暂存的未刷盘数据全量存储在内存中，如果刷盘完成前节点发生进程崩溃、机器掉电、强制重启，内存中滞留的所有数据会直接丢失，没有副本、日志可以用于恢复这部分数据
• 如果Buffer表配置的刷盘阈值过高（比如单Buffer允许缓存的字节数、行数上限过大，刷盘时间间隔过长），内存中累计数据过多触发进程OOM被系统强杀，同样会导致所有未刷盘的数据丢失
• Buffer触发刷盘到下游Replicated表的过程中如果遇到网络闪断、瞬时节点故障导致刷盘中断，在部分老版本ClickHouse中存在边缘bug，可能出现部分数据未成功重试刷入下游的情况，导致数据遗漏。

实践提示：如果必须在Replicated表前使用Buffer表，不要依赖引擎原生的精确一次能力，需要业务侧自行添加唯一标识，借助ReplacingMergeTree等引擎的最终去重能力实现业务层幂等；同时尽量调低Buffer的刷盘阈值，缩短数据在内存中滞留的时间窗口，降低丢数风险。

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