之前一个spark写ck的任务，某天开始频繁报错如下：

Too many parts (300). Merges are processing significantly slower than inserts (version 21.6.5.37 (official build))。

之前在网上查了查该问题，了解到：当数据插入到clickhouse时，会生成parts文件，clickhouse后台会有合并小文件的操作。当插入速度过快，生成parts小文件过快时，clickhouse无法以适当的速度合并这些parts时会报上面这个错误。

解决方法有两种方式：

一、降低insert clickhouse速度

我选择spark savetock 的并行度，在数据插入ck之前，进行repartition操作。我spark任务总共时4cores,我repartition=4设置数据插入ck的并行度为4。降低并行度后，任务重新跑了一次，没有出现上面那个报错。（但是在之后几天还是会出现这个报错，说明没有找到根本原因，于是采用网上说的方法二继续解决这个问题）

二、修改clickhouse config.xml 中有关merge_tree配置

拉大插入间隔，每次插入的数据量大一些，merge_tree添加如下配置：

<parts_to_delay_insert>600</parts_to_delay_insert> <parts_to_throw_insert>600</parts_to_throw_insert> <max_delay_to_insert>2</max_delay_to_insert> <max_suspicious_broken_parts>5</max_suspicious_broken_parts>

我这ck集群有三台，分别添加上面配置后，我重启了clickhouse集群： systemctl restart clickhouse-server.service

目前再跑任务没有出现上面的报错了。。

但是更改这个配置后有一个问题，就是我插入ck速度变慢了，导致我后面的跑批跑了很长时间才跑完，这个方法也pass掉。

三、调大改任务插入ck batchsize的值

于是重新思考解决问题思路，既然要减慢插入ck生成小文件的速度，直接把插入ck数据的bathsize调大一点不就可以了吗，（这是最直接的了，不知道当时为啥没想到）

我比较了发现报错任务spark要插入ck的数据量为：4130135，而没有报错的任务spark要插入ck的数据量最大才100多万；而代码中存储ck代码都是复用的，发现batchsize设置的是1000，这就解释了为啥只有400多万条的任务报错而其他任务不报错，因为他数据量多，而插入批次又小，产生的小文件多，ck合并小文件的速度跟不上插入速度，只需要把这个任务的batchsize 调大些就可以了，我把batchsize=50000,不仅问题解决了，而且运行速度提高了好几倍！

ps:至于为什么它batchsize设置1000这么少，我发现他有一个spark任务数据字段有200多个，如果插入batchsize批次条数设置较大的话，会报：java.lang.OutOfMemoryError: Java heap space 内存不足，没办法集群节点内存很小。

把 方法一和方法二忘掉吧

参考博客文章：1.解决clickhouse报在后台将较小的parts合并为较大parts异常的问题_云深海阔专栏-CSDN博客

2.clickhouse的too many part问题_kangseung的博客-CSDN博客

3.【ClickHouse系列】写入频繁时为什么易产生Too many part问题_一只努力的微服务-CSDN博客_clickhouse频繁写入