批量写入策略：为什么单条插入是性能杀手？详解批量写入的最佳实践
说实话，我刚接触ClickHouse那会儿，也踩过单条插入的坑。那时候觉得，MySQL里一条一条insert挺正常的啊，怎么到了ClickHouse这儿就不行了？后来在生产环境上亲眼看到，每秒几百条的单次插入，直接把MergeTree的写入吞吐打到地板砖上……嗯，从那以后，我再也不敢小看这个“小动作”了。
一、单条插入为什么是性能杀手？
你想想看，ClickHouse的底层存储是列式结构，每次插入都要经历这么几步：
- 解析SQL：哪怕你只插一条数据，SQL解析器也得跑一遍完整的语法分析
- 生成分区：每条数据都要判断属于哪个分区，如果分区不存在还得新建目录
- 写入内存缓冲区：数据先落到内存的MemTable里，满了才刷盘
- 后台合并：小文件多了，后台线程要不停地做merge操作
单条插入的问题在哪？说白了，就是把一次本该批量完成的工作，拆成了无数次微小的重复劳动。每次插入都要走一遍完整流程，但每次只处理一条数据。这就像你每次只寄一封信，却要跑一趟邮局——效率能高才怪。
核心结论：单条插入会导致大量的小文件产生，增加后台合并压力，严重时甚至引发写入背压（write backpressure），让整个集群的写入性能雪崩。
我记得有一次线上事故，业务方用脚本一条一条地往ClickHouse里灌日志数据，结果半小时后写入延迟从5ms飙升到3秒，后台的merge队列排了上千个任务。最后不得不临时停掉写入，手动触发optimize合并。那次之后，我就在团队里立了个规矩：任何写入操作，必须走批量接口。
二、批量写入的最佳实践
既然单条插入不行，那批量写入该怎么搞？我个人的经验是，抓住三个关键点：批次大小、频率控制、写入方式。
2.1 批次大小：到底一次插多少条合适？
这个问题没有标准答案，但有个经验范围。我一般建议：
- 单批次行数：1000 ~ 100000 条之间
- 单批次数据量：控制在 1MB ~ 100MB 之间
为什么是这个范围？太小了，批量的优势没发挥出来；太大了，内存和网络开销会暴涨，反而容易OOM。
| 批次大小（行数） | 写入延迟 | CPU消耗 | 内存消耗 | 推荐场景 |
|---|---|---|---|---|
| 1 ~ 100 | 高 | 高 | 低 | 不推荐 |
| 1000 ~ 10000 | 中 | 中 | 中 | 实时日志、监控数据 |
| 10000 ~ 100000 | 低 | 低 | 高 | 离线批量导入、ETL任务 |
我个人习惯是，对于实时性要求高的场景，批次大小设在5000~10000条；对于离线批量导入，直接拉到50000条以上。你可以在测试环境里压一下，找到自己业务的最佳平衡点。
2.2 频率控制：别让ClickHouse“喘不过气”
批次大小定好了，频率怎么控制？这里有个常见的误区：很多人以为批次越大越好，于是攒够10万条才刷一次。结果呢？数据延迟太高，业务方受不了。
我建议采用“双阈值”策略：
- 按条数触发：比如攒够5000条就写入一次
- 按时间触发：比如最多等5秒，不管攒了多少条，必须写入
这样既能保证吞吐，又能控制延迟。我曾经在某个物联网项目中，用这个策略把写入吞吐从每秒2000条提升到了每秒8万条，延迟还控制在3秒以内。
小技巧：如果业务允许，可以在写入前对数据做一次排序（按分区键排序），这样能减少分区文件的碎片化，进一步提升合并效率。
2.3 写入方式：用对工具事半功倍
ClickHouse提供了多种批量写入方式，我挑几个常用的说说：
- INSERT INTO ... VALUES (...), (...), (...)：最直接的方式，适合小批量（几千条以内）
- INSERT INTO ... FORMAT CSV/JSONEachRow：适合大批量，直接从文件或流中读取
- ClickHouse JDBC/HTTP 批量接口：程序接入时推荐，支持自动分批
举个例子，用HTTP接口批量写入CSV格式的数据：
echo -e "1\tclick\n2\thouse\n3\thousefly" | curl -X POST \
'http://localhost:8123/?query=INSERT+INTO+test.table+FORMAT+TabSeparated' \
--data-binary @-
这种方式比逐条INSERT快几十倍。我在项目中用Python写了个批量写入器，核心逻辑就是攒够5000条或者5秒，然后一次性通过HTTP接口发出去。
三、避坑指南
批量写入虽然好，但坑也不少。我把自己踩过的几个坑分享给你：
- 批次太大导致OOM：我曾经一次插了50万条，结果ClickHouse进程直接挂了。后来发现是内存不够，分批处理就没事了。
- 写入频率过高导致合并风暴：每秒刷一次批次，后台合并线程根本忙不过来。建议控制写入频率在每5~10秒一次。
- 忽略分区键设计：如果分区键选择不当，比如按秒分区，那每个批次都会生成一个新分区，小文件数量爆炸。建议按天或按小时分区。
特别注意：ClickHouse的写入是异步的，数据先写入内存，后台再异步刷盘。如果写入后立即查询，可能查不到最新数据。需要设置 insert_quorum 或等待几秒再查。
四、知识体系总览
下面这张图，帮你把批量写入的核心逻辑串起来：
从原始数据流开始，经过双阈值判断，决定是否触发批量写入，最终数据落到MergeTree的分区存储中。整个过程环环相扣，任何一个环节没做好，都可能成为性能瓶颈。
好了，关于批量写入的策略，我就讲这么多。记住一句话：别让ClickHouse干“碎活”，让它干“整活”。下一章我们聊聊分区键设计，那个坑比这个还深……嗯，到时候再细说。
一句话总结：单条插入是性能杀手，批量写入才是王道。控制好批次大小（5000~10000条）和写入频率（5~10秒），配合双阈值策略，就能让ClickHouse的写入性能发挥到极致。
公众号:蓝海资料掘金营，微信deep3321