初次使用ClickHouse，基本都会碰到如下图中too many parts的报错。本文将具体介绍报错原因和优化方案。

频繁写入ClickHouse报错原因

如上图所示，clickhouse操作数据的最小操作单元是block，每次写入，都会按照zookeeper记录的唯一自增的blockId，按照PartitionId_blockId_blockId_0生成data parts，也就是小文件，然后后台会有merge线程，不定时（分钟级别）的将多个小文件进行合并，生成PartitionId_MinBlockNum_MaxBlockBum_Level的文件，未达到data parts最小rows或者大小限制前，会持续merge，每次merge的耗时大概5分钟左右。由于merge线程池是固定的，默认32，所以如果插入过于频繁，merge压力过大，处理不了，就会出现too many parts的报错。

实时写入引入缓存buffer

基于实时清洗，如果延时要求高，可以使用redis做缓存，根据时间窗口期和固定写入阈值（针对波动大的可以按照二次指数平滑函数去确定阈值）进行写入与否的判断；如果能接受一定的时延，可以使用flink的窗口去做。

离线服务使用预构集群

离线导入的数据量一般比较大，可以基于spark调度任务，预先进行数据的shuffle和排序，然后写入预构集群，这样可以提前merge成data parts，然后通过remote推送到正式的ClickHouse集群，这样可以减少正式集群的merge压力，同时达到读写分离。

ClickHouse配置优化

ClickHouse存储方式优化

ClickHouse默认Wide，我们可以针对业务场景特点和数据量，对于一定数据量（条数&大小两个方面）以下，选择Compact，这样可以减少merge压力和时间，针对超过的使用wide。

调大后台Merge线程池数量

通过backbackground_pool_size调整merge线程大小，默认是32，这个结合ClickHouse服务器进行适当调整，不宜过大

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。