背景
在一次数据排查时,无意间发现数据对不齐。结合代码及日志分析发现都没问题,且有插入操作,但是 Clickhouse 却查不到改条记录。匪夷所思....
排查过程
最后断定大概率是 Clickhouse 的问题,难道 Clickhouse 存在数据丢失的情况?进一步分析丢失数据部分时间分布发现并无任何规律,排除 Clickhouse 可能出现的定时故障问题。
无奈只能找公司 DBA 寻求帮助,得出大概率是 Clickhouse 的 ReplicatedReplacingMergeTree 问题。该业务表结构大致如下
-- auto-generated definition create table t_product_request_log_local ( id String, merchant_id String, product_code String, order_no String, spend_time UInt16, create_time DateTime default toDateTime(now()) ) engine = ReplicatedReplacingMergeTree('/***/{shard}', '{replica}') ORDER BY (create_time, merchant_id, product_code, order_no) SETTINGS index_granularity = 8192;
其中若是高并发场景 ORDER BY 相当于主键,使用该存储引擎的话聚合的字段可能一致,而 order_no 字段由于历史设计问题部分数据该字段存储和的为外部时间戳,因为导致多条数据被聚合为一条数据插入。
为了验证这一猜想,编写了一个批量插入的 SQL 发现,虽然 SQL 执行成功但是确实无重复的数据,而修改变更其中某个字段值即又能正常插入得出数据。
解决
因此需在 ORDER BY 中新增一个唯一字段,使得后期插入数据唯一即可。因此在 ORDER BY 新增 ID 列得解。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于