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小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。