AI Labs 都在用，ClickHouse 能成为 AI 日志的实时分析引擎吗？
拾象对 ClickHouse 的初步研究，核心问题：一个 2009 年为俄罗斯搜索引擎 Yandex 写的列式数据库，为什么在 2025-2026 年突然爆发？
核心数据
ClickHouse Cloud ARR 在 18 个月内完成 10 倍增长：从 2024 年中的约 $15M 增长到 2025 年底的约 $160M，同比增速 250%。付费云客户从 1,000 涨到 3,000+。2026 年 1 月 D 轮融资 $4 亿，估值 $150 亿（对应 94x ARR——极贵）。
为什么 ClickHouse 适合 AI
这不是”蹭 AI 概念”，而是架构层面的天然契合。
ClickHouse 最擅长的数据类型叫 append-only 事件流——数据只追加不修改、写入后立刻可查、需要对几十个字段做高速聚合统计。LLM 推理日志恰好就是这种数据：每次 API 调用会产生 token 消耗量、延迟、模型版本、GPU 编号、安全过滤结果等几十个字段的日志。
Anthropic 的真实案例：Claude 3.5 发布期间，每天 PB 级日志把原有的 APM（Application Performance Monitoring，应用性能监控）系统搞崩了，被迫迁移到 ClickHouse。最终只用 3 人团队就管住了整个可观测性基础设施。双方合作搭建了一套 air-gapped 部署方案（物理隔离，数据完全在 Anthropic 自己的机房里运行，不经过 ClickHouse 的云）。
OpenAI 也在用 ClickHouse，但用法不同——自己运维几十个分片的集群，做内部的可观测性方案，大概率不是 ClickHouse Cloud 的付费客户。
ClickHouse 的技术核心：为什么快
三个关键设计决策让 ClickHouse 在”大规模、只追加、实时聚合查询”这个场景里几乎无敌：
1. 列式存储（Column-oriented Storage）
传统数据库（MySQL、PostgreSQL）按行存数据——一行用户的所有字段挨着放。想查”一亿用户的平均消费金额”，必须把每一行的所有字段都读出来，实际上只需要”消费金额”这一列。如果表有 100 列，你读了 100 倍于需要的数据。
ClickHouse 按列存——同一列数据紧挨着放。查询只涉及 3 列，就只读 3% 的数据。同一列的数据类型相同、相邻值往往相似，压缩效果极好。典型压缩率 10:1 到 20:1（对比 Elasticsearch 的 1.5:1），1TB 原始数据压缩后可能只占 50-100GB。
2. 向量化执行（Vectorized Execution）
大多数数据库一行一行处理数据。ClickHouse 把数据分成块（通常 8,192 行一块），对整块同时执行操作，利用现代 CPU 的 SIMD 指令集（Single Instruction Multiple Data，一条指令同时处理多个数据）。列式存储 + 向量化执行两个一起做的开源数据库在当时很少，ClickHouse 是先行者。
3. MergeTree 引擎
核心哲学：数据写完就不改了，只管不断追加新数据。每次写入生成一个”小片段”快速落盘，后台线程异步合并。写入效率极高，但代价是删改操作很麻烦。
实际效果：专家实测比 Snowflake 快 5-13 倍，比 Elasticsearch 快 5-19 倍，成本低一个数量级。Nike 用 ClickHouse 替代 Splunk 做基础设施监控，年费从数千万美元变成便宜 5 倍以上。
三笔收购构建数据平台
过去一年 ClickHouse 从单一的 OLAP（Online Analytical Processing，在线分析处理）引擎扩成了数据平台，靠三笔收购：
收购 1：HyperDX → ClickStack（可观测性平台）
ClickStack 是开源的统一可观测性平台，由三个组件组成：OpenTelemetry Collector（数据采集器）+ ClickHouse（存储引擎）+ HyperDX UI（前端界面）。直接对标 Datadog / Splunk / Elastic 所在的 $200 亿 TAM 市场。
核心优势是 cross-signal correlation（跨信号关联）：传统工具里日志、追踪、指标存在不同的后端系统（Grafana 的 Loki/Tempo/Mimir 各自独立），排查问题要在三个系统间手动拼时间戳。ClickStack 所有数据共用 ClickHouse 存储，点击一条错误日志 → 一键跳转完整追踪链路 → 一键看指标面板，从”发现异常”到”定位根因”缩短一个数量级。
成本对比：同等监控负载下，ClickStack 约为 Datadog 的 30-50%、Splunk 的 15-20%。关键原因是列式压缩率 90%，数据存储成本碾压 Elasticsearch 的倒排索引存储。
短板：集成数量远落后 Datadog，缺 APM（Application Performance Management），RBAC（基于角色的访问控制）和审计日志不完善，还在 Beta。
收购 2：Langfuse（AI 可观测性）
2026 年 1 月与 D 轮同步收购。Langfuse 是开源 LLM 工程平台，MIT 许可证。收购前的数据：2,000+ 付费客户、19 家 Fortune 50 客户、20,000+ GitHub Stars、2,600 万+ SDK 月安装量。它原本就建在 ClickHouse 存储之上——收购逻辑非常顺滑。
Langfuse 做 6 件事：LLM 调用链追踪（tracing）、成本追踪（cost tracking）、prompt 版本管理、LLM Playground（在线测试 prompt）、测试数据集管理、评估（Eval，支持人工打分 + LLM-as-judge + 自定义函数 + 外部评估器四种方式组合）。
Eval 能力是 Langfuse 相对竞品的核心差异化，也是作者认为这笔收购漂亮的原因——不仅拿到了 $20 亿 TAM 的 AI 可观测性赛道领导者，还拿到了 LLM 应用全生命周期的工具链。
收购 3：PeerDB → ClickPipes（ETL 引擎）
全托管的数据摄入引擎，把外部数据持续导入 ClickHouse。覆盖 S3、Kafka、Postgres CDC（Change Data Capture，变更数据捕获——Postgres 里的数据一改就自动同步到 ClickHouse）等。
此外还推出了 Postgres Service（与 Ubicloud 合作），让客户在同一个控制台同时有 OLTP（PostgreSQL，事务处理）和 OLAP（ClickHouse，分析处理）。配了两个关键集成：pg_clickhouse 扩展（在 Postgres 里直接写 SQL 查 ClickHouse，性能提升 60 倍）和内置 CDC 实时复制（秒级延迟，不用自己搭 Debezium / Kafka Connect 这种管道）。
Agent-Facing Analytics
ClickHouse 从 2025 年下半年开始提出 Agent-Facing Analytics 概念——让 AI agent 代替人类分析师写 SQL 查数据。
基于三笔收购构建了完整的开源 Agentic Data Stack：Agent 通过 MCP（Model Context Protocol）检查 Schema，借助 Business Glossary（业务词典）理解语义，生成并执行 SQL，用自然语言返回结果。
ClickHouse 自己内部 dogfooding 了这套系统，叫 DWAINE（Data Warehouse AI Natural Expert）：服务 250+ 内部用户，日均处理 200+ 条数据查询，接管了约 70% 的数据仓库查询请求，分析师工作量减少 50-70%。
作者对此的态度有保留：这和 Snowflake 等公司在做的 AI 转型没有本质区别，ClickHouse 本身不做 AI，只是存储和查询 AI 产生的数据。
GTM 与定价
从纯 PLG 转向 PLG + SLG：2025 年之前完全没有 SDR（Sales Development Representative，销售开发代表），100% 靠开源用户自然转化。2025 年 7 月聘用前 Atlassian CSO Kevin Egan 担任 CRO（Chief Revenue Officer），开始搭企业级销售团队。
历史参照：MongoDB 在 $1 亿 ARR 引入 CRO 后 6-7 年收入增长 19 倍，Datadog 在 $3 亿 ARR 建销售团队后 5 年增长 8 倍。
按实际消耗收费（Usage-based），三个维度：
- 计算（占收入 65-75%）：按”计算单元 × 使用时长”分钟级计费。单价约 $0.69/单元·小时，同等算力下 Snowflake 收 $6.00——便宜 88%
- 存储（15-20%）：$47/TB/月，表面比 Snowflake 贵 2 倍，但 ClickHouse 压缩率 90-98%（Snowflake 50-75%），按原始数据量折算实际更便宜
- 数据传输 Egress（5-8%）：$115/TiB。2025 年 1 月之前免费，此后新增收费——明确的锁定机制
2025 年 1 月做了约 30% 综合提价并新增 Egress 收费，处于第一波提价周期。
企业端反馈（15 位专家访谈）
一致认可的：实时 OLAP 性能碾压级领先（共识度最高，均值 +1.7），单毫秒级扫描数十亿行。Deutsche Bank 从 kdb 迁移后年费从 $300 万降至 $20 万。
一致担忧的：
- 平台完整性缺失是估值天花板的决定性因素——无 AI/ML、ETL 刚起步、生态薄。Cisco VP 估算如果保持专用工具定位，TAM 上限可能仅为数据分析支出的 3-5%
- 企业就绪度是 Cloud ARR 增长最大瓶颈——Walmart 明确表示 Cloud 版无法通过敏感数据安全审批（SSP）；客户支持人员流失严重；RBAC/IAM/审计需客户自建
- 护城河正在被侵蚀——Goldsky CTO 警告核心优势正被 SingleStore、StarTree 快速复制，产品日趋可互换。最值得警惕的信号：即便最满意的客户也在密切关注竞品定价变化
- 开发者体验两极化——深度工程师视为”乐园”，企业非技术用户认为门槛过高。bottoms-up 增长模式天然排斥 CIO 级别的自上而下采购
- Yandex 背景——部分决策者因 ClickHouse 和俄罗斯的关系在国家安全层面对使用官方托管产品有疑虑
团队
- Aaron Katz（CEO）——联合创始人，前 Elastic 和 Salesforce 高管。Elastic 的经历可能是 ClickStack 战略的底层逻辑：用成本低一个数量级的列式引擎复制 Elastic 从搜索引擎到可观测性平台的路径
- Alexey Milovidov（CTO/创始人）——2009 年在 Yandex 开始写 ClickHouse，全球列式数据库领域最顶尖的工程师之一，至今仍是 GitHub 最活跃的核心贡献者。技术创始人留任且高强度贡献是极强正信号
- Kevin Egan（CRO，2025.7 加入）——前 Atlassian CSO / Slack VP Sales / Dropbox / Salesforce。每段履历都是 PLG 到 Enterprise 转型的教科书案例
估值与投资逻辑
$150 亿估值对应 94x ARR，极贵。作者给了一张增长预测表：如果 ClickHouse 能在今年赶上 Grafana 的 2025 年 ARR（$4 亿），并保持高增速，到 2028 年这个估值可以回归到 11x。
对比：Grafana 25 年 $4 亿 ARR / $90 亿估值 = 22.5x；Databricks $54 亿 ARR / $1340 亿估值 = 24x；二级市场 Snowflake / Datadog 在 8-15x。
作者的核心判断：ClickHouse 是 Snowflake 和 Databricks 向实时 OLAP 拓展的最大障碍，也是 Datadog/Splunk/Elastic 的新威胁。但完全开源 + Yandex 背景限制了商业化进展，三个市场的绝对份额都不高。
术语表
| 术语 | 解释 |
|---|---|
| OLAP | Online Analytical Processing，在线分析处理——面向分析查询的数据库（“过去一个月各城市的销售额是多少”） |
| OLTP | Online Transaction Processing，在线事务处理——面向日常操作的数据库（“这笔订单扣多少库存”） |
| 列式存储 | 按列而非按行存数据，分析查询时只读需要的列，省 IO |
| MergeTree | ClickHouse 的核心存储引擎，数据写入后生成小片段快速落盘、后台异步合并 |
| SIMD | Single Instruction Multiple Data，一条 CPU 指令同时处理多个数据 |
| append-only | 只追加不修改——日志类数据的天然特征 |
| APM | Application Performance Monitoring，应用性能监控 |
| CDC | Change Data Capture，变更数据捕获——数据一改就自动同步到下游 |
| Egress | 数据传出费用——云厂商的锁定机制 |
| air-gapped | 物理隔离部署，数据不出客户机房 |
| BYOC | Bring Your Own Cloud，在客户自己的云账户里运行服务商的软件 |
| PLG | Product-Led Growth，产品驱动增长——用户自己注册试用付费 |
| SLG | Sales-Led Growth，销售驱动增长——有销售团队主动跟进 |
| SDR | Sales Development Representative，销售开发代表——负责找潜在客户 |
| ARR | Annual Recurring Revenue，年经常性收入 |
| TAM | Total Addressable Market，总可触达市场 |
| RBAC | Role-Based Access Control，基于角色的访问控制 |
| cross-signal correlation | 跨信号关联——日志、追踪、指标三种数据互相关联，一键跳转 |
| OpenTelemetry | 开源的可观测性数据采集标准（不绑定任何后端） |
| Agentic Data Stack | ClickHouse 提出的概念：让 AI agent 通过 MCP 连接数据库、自主查询数据 |
Discussion 补充（2026-05-14）
vs Supabase：同一条路，不同位置
两篇都是拾象 Patrick 写的，结构和视角一致，放一起看很有意思。
共同叙事：从单一开源引擎，通过收购快速叠加能力层做平台化。Supabase 4 笔收购向下挖（改 Postgres 内核），ClickHouse 3 笔收购向上堆（引擎之上加应用层）。两家都在押注 Agent-Facing 产品，都估值极贵（Supabase 140x ARR，ClickHouse 94x ARR）。
互补而非竞争：Supabase = 事务层（OLTP，写进去、改一下、查一条），ClickHouse = 分析层（OLAP，只追加、不修改、扫十亿行聚合）。两家在数据链路的不同位置。但两边都在往对方地盘伸手——Supabase 收购 Hydra 做 pg_duckdb 跑列式分析，ClickHouse 推出 Postgres Service 补 OLTP。短期不构成威胁。
增长引擎差异：Supabase 靠”被选中”（agent 训练数据偏好 → 默认推荐 → 零获客成本），ClickHouse 靠”被需要”（PB 级日志搞崩了别人的系统 / 同等算力便宜 88%）。前者强但脆（依赖训练数据），后者慢但硬。
风险结构差异：Supabase 最大风险是分发优势消失，ClickHouse 最大风险是平台化失败 + Yandex 背景的安全审批问题。
在 agent 生态中的位置：这两家是”后端脊梁”层（agent 干活需要的数据库和日志监控），与我们 mapping 的 Slock/Multica/Consen 等”前端协作”层（人和 agent 怎么一起工作）是不同层级。infra 越成熟，协作层能做的事越多。