ClickHouse 交易明细系统的整体架构
交易明细从 Kafka 经托管 sink 写进三副本 ClickHouse，单日一千多万到三亿多行。现状是按结算日分区、至少一次写入、单分片三副本靠 Keeper；按键折叠、报表增量聚合加对账重算、整分区替换修数据在 lab 上验过，还没在现有集群上执行。
最新文章
查看全部 →ClickHouse 误删表和分区之后的恢复
上游默认下，DROP TABLE 不加 SYNC 有 480 秒能 UNDROP，DETACH 可逆，DROP PARTITION 只靠 FREEZE 备份，删超过 50 GB 会被拦下。Aiven 上的现有集群里宽限期和大小保险都是 0，误删后只剩备份。
ClickHouse 的 Keeper 故障和 part 过多
写入变慢或被拒时，先看 Keeper 和 part 数。lab 上 Keeper 停掉时副本立刻只读，INSERT 卡约 143 秒才报错；卡住时客户端 30 秒超时，服务端在 Keeper 回来后照样提交。part 过多则先拖慢、后拒绝，中间那段是预警窗口。
ClickHouse 数字对不上的排查顺序
行数对得上、数字却不对，先查时间轴：UTC 16 点到 24 点之间的时刻，在 UTC 和上海两种列声明下会落进相邻两天的分区。再查 JOIN 有没有在右表重复键上放大，去重计数是不是近似的 uniq，上游有没有改字段名让整列变成默认值。
ClickHouse 数据少了的排查顺序
数据少了不报错，常常很久之后才被发现。排查从上游和 Kafka 开始，再看 connector 的错误处理：默认配置下一条坏记录让 task 停住；配了 DLQ，同批同分区的好记录跟着进 DLQ；只开容错不配 DLQ，整批静默消失。
