1、写入瓶颈分析：深入理解ClickHouse写入链路，从客户端到MergeTree的完整流程，识别常见性能瓶颈
大家好，我是你们的ClickHouse讲师。今天咱们来聊聊写入瓶颈。
说实话，很多刚接触ClickHouse的朋友，上来就写数据，然后发现——怎么这么慢？甚至比MySQL还慢？
嗯，这其实不怪ClickHouse。它设计出来就不是为了单条插入的。但如果你不理解它的写入链路，你根本不知道瓶颈在哪。
我个人习惯，遇到性能问题，先画链路图。把数据从客户端到落盘的每一步拆开，一个一个看。今天我就带你走一遍这个流程。
1.1 写入链路全景图
先看一张我手绘的流程图。别嫌丑，但逻辑很清楚。
这张图我画了好几次才满意。你看，从客户端到磁盘，中间要经过网络、解析、缓冲、排序、落盘。每一步都可能成为瓶颈。
1.2 第一步：客户端到服务端——网络传输
很多人忽略这一步。你想想看，如果你的客户端在北京，服务器在杭州，每次写入都要走公网。延迟能不高吗？
我在项目中遇到过，有个团队用Python脚本一条一条INSERT，每次网络往返就要20ms。插入100万条数据，光网络开销就5个多小时。这谁受得了？
核心结论：网络延迟是写入的第一个瓶颈。解决方案就是批量写入，一次发送几千到几万行。
1.3 第二步：SQL解析与权限校验
服务端收到请求后，先做SQL解析。说白了，就是把你的INSERT语句拆开，看看表名对不对、字段类型匹配不匹配。
这一步本身很快，微秒级。但如果你用了复杂的物化视图、或者表结构特别复杂（比如几百个字段），解析时间会明显增加。
小技巧：我建议生产环境不要用太复杂的INSERT语句。尽量用标准的INSERT INTO table VALUES (...)，少用子查询或复杂的表达式。
1.4 第三步：内存缓冲区——Block与Partition
这是写入链路中最关键的一环。ClickHouse不会每来一条数据就写磁盘。它会先把数据攒在内存里，攒够一个Block（默认约100万行），再统一处理。
但这里有个坑——分区。如果你的表按天分区，但写入的数据跨了多个分区，ClickHouse会在内存里为每个分区维护一个独立的Block。
我曾经遇到一个案例：某公司按小时分区，但写入的数据时间戳非常分散。结果内存里同时维护了上百个Block，每个Block都没攒满，导致频繁刷盘。写入性能直接崩了。
| 场景 | 内存行为 | 写入性能 |
|---|---|---|
| 数据集中在1-2个分区 | Block快速攒满 | 高 |
| 数据分散在10+个分区 | 每个Block都攒不满 | 低（频繁刷盘） |
避坑指南：我曾经因为分区键设计不合理，导致写入性能下降10倍。后来把分区粒度从「小时」改成「天」，问题就解决了。记住：分区不是越细越好。
1.5 第四步：排序与合并
Block攒满后，ClickHouse会按照表的ORDER BY定义对数据进行排序。这一步是CPU密集型的。
为什么一定要排序？因为MergeTree的存储结构要求每个Data Part内部是有序的。排序后，查询时才能用二分查找快速定位数据。
嗯，这里要注意：如果你的ORDER BY字段很多（比如5个以上），排序开销会显著增加。我建议ORDER BY字段控制在3个以内，除非你有特殊需求。
1.6 第五步：生成Data Part并落盘
排序完成后，ClickHouse会把数据写入磁盘，生成一个不可变的Data Part。每个Part包含主键索引、列存文件、标记文件等。
这一步的瓶颈主要在磁盘IO。如果是机械硬盘，写入速度可能只有100MB/s。如果是NVMe SSD，可以到3GB/s以上。
另外，Part的数量也很关键。如果写入频率太高，会产生大量小Part。后台的Merge线程需要不断合并这些小Part，消耗大量CPU和IO资源。
经验之谈：我建议控制Part数量在1000个以内。如果超过这个数，查询性能会明显下降。可以通过调整写入批次大小和后台合并策略来优化。
1.7 常见瓶颈总结
好了，链路走完了。我把常见的瓶颈点整理成一张表，方便你对照排查。
| 环节 | 常见瓶颈 | 排查方法 | 优化方向 |
|---|---|---|---|
| 网络传输 | 延迟高、带宽不足 | ping延迟、网卡监控 | 批量写入、内网部署 |
| SQL解析 | 复杂SQL、字段过多 | system.query_log | 简化INSERT语句 |
| 内存缓冲区 | 分区过多、Block攒不满 | system.parts | 优化分区键、增大batch |
| 排序合并 | ORDER BY字段过多 | top -H 看CPU | 精简排序字段 |
| 磁盘落盘 | IOPS不足、小Part过多 | iostat、Part数量监控 | SSD、控制写入频率 |
1.8 我的排查习惯
最后分享一个我自己的排查流程。遇到写入慢，我一般按这个顺序查：
- 先看Part数量：SELECT count() FROM system.parts WHERE active=1。如果超过1000，先处理小Part合并。
- 再看写入批次大小：检查客户端代码，是不是一条一条INSERT的？改成10000行一批。
- 然后看分区分布：用SELECT partition, count() FROM system.parts GROUP BY partition。如果分区太多，考虑调整分区键。
- 最后看磁盘IO：用iostat -x 1 看磁盘利用率。如果%util接近100%，说明磁盘是瓶颈。
说实话，大部分写入性能问题，都出在「批次太小」和「分区太碎」这两个点上。你只要把这两点控制好，写入性能基本不会差。
好了，这一章就到这里。记住：理解链路，才能定位瓶颈。下一章我们聊聊具体的批量写入策略和参数调优。
公众号:蓝海资料掘金营，微信deep3321