2026 年 6 月 15 日,ClickHouse 迎来了作为开源项目的第十个年头。创始人 Alexey Milovidov 在官方博客上发布了一篇十年回顾,从 2009 年一个替换慢速 libc 时间函数的 commit 讲起,到如今 48000 个 GitHub star、2600 多位贡献者和 2.5 亿美元年化营收,这个"完全从零构建"的列式分析数据库走过了一条在开源世界极为罕见的路径。
它既不是任何现有数据库的分叉——不像 MySQL 派生出的 MariaDB,也不像 Redis 派生出的 Valkey——也不依赖任何外部数据库内核,每一行代码都是从标准 C++ 库起步。如果你读完 Milovidov 的全文,会发现这不仅仅是一个技术产品的成长史,更是一个工程师对"极致开放"理念长达十年的固执实践。

ClickHouse 的起源故事可以追溯到 2008 年,远早于"大数据"成为行业热词。当时在俄罗斯搜索引擎公司 Yandex 工作的 Milovidov 面临一个棘手的现实问题:公司的网络分析系统——功能类似于 Google Analytics,但规模更大——基于 MySQL 构建,而行的关系型数据库在处理海量非聚合数据的实时分析查询时表现捉襟见肘。典型的查询场景是这样的:用户需要从数百亿条原始日志记录中,按任意维度组合(城市、浏览器版本、操作系统、来源渠道)进行过滤和聚合,且必须在几秒内返回结果。MySQL 的索引和查询优化器在设计上从未为这种工作负载做过优化。
团队尝试了两个原型方案:OLAPServer 采用列式存储,以日为批次进行更新,但数据类型只支持整数,限制了其适用范围;Metrage 则是行式存储,通过自定义的 CRDT(无冲突复制数据类型)数据结构实现实时更新。将列式存储的压缩率和扫描性能优势,与 MergeTree 引擎的增量排序和实时写入能力结合起来,最终催生了 ClickHouse 的核心架构。
2009 年 5 月 29 日,整个项目有了第一个正式的代码提交——一个将慢速 libc 时间函数替换为自定义高性能实现的性能补丁。在 Milovidov 看来,数据库性能优化的第一原则就是永远不要相信标准库的时间函数足够快。

随后三年(2009-2012)的开发顺序展示了一种近乎教科书级的数据库构建方法论,这种自底向上的工程策略贯穿了 ClickHouse 至今的设计哲学:先实现内存列(IColumn 和 Field 类——这些抽象早于 Apache Arrow、ORC 和 Parquet 等后来成为行业标准的列式格式),再依次实现聚合函数、表引擎(第一个引擎类似于今天的 TinyLog,只支持追加写入和全表扫描)、数据压缩(用 LZ4 替代了早期实验中选用的 QuickLZ,因为前者在解压速度上优势明显),然后是 Block streams 数据处理管道(后来演变为更灵活的 Processors 框架)、SQL 解析器(第一次尝试使用 Boost.Spirit 库失败后,自行实现了递归下降解析器)、关系运算符(第一个实现的 SQL 运算符是 LIMIT——一个工程师的务实选择,因为有了它才能控制结果集大小),以及读写缓冲区抽象(替代了缓慢的 C++ iostreams,自实现了内存映射文件和异步 IO),直到 2012 年 3 月,第一个可用的 Server 和 Client 程序才诞生。
同年,MergeTree 家族表引擎问世——这个通过后台增量归并排序来维护数据局部性、从而实现对大规模范围扫描查询进行快速剪枝的技术,成为了 ClickHouse 至今最核心的差异化能力。随后,由团队第二位成员 Michael Kolupaev 开发的 ReplicatedMergeTree 引擎,利用 Apache ZooKeeper 实现了跨多个数据中心的强一致性复制,使得 ClickHouse 具备了生产级的高可用能力。
到 2014 年,ClickHouse 已在 Yandex 内部全面支撑面向终端用户的实时分析查询,日摄入数据量达数千亿条记录,跨多个数据中心部署运行。欧洲核子研究组织(CERN)也将其用于大型强子对撞机底夸克实验的数据分析——这是 ClickHouse 在 2016 年开源之前唯一的外部用户。
2016 年 6 月 15 日,经过 Yandex 管理层的正式审批,ClickHouse 以 Apache 2.0 许可证在 GitHub 上公开发布,配备了完整的 logo、官方网站、技术博客和 Debian 软件仓库。Milovidov 在回顾文章中透露了一个细节:他之所以推动开源,是因为注意到市场上不断有其他公司为了解决类似的实时分析需求而"重复造轮子"——既然没有现成的数据库能满足这个需求,不如把自己已经在生产环境验证过的方案公开。"最坏的情况是什么都不会发生,但有机会的话,它可能会影响一代工程师。"他说。
在回顾文章中,Milovidov 提出了一个值得整个开源社区思考的"开源四层次"框架。第零层,代码公开但实质上静止——就像 id Software 在游戏过时后将 Doom 或 Quake 的源代码以存档形式发布,有历史价值但无社区价值。第一层,有活跃的公开提交记录,但原则上不接受外部贡献——他举了 SQLite(因其独特的"公共领域"许可和单人维护模式)和 Ladybird 浏览器(因开发节奏极快而不接受外部 PR)为例。第二层,接受外部贡献,但开发决策和路线图规划仍然在内部封闭进行——这实际上描述了当今大多数"开放核心"商业模式下的开源项目。第三层,则是一切相关活动全部在公共领域透明进行:任务跟踪、代码审查、路线图讨论、持续集成流水线、发布周期、文档维护——全部对社区可见。"我的野心很简单,始终瞄准最高标准,"Milovidov 写道。他进一步说明,他希望 ClickHouse 同时在三个维度上成为行业典范:第一,如何从工程角度构建一个优秀的数据库系统;第二,如何实践现代 C++ 开发——项目已经使用 C++23 标准,并在开发流程中深度整合了 AI 辅助编程工具;第三,如何成为数据结构创新和性能优化的开放实验沙盒。一个极为动人的细节是,ClickHouse 不仅在每次发布时在更新日志中逐一列名感谢所有贡献者,甚至在其数据库内部专门维护了一张名为 system.contributors 的系统表,以结构化数据的形式永久记录每一个为这个项目写过程序的人。他写道:"简单来说,我们爱我们的贡献者。如果有贡献者提交了一个只完成了一半的功能实现,我们的团队会接手帮助完成它,并在最终合并时保留原始作者的全部署名。"
进入 AI 和大模型时代,ClickHouse 意外地找到了一条与其技术架构天然契合的增长曲线。大语言模型的推理和训练会产生海量的结构化日志——每一次 API 调用的请求参数、每一个 token 生成的延迟数据、每一次模型版本切换的效果差异——这些数据具有极其典型的"追加写入、列式分析"特征:写入量大且永不修改,查询时通常只需要少数几个列进行聚合和过滤。这与 ClickHouse 的 MergeTree 引擎设计几乎完美对应。
据公开信息,Anthropic 每天通过 ClickHouse 处理 PB 级别的推理和训练日志,OpenAI 和 Cursor 等 AI 行业的标志性公司也是其客户——而传统的可观测性方案如 Datadog 或 Splunk,在同等规模下的成本通常是 ClickHouse 的五到十倍。
在 2026 年 5 月于旧金山举办的 Open House 用户大会上,ClickHouse 发布了面向 AI 时代的一系列产品:ClickHouse Agents——基于 Anthropic Claude 的全托管智能分析服务,用户可以用自然语言提问,系统自动生成和优化查询计划,支持多 Agent 协作工作流和沙箱代码解释器;原生 MCP Server——支持 Model Context Protocol 协议,使外部 AI Agent 能够安全、高效地直连 ClickHouse 数据进行查询和分析;AI Notebooks——持久化的交互式分析工作区,旨在成为数据分析师的"第二大脑";以及 ClickStack——整合日志、链路追踪、指标和会话回放的完整可观测性平台。公司还宣布了全托管 Postgres 服务的公开测试版,意味着 ClickHouse 开始从 OLAP 向 OLTP 方向拓展,并推出了完全开源的成本性能基准测试工具 CostBench,试图为整个分析数据库行业建立透明、可复现的性能评估标准。
在商业层面,ClickHouse 的增长曲线同样陡峭。2026 年 1 月,公司完成了 4 亿美元的 D 轮融资,估值约 150 亿美元,年化营收突破 2.5 亿美元且同比增长超过三倍。仅在 2026 年第一季度就新增了超过 1000 家客户。过去一年内,公司完成了两笔战略性收购:HyperDX 构成了 ClickStack 可观测性平台的技术基础,而 Langfuse——开源的大语言模型可观测性和追踪平台——则被整合为 AI 工作负载的分析入口。
与此同时,ClickHouse 在全球六大洲建立了超过 60 家"House Mates"合作伙伴网络,包括 Fivetran(支持 500 多种数据源的即开即用连接器)、dbt Labs(首个社区 Fusion 引擎适配器)、Sigma Computing 和 Notion 等。从一个 Yandex 莫斯科办公室里的 C++ 项目,到支撑 Anthropic 每天处理 PB 级 AI 日志的商业数据库,ClickHouse 用十年时间验证了 Milovidov 在文章末尾写下的一条看似反直觉的原则:"删除不必要的代码比添加新代码更重要。"对于一个开源项目的长期演化而言,这或许是最被低估的生存法则。
参考来源: