从一到无穷大 #86：ClickHouse 收购 RunReveal——可观测性竞争进入宏观调控阶段

2026 年 8 月 27 日，ClickHouse 发了一篇很长的文章，回应外界关于 ClickHouse 是否正在赢得可观测性战争的讨论。它给出的结论是：ClickHouse 在不少可观测产品中已经成为事实上的存储与查询引擎，这只是整个可观测产品的一层。采集、Schema、关联、可视化、告警和调查工作流仍然要另外构建。 $1$

9 月 1 日，只过了五天，ClickHouse 收购 RunReveal。RunReveal 是一家完全构建在 ClickHouse 上的安全数据平台，提供安全日志采集、检测、调查与响应。ClickHouse 在收购公告里写得很直接：它希望把 RunReveal 的安全知识带回公司，改进安全数据的参考架构、Schema、保留策略与数据库 Roadmap；RunReveal 已经完成的 Agentic Investigation 也会进入 ClickHouse 的 Agentic Analytics 方向。 $2$

这个时间差很有意思。前一篇文章说明数据库能赢到哪一层，后一笔收购开始处理它赢不了的那几层。

图 1：ClickHouse 2026 年公开的 Compute & Storage 演进图。开源版默认让存储与计算留在同一批机器上；ClickHouse Cloud 的一个 Warehouse 可以创建多个隔离的计算 Service，并共享对象存储。原图来自 ClickHouse。 $3$

这张图就是本文的起点。当一家数据库厂商已经把列存、向量化执行、对象存储和多个隔离计算 Service 串成一个可交付的云服务，继续优化引擎当然有价值，但市场很难再因为某一个算子快 20% 就重新分配。用户买的是能处理自己 workload 的完整产品，而完整产品已经超出这张架构图的边界。

1. RunReveal 交易与 Security workload

1.1 安全数据底座与安全产品的边界

安全数据对 ClickHouse 很友好。Cloud Audit Log、Identity Event、Endpoint Telemetry 与 Network Flow 都是持续追加、字段宽、量大、高基数的事件；查询一方面需要按时间、账号、IP 和资源做精确过滤，另一方面会在数月乃至数年的保留周期上做聚合与回溯。这些条件会放大列存压缩、数据裁剪、并行执行和对象存储的优势。

数据进了 ClickHouse，SIEM 还没建成。实际产品还要处理数据源认证、断点续传、格式标准化、字段富化、Sigma 与 SQL 检测、规则版本、误报、调查证据链、Slack/PagerDuty/Jira 通知，以及谁有权查看哪一类日志。RunReveal 的公开文档列出了 100 多种数据源、Pipeline、Detection as Code、AI Chat、MCP Server 与自动调查 Agent。 $4$ 这些东西很少以一个大功能存在，更多是数百个场景细节。

RunReveal 这笔收购的核心是一组已经跑通的 Security workload：什么数据会进来，怎样建表，什么字段值得做排序键与索引，检测查询会如何打爆资源，安全分析师怎样从一个 Signal 追到结论。这组知识能回到 Schema、Materialized View、索引、资源隔离和 Agent Tool 的 Roadmap。

1.2 Bring Your Own Database 与已成立的分发路径

RunReveal 与 ClickHouse 的关系在收购前已经非常深。2023 年，RunReveal 就支持 Bring Your Own Database：客户提供自己控制的 ClickHouse Cluster，RunReveal 自动下发表结构，其余采集、检测和调查功能透明使用这个集群。这条路径需要解决小批次写入、客户集群故障、Schema Migration 与权限等很具体的问题。 $5$

从 ClickHouse 视角看，这是一条现成的 workload 分发链。新的 RunReveal 客户选择 BYOD，底层就会增加一个 ClickHouse Deployment；用户继续增加数据源、保留期与检测规则，会直接增加 ClickHouse 的存储、写入和查询消耗。数据库在这里不再等待用户独立做技术选型，它已经被写进上层产品的默认路径。

2. 可观测存储原语的收敛与剩余差异

2.1 列存、对象存储与存算分离

ClickHouse 变成很多可观测产品的默认底座，首先是技术结果。宽事件通常包含几十到几百个字段，一次分析只读取时间、分组维度与少数测量值。列存、压缩、向量化执行和数据跳过刚好命中这类访问模式。2026 年 3 月，ClickHouse 26.2 将全文搜索的 text index 推到 Production Ready（每个 data part 里是 512-Token Front-Coded Dictionary Block、常驻内存的 Sparse Block Index 与 Adaptive Posting List，后者按基数选择 Embedded Row ID、VarInt 或 Roaring Bitmap）。它补的是 ClickHouse 与日志搜索引擎之间一块很具体的能力差。 $1$ $6$

图 2：图 1 高层抽象下的详细架构。表数据位于共享对象存储，热数据进入分布式缓存，数据库与表定义由 Keeper 上的 Shared Catalog 管理，计算节点只保留内存状态。ClickHouse 于 2025 年公开这张图，并在 2026 年的 Cloud 架构文章中继续使用同一套存算分离模型。 $3$ $7$

同时，这条路线已经不是 ClickHouse 独有。Datadog 在 2022 年介绍的 Husky，是一个围绕对象存储构建、存算分离、读写分离的向量化列存；Writer 将事件文件写入 Blob Storage，Compactor 独立合并，Reader 按需扫描并返回局部聚合结果。 $8$ Honeycomb 也长期使用自研的分布式列存 Retriever 保留高基数、宽事件原始数据，支持事前无法预测的交互查询。 $9$ Elastic Serverless 也把便宜对象存储作为 System of Record，将索引与搜索计算分开。 $10$

这几套系统的索引、元数据、文件格式、Cache 和多租户调度实现并不相同，物理方向已经很接近：原始事件保存更久，按列执行聚合，热数据用 Cache 吸收对象存储延迟，写入、合并与查询独立隔离，再通过水平扩展应对峰值。

技术竞争没有结束。它从列存与分布式查询的有无，变成了更细的工程竞争：倒排索引与 Skip Index 怎么选，Cache 是跟着 Compute 还是独立服务，Fresh Data 在多长时间内可见，Compaction 怎样隔离，一个租户的全年查询会不会影响另一个租户的告警。这些差异会影响成本和稳定性，只是很难再形成一家工程师水平比另一家高十倍的代际差。基础软件公司的工程师都在看同一批论文、硬件与开源实现，有效设计会很快被理解和追赶。

2.2 数据模型、查询语义与工作流差异

把底层原语收敛理解为产品同质化，还是太早。Honeycomb 强调 Wide Event 与事后任意切分，Datadog 要在统一事件存储上服务日志、Trace、Network 等多种已有产品，ClickHouse 则同时支持自定义 Schema、ClickStack 默认 Schema 和直接 SQL。 $1$ $8$ $9$

Metrics 是一个明显的反例。ClickHouse 对事件型 Metric 很适合，它对 Prometheus Remote Read/Write、PromQL 和 TimeSeries Engine 的支持到 2026 年仍在实验与持续补齐阶段。那些依赖完整 PromQL 语义、大量现有 Dashboard 与 Alert Rule 的团队，暂时不应把 ClickHouse 当成 Prometheus 后端的 Drop-in Replacement。 $1$ 同样，Trace 的 Parent/Descendant、Profile 的 Stack 聚合与 Diff、Security 的 Detection Lifecycle，都不会因为底层能写 SQL 就自动出现。

收敛发生在存储与执行原语，产品分化向 Schema、查询语义、预计算、默认值与调查流程转移。这也是市场竞争开始占据更大权重的位置。

2.3 ClickHouse 赢了，哪一个 ClickHouse 产品赢了？

这里还要校正一个很容易过期的印象。把腾讯云 ClickHouse 整体归为存算一体，放在 2026 年 9 月已经不准确。腾讯云在 2026 年 4 月 21 日更新的 TCHouse-C 产品文档里，已经同时列出存算一体与存算分离两种架构；后者允许计算与存储独立配置和伸缩，并用对象存储降低成本。 $11$ 如果一套现有腾讯云集群买的是传统存算一体规格，那么"计算与存储资源耦合"的判断对这个实例仍然成立，不能再把它外推到整个产品线。

云上的 ClickHouse 至少有三种交付关系：ClickHouse 自己运营的 ClickHouse Cloud，ClickHouse 管理但数据面放在客户云账号里的 BYOC，以及公有云厂商基于开源内核运营的托管产品。机器落在哪朵云上，只说明基础设施位置，不说明谁在提供数据库产品。ClickHouse Cloud 同时运行在 AWS、GCP 与 Azure 上，这三家在其合规文件中的角色是 Hosting and Infrastructure Provider，数据库服务和控制面仍由 ClickHouse 提供。 $12$ $13$ $14$

下表只比较截至 2026 年 9 月 2 日能由官方文档确认的产品形态，不把"兼容 ClickHouse SQL"当成"等同 ClickHouse Cloud"。地域、可购规格和版本还会继续变化，真正选型时仍要落到具体 Edition 与 SKU。

云上入口	数据库产品运营方	当前公开的架构口径	与 ClickHouse Cloud 的关键区别
ClickHouse Cloud on AWS / GCP / Azure	ClickHouse	SharedMergeTree 将持久数据放到共享对象存储，计算节点无状态；分布式 Cache 与 Shared Catalog 也从计算节点拆开，一个 Warehouse 可以让多个 Service 共享数据 $3$ $7$ $12$	这是 ClickHouse 官方云产品，三朵公有云主要提供底层资源与 Marketplace 入口；扩缩容、升级、备份、集成和 SLA 由 ClickHouse 的控制面负责
腾讯云 TCHouse-C	腾讯云	同时提供存算一体与存算分离；分离形态支持计算、存储独立伸缩，计算扩容不搬数据，持久层使用对象存储 $11$	架构取决于实际购买形态，不能用一个"Tencent ClickHouse"标签推断扩容、迁移和副本成本
阿里云数据库 ClickHouse	阿里云	企业版是 OSS 共享存储、无状态计算与 SharedMergeTree 的 Serverless 存算分离；社区兼容版仍是 ECS、云盘、Shard 与 Replica 耦合 $15$	同一云厂商内部已经分成两条产品线，内核版本、功能矩阵和运维能力也分别演进
华为云 CloudTable ClickHouse	华为云	2026 年 6 月 29 日版用户指南仍明确写"集群存储模式：存算一体"，磁盘容量随 ClickHouse 计算节点选择，为每节点 100---10000 GB $16$	扩计算节点、扩磁盘和调整规格仍是集群资源操作，与 ClickHouse Cloud 的无状态计算、共享数据和 Service 隔离不是一套伸缩模型

Apache 2.0 让公有云可以基于同一内核构建各自的托管产品。 $17$ 同一个 ClickHouse 名字下面，存储架构、控制面、版本和 SLA 可以完全不同，阿里云的两种 Edition 已经说明这一点。ClickHouse 赢得引擎标准只会把市场做大，不会自动替 ClickHouse Cloud 或任何一家公有云赢得订单；托管服务这一层，竞争的仍是谁占住 workload 与数据入口，并掌握云账号和运维关系。

3. Workload、生态位与新产品的插入条件

3.1 Workload 的产品定义

这里的 Workload 指一组共同决定产品形态的负载与业务约束：数据由谁产生，怎样进入，Schema 如何演化，写入峰值多高，默认查询扫多少时间，哪些结果需要预计算，调查过程中会连续发出多少次查询，最后又由哪一类人为结果付费。

同一个 ClickHouse Engine，跑 Infra Observability、LLM Observability 和 Security Analytics，产品形态完全不同。ClickStack 需要处理 Service、Deployment、Log、Span 与 Session Replay 的关联；Langfuse 需要追踪 Prompt、Generation、Tool Call、Token、Cost 和 Eval；RunReveal 需要维护 Source、Pipeline、Detection、Signal、Alert 和 Investigation。数据库的查询速度是共同底座，这些对象和流程才是用户实际接触的产品。

这些对象和流程还会反过来决定底层的优化方向。没有一种基础设施产品能在诞生时枚举后续所有 workload，排序键、索引、预计算、资源隔离和故障恢复也不可能预先一次做完。只有 workload 进入真实使用，查询形态、延迟边界与成本问题连续暴露，引擎团队才知道下一步该优化什么。ClickHouse 把上层 workload 收回来，也是在缩短从使用问题到引擎 Roadmap 的反馈链。 $2$

3.2 生态位与默认路径

生态位决定一个产品在用户架构里站在哪里。它可以是数据生成点，可以是数据进入管道、存储、查询入口、Dashboard、告警中心、Agent 交互界面，也可以是企业采购与权限治理的入口。一个位置一旦进入默认路径，就会积累数据、Schema、Dashboard、告警规则、Runbook、用户习惯、权限与合同。单项技术优势要先超过这笔迁移成本，才能成为足够强的插入理由。

为了便于讨论，基础设施产品的产品力可以粗略写成：

t e x t 产品力 a p p r o x t e x t 引擎能力 t i m e s t e x t W o r k l o a d F i t t i m e s t e x t 生态位 \\text{产品力} \\approx \\text{引擎能力} \\times \\text{Workload Fit} \\times \\text{生态位} text产品力approxtext引擎能力timestextWorkloadFittimestext生态位

这里的乘号只强调三者不能完全互相补偿，不代表可计算的商业模型。

Workload Fit 不足。 引擎本身很快，用户接入时仍要自己补齐 Schema、数据接入、索引、预计算和工作流；这部分适配同时包含性能调优与基础能力建设。
生态位不足。 产品做得不错，却进不了数据管道与采购入口，只能不断支付获客成本。
引擎能力不足。 生态位已经成立，查询成本和稳定性如果持续失控，竞争产品仍会获得强制切入的窗口。

OpenTelemetry、MCP、Iceberg、PromQL 这些开放契约降低了接入和迁移成本。ClickHouse 的开放生态文章把 OTel、MCP、Iceberg/Delta 与数百个集成都放在同一套扩张策略里。 $18$ 它们发挥作用有一个前提：性能、成本或新能力已经让用户产生了足够强的替换意愿。兼容 OpenTelemetry，应用不必重新埋点；兼容 PromQL，原有查询和告警规则可以继续使用；直接读取 Iceberg，新引擎不必先复制全部数据；支持 MCP，Agent 不必重写工具调用接口。标准降低的是把替换付诸实施的成本，不能回答用户为什么要换。

3.3 既有生态位的插入条件

这一点和我在司内看到的很多竞争很像。对手已经把住数据入口、用户入口或一个团队的默认工作流，只要做得不是特别烂，新产品就缺少插入的理由。这个现象很容易被解读为技术团队不够强，实际阻力常常来自另一边：新方案能够提供的改善，还不足以覆盖迁移、重新建模、学习、稳定性验证和组织协作的成本。

新产品要插入一个已经成立的位置，通常需要出现下列至少一种条件。

当前产品已经失效。 成本、延迟、稳定性或功能边界差到用户必须换，迁移成本才会突然变得可接受。
新 workload 绕过旧入口。 Agentic Investigation、LLM Eval、Session Replay 或新的高基数安全数据产生了旧产品没有控制的用户与数据路径。
组织与采购边界发生变化。 原本由单团队自建的系统变成公司统一平台，或者从自托管转向 Cloud/BYOC，新的责任人会重新评估默认方案。

ClickHouse 收购 HyperDX、Langfuse 与 RunReveal，实际上是主动建立第二种条件。它通过新 workload 创建原生的用户入口，不必只等原有市场中的数据库用户把后端换成 ClickHouse。这里的市场竞争落在产品进入架构的位置、天然留在引擎上的 workload 和最终用户开始工作的界面。多投广告、多招销售改变不了其中的大部分默认路径。

4. ClickHouse 的收购地图与上层迁移

ClickHouse 近几年公开的收购与项目并入很连贯。下表用广义口径统计：chDB 的官方措辞是加入 ClickHouse Family，不和其他公司收购混成同一种交易结构。

时间	对象	原有位置	进入 ClickHouse 后的作用
2022 年末	Arctype	SQL Client	成为 ClickHouse Cloud SQL Console 与统一 Console 的产品基础 $19$
2024-03	chDB	进程内 OLAP	将 ClickHouse 执行引擎带入 Python、Notebook 与本地 Agent 环境 $18$
2024-07	PeerDB	Postgres CDC	成为 ClickPipes Postgres CDC 的核心引擎，让 Postgres 数据持续进入 ClickHouse $20$ $21$
2025-03	HyperDX	Infra Observability	进化为 ClickStack UI，补采集、Schema、查询生成、可视化与调查工作流 $22$
2025-11	LibreChat	AI Chat / Agent	建立 Agentic Analytics 交互入口，连接模型、MCP、身份与数据治理 $23$
2026-01	Langfuse	LLM Observability	获得 LLM Trace、Eval、Prompt 管理与独立云产品 $24$
2026-09	RunReveal	Security Data / SIEM	获得安全采集、检测、调查和 Agentic SOC workload $2$

图 3：ClickHouse 公开项目并入与收购的位置示意。对象、时间与产品关系来自官方公告；数据/交互入口与上层 workload 是本文的分类。对应绘图脚本与 SVG/PDF 位于同目录。

前三项主要降低引擎的采用摩擦。Arctype 解决查询和数据浏览入口，PeerDB 解决 Postgres 的持续入湖，chDB 把同一执行引擎带到进程内。PeerDB 的后续结果很直观：收购后四个月完成 ClickPipes 集成，到 2025 年底已有 400 多家公司使用，每月复制超过 200 TB Postgres 数据，使用量接近收购前的 100 倍。 $21$

从 HyperDX 开始，位置明显向上移。收购对象越过数据进入和查询引擎，开始直接覆盖可观测、LLM 工程和安全这些上层产品。这些项目都在收购前就已经用 ClickHouse 证明过 workload，买回来以后无需再从一个竞争引擎迁移数据层。Langfuse 的 Cloud 和自托管架构都已经使用 ClickHouse，HyperDX 本来就是 ClickHouse-native UI，RunReveal 甚至早已把客户自有 ClickHouse 做成一种正式交付模式。 $5$ $22$ $24$

这种收购同时获得四样东西：已成立的用户需求，一个已经默认使用 ClickHouse 的 workload，对应领域的工程团队，以及能接触最终用户的产品入口。这比在 Roadmap 上增加一行支持 Security 或 LLM Observability 有效得多。

5. AWS 收购 DuckLabs 与默认值竞争

不到一周前的另一笔交易是 AWS 收购 DuckLabs。严格来说，AWS 收购的是 DuckDB 背后的商业公司与核心团队，DuckDB、DuckLake 与 Quack 的开源项目仍由 DuckDB Foundation 治理并使用 MIT 许可证。 $25$ 上一篇文章已经详细拆过交易边界，本文只取其中一个结论：AWS 获得了一组能把高效分析执行带到浏览器、应用进程、Lambda、EC2 和长期服务的人，而 S3 可以继续做这些执行位置背后的持久数据层。

ClickHouse 与 AWS 保住的生态位不同。ClickHouse 通过收购上层 workload，让更多数据、查询与最终用户自然进入 ClickHouse；AWS 容许计算位置继续分散，只要长期数据、Catalog 与云上执行还围绕 AWS 展开。一家从引擎向 workload 和交互入口扩展，另一家从对象存储向应用内执行引擎扩展。方向看起来相反，实际上都在争夺架构的默认值。

技术开放不会消除这种竞争。MIT、Apache 2.0、OpenTelemetry 和 MCP 让其他厂商有权接入，还要有人愿意为第二套 Backend、第二个对象存储或第二条 Agent 路径持续做测试、发布、运营与支持。标准可以打开门，不会自动把一个产品放进屋里。

6. 上移战略的边界

这条路也有明显风险。ClickHouse 自己在 8 月 27 日的文章里已经承认，可观测厂商可能因为 workload 足够特殊，或者不愿把核心存储交给一家同时与自己竞争的公司，继续自研引擎。这在商业上是合理选择。 $1$

RunReveal 收购公告专门强调 ClickHouse 会继续做中立底座，继续支持其他安全公司构建产品，RunReveal 也保留 BYOD。 $2$ 这些承诺很重要，也恰好证明矛盾已经存在。引擎厂商向上拿走更多产品价值，平台上的创业公司就会重新计算依赖风险；一旦这些公司开始把自己的引擎适配当成第二条默认路径，ClickHouse 原本的 workload 飞轮又会被削弱。

另一个风险是产品整合。一组开源项目可以分别很优秀，用户仍然需要统一身份、计费、权限、Schema、导航、支持和 SLA。收购只缩短组建团队与获得知识的时间，不会自动把七个项目变成一个统一产品。

7. 结束语

RunReveal 这笔交易，给 ClickHouse 是否正在赢得可观测性战争补了一个比文章更准确的答案。它已经在存储与查询层拿到很好的位置，可观测产品本身还没有因此自动属于 ClickHouse。所以它开始买 HyperDX、LibreChat、Langfuse 和 RunReveal，从引擎走向不同 workload 的 Schema、默认查询、调查流程与最终用户。

随着数据库、可观测和对象存储技术成熟，核心引擎仍然会持续产生性能与成本差异，技术原语也会继续被同行理解、实现和追赶。市场最后比较的会是：哪家的默认 Schema 更理解 workload，哪家掌握数据与用户入口，哪家已经占住一个对手很难插入的生态位。

ClickHouse 在 2026 年 1 月融资后的估值已经达到 150 亿美元；截至 2026 年 9 月 2 日，LinkedIn 页面显示 672 名关联员工（不等同于公司内部 HR 口径），官方社区页记录的贡献者则超过 3200 人。 $26$ $27$ $28$ 以这样的资本、组织和开源社区规模，赢下越来越多可观测 workload 并不意外。这个结论放到云上还要再拆一层：开源内核的普及把 ClickHouse 带进更多系统，扩大的是 ClickHouse Cloud、公有云托管版与自建集群共同面对的市场，不会替任何一种交付方式提前决定份额。我认为公有云里的托管 ClickHouse 团队应该有更大的野心，它们已经承接了开源普及带来的 workload 增长，下一步不该只交付一个有人运维的 ClickHouse 集群，还要利用云账号、VPC、IAM、对象存储、数据入口、账单和销售关系，把这些 workload 留在自己的产品里。

前面的收购序列还反推出一个组织问题。PaaS 产品进入技术成熟期以后，核心研发仍然是把产品做出来的前提，竞争力的主要增量越来越来自那些能把新 workload 带进产品的人。他们要看懂上层业务，把 Security、LLM Observability、Postgres CDC 这类需求翻译成数据入口、Schema、默认查询和交付路径，再把产品推到真实用户面前。ClickHouse 买回来的几家公司，都同时带着一组已经成立的 workload 和一个原本不属于数据库团队的用户入口。

这要求研发团队至少和一名真正懂技术的产品或市场人员配对。他需要持续看上层业务，找到产品可以进入的位置，把需求和使用反馈带回 Roadmap，再向外完成分发。这个角色的工作从上层业务发现一直延伸到产品分发，排期和销售材料只占很小一部分；核心产出是让 workload、用户反馈和产品能力连续运转。

没有这类岗位时，组织很容易进入一种混沌状态：开发同时承担市场、产品、项目管理，甚至运维体系、测试系统的工作，晋升考核却仍然落在架构复杂度、性能数字和技术难度上。个人获得认可的路径与产品完整发展的路径由此分开，前者奖励把局部技术做深，后者需要有人持续带回新 workload、用户入口和商业反馈。纯靠开发把这些工作一起扛住很割裂。