第一次：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不可用，为了保证数据的一致性，系统就会进行“写保护”，出现上述提示。
- 解决办法：
- 方案1：调整use_minimalistic_part_header_in_zookeeper参数； 网上有些朋友说是调整这个参数可以减少写入zk日志的数据量，但因为我们使用的是21的版本，此版本默认这个参数已经是开启了，因此这个方案对我们实际无效。
- 方案2：一个CH集群使用多个zk集群来提供服务； 这属于压力转移的策略，我们最后也无奈使用了这种办法，当然能解决问题，但带来的副作用就是zk集群运维管理成本的上升。
第三次：ClickHouse 插入无法部分成功，statement execute 失败之后，事务 context 会断开，会导致你 commit 的时候，整体失败，因为每次我都插入20-50万条记录，其中一两条数据异常会导致其他几十万数据也插入失败，最终导致插入10亿条数据的时候有几百万数据未插入，
这里我的方案是，statement execute 失败之后，不立即回滚，跑完所有语句，然后记录所有失败的语句，最后回滚事务，然后再重启一个事务，剔除异常的数据之后，再跑一次，那么就会只有少量失败记录插入失败，把这些失败数据写入 redis 集合，后续再处理。
第四次：es 按月分索引，读取数据 scroll 默认按 _doc 排序，这个查询效率是最高的，但是因为不是按照时间序排的，取出来的数据可能分布在不同的天，而 ClickHouse 是按照天来建立 partition,这样就导致了，每次插入的 50万数据，会分配到 N 个分区，由于 ClickHouse 的合并是按照分区来的，这样就导致每次插入需要合并 N 个分区，ck 压力暴增，最终拒绝服务，所以这里需要按照时间排序来 scroll es 数据，这样子，每次插入的数据，以及最近一段时间插入的数据，基本上都在同一天，提升了 ClickHouse 合并效率。
修改前每分钟 600万插入，CPU使用率在高位运行，说明一直在合并数据，修改后每分钟插入 400万数据，会慢一些，但是 CPU 一直在 10% 以下。
从上图还可以看出，之前的数据插入，会一直写到热盘，并且等合并完成之后，才会合并数据并迁移到冷盘，优化之后，会持续合并数据到冷盘，热盘的整体使用率一直稳定在低位。
迁移程序也因为数据处理速度快，避免了数据堆积，内存占用大的问题。
