核心内容摘要
宋雨琦“传闻”背后的流量密码：当红爱豆如何深陷舆论漩涡与自救？
本文字数4369估计阅读时间11 分钟作者Tom Schreiber为什么基准测试总是贯穿于我的工作年末将至我习惯回顾一些最令我自豪的工作成果。
2025年我创作并协助发布了大量与 ClickHouse 相关的内容但其中最让我在意的几篇文章都有一个共同点背后都基于一项基准测试。
基准测试之所以频繁出现在我的工作中是因为它能带来清晰的认知。
它能纠正我们对性能的直觉揭示各种取舍有时甚至会推翻一些已经存在太久的固有看法。
以下是我今年最喜欢的几个案例——它们让我感到惊讶改变了人们对 ClickHouse 的认知甚至直接影响了实际系统的构建方式。
把它们串联起来可以勾勒出一个完整的发展路径从数据布局与写入到存储与执行最终落脚到成本优化。
在重读这些内容时我不断意识到同一个事实性能归根结底取决于引擎在端到端传输数据时的效率。
十亿文档的 JSON 基准测试这项基准测试源于一个基础性的问题如果将 JSON 看作列式数据而不是传统的文档格式它将呈现出怎样的形态ClickHouse 在列式存储架构之上彻底重构了 JSON 的存储方式带来了远超以往的处理速度、压缩率和使用体验在现有所有 JSON 数据存储方案中遥遥领先。
为了验证性能我们设计了 JSONBench——一项可复现的基准测试它会将相同的真实数据集最多包含 10 亿条 Bluesky 事件加载到多个系统中然后对存储空间、冷热查询时延及数据质量成功导入的文档数量进行测量。
在初始的十亿文档测试中ClickHouse 的查询速度快了数个数量级同时在磁盘占用上也更具优势——相比将同一 JSON 存为压缩文件ClickHouse 所需空间还减少了 20%。
我们还构建了一个在线实时仪表板支持按数据集规模、冷热状态、存储方式和数据质量维度进行结果筛选还可以切换是否显示支持 JSON 扁平化处理的系统。
JSONBench 不止是一次性博客项目。
它已经在社区中被广泛使用并持续收到外部贡献者的拉取请求用于新增或更新不同系统的测试结果。
这是我今年最喜欢的基准测试之一因为它的结果超出了我的预期。
ClickHouse 相比传统的 JSON 数据存储系统例如 MongoDB性能提升达到成千上万倍同时使用的存储空间也明显更少。
这完全颠覆了我对 JSON 可执行分析查询的认知。
小插曲ClickHouse 在最初的 JSONBench 测试中就已展现出显著优势。
随后我们又独立优化了 JSON 的实现方式并引入了新的共享数据序列化机制使得复杂 JSON 场景下的性能和内存占用得到了大幅提升。
如今无论在冷热查询还是任意数据集规模下ClickHouse 都以更大的领先优势遥遥领先于其他系统。
输入格式基准测试这个基准测试源于一个看似简单却实际复杂的问题ClickHouse 支持 70 多种输入格式那在追求高吞吐导入时哪些格式才是真正关键的为了系统性地回答这个问题我们设计了 FastFormats 基准测试。
它专注于测量服务端导入的成本并在几十种格式、批处理大小、压缩方案和预排序策略下对时间、CPU 占用、内存使用和文件大小等指标进行详细对比。
最终结论非常清晰且出奇一致原生格式几乎在所有场景中都是最优解压缩几乎是“标配”LZ4 优先若带宽受限则用 ZSTD预排序确实有帮助但效果远没有人们想象中那么大批处理大小的影响甚至超过几乎所有其他因素。
就像 JSONBench 一样我们也构建了一个实时在线仪表板用户可以按格式、批量大小、压缩方式、是否预排序及不同性能指标灵活查看测试结果。
这是我今年最喜欢的基准之一因为它对 ClickHouse 以外的实际生产环境也产生了直接影响。
Netflix 就提到他们在数据导入方面的一个重大突破正是来源于这篇文章和 FastFormats 的测试结果。
他们发现 ClickHouse 原生协议在性能上始终优于 RowBinary 后便反向分析了 Go 客户端的实现逻辑并在 Java 管道中重写了采用 LZ4 压缩的原生协议编码。
最终取得了更低的 CPU 占用、更高的内存效率如今这个系统每天向 ClickHouse 写入约 5PB 的日志数据。
对象存储缓存基准测试这个基准测试起源于一个实际的云计算问题为什么一些分析系统在测试中吞吐量很高但实际使用时却仍感觉缓慢答案不是带宽而是延迟。
对象存储虽然具备可观的吞吐能力但每次读取通常需要几百毫秒的延迟对于许多分析类查询尤其是小型、选择性强、随机读取来说延迟才是决定性能的核心因素。
为此我们为 ClickHouse Cloud 构建并测试了一个分布式缓存系统——它是一个位于无状态计算节点与对象存储之间的共享、低延迟缓存层。
与其让每个节点各自建立本地缓存不如将热点表数据缓存一次让所有节点即时复用。
我们对比了以下三种方案使用相同的数据集与查询一台带本地 SSD 的自建服务器ClickHouse Cloud 使用传统的每节点文件系统缓存ClickHouse Cloud 启用新型分布式缓存。
结果显示在吞吐受限的扫描任务中冷查询性能最高可达本地 SSD 的 4 倍这得益于共享缓存和缓存节点之间的并行拉取在延迟敏感的分散读取场景中冷查询性能可媲美本地 SSD而热查询则稳定实现低于 60 毫秒的内存级访问速度——整个过程中完全不依赖本地磁盘。
核心观点是共享缓存结合弹性无状态计算架构即便是冷启动也优于依赖“高速磁盘”的传统方式。
这样不仅启动更快无需反复从对象存储下载还能灵活扩缩计算资源而不丢失任何热点数据。
这是我今年最欣赏的基准测试之一因为它展示了一种真正的架构范式转变。
云原生分析系统不再需要在弹性与性能之间权衡。
两者可以兼得。
UPDATE 基准测试过去很长时间ClickHouse 都被一句话所定义“适合做分析但不支持频繁快速的更新操作。
”这个基准测试终于打破了这种固有看法。
我们撰写了一篇博客文章基于同一数据集、相同硬件和相同查询对 ClickHouse 支持的所有 UPDATE 方式进行了对比测试——包括传统变更classic mutations、即时变更on-the-fly mutations、ReplacingMergeTree 插入方式以及通过 patch parts 实现的新一代轻量级标准 SQL UPDATE。
测试结果令人惊讶ClickHouse 的标准 SQL UPDATE 比传统变更最多快达 1000 倍原本需要几分钟的大批量更新如今只需毫秒级时间单行更新也能在几十毫秒内完成性能几乎与插入相当。
这是我今年最喜欢的基准测试之一因为它颠覆了人们对 ClickHouse 的传统认知。
你现在可以用标准 SQL 高频率地执行快速更新无需牺牲分析性能也不必依赖特定引擎的特殊方案。
分布式 GROUP BY 基准测试这个基准测试关注的是GROUP BY 作为分析查询的核心其执行模型到底能扩展到多大规模GROUP BY 是支撑几乎所有分析查询的基础可观测性仪表盘、实时对话型生成式 AI、AI 智能体可视化分析等场景都离不开它。
ClickHouse Cloud 利用并行副本架构可将单个 GROUP BY 查询扩展到所有计算节点的所有 CPU 核心上执行。
为评估其可扩展性我们在从数千万行到 1000 亿行、甚至 1 万亿行的数据集上运行相同的 GROUP BY 查询并逐步将 ClickHouse Cloud 中的计算节点规模从 1 台扩展至数百台。
结果令人震撼1000 亿行聚合仅耗时约
4 秒每秒处理数据量高达约 2400 亿行吞吐超过
4 TB/s无需预聚合无需重排数据。
这是我今年最欣赏的基准测试之一它展示了架构设计的极致扩展能力。
就像一款精致的钢笔或经典的 Unix 工具ClickHouse 聚焦一项核心功能——GROUP BY并将其做到极致。
从本地笔记本到云端大规模集群执行模型无需任何改动而这个基准测试展现了这种设计理念带来的实际影响。
你可以将这个决定分析速度的操作横向扩展到整个集群而无需更改任何查询逻辑或数据模型。
值得一提云数据仓库的成本-性能基准测试这个基准测试关注的不再是功能细节而是一个更核心的问题在云上性能如何转化为真实的使用成本它被列为“特别推荐”因为相比其他测试它的研究范围更广、挑战也更大。
测试的起点是一个朴素的观察标价往往并不能代表实际花费。
不同系统的计费模型各异计费单位与资源模型错位使得单纯对比价格表既困难又容易误导。
为了还原真实成本我们选取了五大主流云数据仓库在相同分析负载和不同规模下进行测试然后根据各自的计费方式将运行时长换算为实际成本。
这是我今年最喜欢的基准之一因为它重构了对话方式。
与其争论价格表和档位设置不如专注效率这个真正的“价值单位”。
当以系统实际计费方式来衡量成本时ClickHouse Cloud 总能实现单位成本下的最大性能回报。
一年来基准测试的启示回顾过去这些工作背后都体现了基准测试在打破假设中的关键作用。
它们推翻了固有观念“ClickHouse 不支持 UPDATE”揭示了关键取舍延迟 vs 吞吐、速度 vs 成本验证了架构选择的有效性列式 JSON、无状态云计算。
在一些案例中基准测试甚至影响了真实系统的构建方式而不仅仅停留在博客层面。
这一年所有测试都指向同一个核心结论性能取决于引擎在端到端过程中传输和处理数据的效率。
总结下来我们反复看到没有批量处理数据格式再先进也徒劳延迟没控好带宽再高也无济于事计算节点是弹性的缓存不能是孤立的更新操作能避免大规模重写时存储结构就不是瓶颈执行模型不具备扩展性节点数量再多也无法提升性能价格表再诱人如果执行效率不高也无法节省成本。
这就是为什么基准测试始终贯穿我的工作它让所有这些端到端的性能权衡变得透明可见。
2026年我们会发布新的功能、新的架构、提出新的性能主张。
而我们的方法仍然不变先测量公布结果用真实数据推动讨论。
征稿启示面向社区长期正文文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。
建议行文风格干货输出图文并茂。
质量合格的文章将会发布在本公众号优秀者也有机会推荐到 ClickHouse 官网。
请将文章稿件的 WORD 版本发邮件至Tracy.Wangclickhouse.com