初次使用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服务器进行适当调整,不宜过大 |
|