ClickHouse kafka表引擎使用故障问题 (一)

场景与问题：MRS ClickHouse客户，在执行滚动重启操作后，发现manager界面“集群队列大小”有大量业务拥塞，检查后台信息“Too many parts (303). Parts cleaning are processing significantly slower than inserts…”

客户数据表情况：

（1）客户报错信息设计数据表test.dwd_c_vehicle_upload_real_detail采用vin String 设置分区键，“PARTITION BY xxHash32(vin) % 100”

（2）kafka引擎数据表，参数仅配置了必须配置的参数

SETTINGS kafka_broker_list = ‘xx.xx.xx.xx:9092,xx.xx.xx.xx:9092,xx.xx.xx.xx:9092’,

kafka_topic_list = ‘pro_dwd_c_vehicle_upload_real_detail’,

kafka_group_name = ‘clickhouse_pro_new’,

kafka_format = ‘JSONEachRow’,

kafka_num_consumers = 1

（3）客户数据插入的频次不详，每次插入数据大致在几百条。

根据报错信息定位源码信息与相关参数信息：

（1）\ClickHouse_Kernel-master\src\Storages\MergeTree\MergeTreeData.cpp

size_t parts_count_in_partition = getMaxPartsCountForPartition(); ……. if (parts_count_in_partition >= settings->parts_to_throw_insert) { ProfileEvents::increment(ProfileEvents::RejectedInserts); throw Exception( ErrorCodes::TOO_MANY_PARTS, "Too many parts ({}). Parts cleaning are processing significantly slower than inserts", parts_count_in_partition); }

查阅官方文档parts_to_throw_insert默认值为300；

（2）根据kafka表引擎，其他参数分析，影响kafka数据表性能的重要参数：'kafka_max_block_size’默认值为65536即64K。

结合以上信息得出结论：由于客户数据表采用hash值作为分区键，数据表分区相对较多，再由于客户kafka表引擎参数“kafka_max_block_size”采用默认值65536，导致数据块较小，进而也就导致了数据插入时数据块较多，相应的分区part数量很容易超过“parts_to_throw_insert”默认值300，进而触发异常报错。

给客户建议：建议客户根据数据表情况、数据插入频次和每次插入数据的条数，对kafka表引擎数据表进行合理化配置，也可对clickhouse相应配置进行更改。例如：可以修改parts_to_throw_insert的默认值，可以增加“kafka_max_block_size”默认值，社区建议将“kafka_max_block_size”设置应增加为521K-1M，实现单表的最佳性能。

参考链接：

https://github.com/ClickHouse/ClickHouse/issues/3174

https://github.com/ClickHouse/ClickHouse/issues/9053

https://altinity.com/blog/clickhouse-kafka-engine-faq

ClickHouse Kafka

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。