日志一条一条写入 ClickHouse 导致性能很差，你会怎么设计批量写入链路？
我的判断
ClickHouse 要批量写，单条写会制造大量小 Part 和合并压力；入口应聚合、限时刷新并支持背压与重放。
我会让日志先进入 Kafka，消费端按目标表和分区聚合，达到例如 5 万行、几 MB 或 1 秒任一条件就提交一批。这样既控制端到端延迟，又避免单条 INSERT 每次创建 Part。
写入链路需要这几个能力：
- 批次行数和字节双阈值，防止一条超大日志撑爆内存；
- ClickHouse 变慢时暂停消费或降速，不能无限堆在进程内；
- 批次失败可重试，消费位点在写入确认后提交；
- 通过 eventId 或表引擎策略处理重试重复。
会监控每秒 INSERT 次数、平均批次、active/inactive parts、merge 队列、Kafka lag 和可查询延迟。批次也不是越大越好，过大会增加单次失败重试和内存峰值。
async_insert可以改善小写入，但上游仍应有批量与背压设计，不能用一个参数掩盖失控的写入模型。