本文记录了在将350亿条数据从Elasticsearch迁移到ClickHouse过程中遇到的问题及解决策略。包括ClickHouse的CPU和内存压力上升、too many parts错误、部分插入失败以及数据排序导致的合并效率低下。解决方案涉及读写速度控制、批量插入优化、事务处理策略调整和数据按时间排序。优化后，ClickHouse的CPU使用率降低，合并效率提升，避免了数据堆积和内存占用过大的问题。
第一次：es 读取速度快，ClickHouse 插入速度慢，导致ClickHouse CPU和内存压力缓慢上升，最终打爆，于是读与写分离，这里对 es 读取功能加了速度控制功能，在 scrollid 不到期的情况下，能够动态调整速度两边保持平衡。
第二次：ClickHouse 每次插入的数据少，然后插入次数比较频繁，会报错too many parts，这里推荐每批次插入20-50万条数据最佳，否则会导致ClickHouse 频繁的数据合并，我这边读 es 线程每次 scroll 65000 条记录，写 ClickHouse 线程开了 100 个，判断队列长度大于 20 万的时候，一次全部取出，然后插入 ClickHouse。
如果报错如下错误，问了腾讯云，也是加大每批次的插入数据条数，减少与 CK 的交互次数，因为小文件过多，后台就会生成很多的 merge 任务。
Table is in readonly mode
- 问题现象：在笔者的项目环境下，由于存在大数据量的数据写入（200MB/s以上的写入速度），时常会在clickhouse-server的日志中看到
Table is in readonly mode的告警信息。 - 问题原因：翻阅资料后发现这其实是很多人都会遇到的一个问题，大体原因当然是和zk的处理性能相关，随着写入数据量的增多，zk的log和snapshot文件会不断膨胀，有时就会出现zk服务不可用的情况，而clickhouse的ReplicatedMergeTree又强依赖于zk，一旦zk不可用，为了保证数据的一致性&#x
最低0.47元/天 解锁文章
扫一扫
8247
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
