ClickHouse真的赢下可观测性之战了吗？

过滤同样由读取的列和粒度驱动，而不是由数据集中不同值的总数驱动。对高基数字段的选择性过滤可以减少扫描的数据量，尤其是在排序键或二级索引支持该访问模式时。基数仍然有成本。对数百万个不同值进行分组需要ClickHouse构建数百万个聚合状态，增加查询时间和内存使用，尽管配置后这些状态可以溢写到磁盘。通常，用户也很少想按数百万个序列分组并显示！我们的ClickHouse和Prometheus中基数的深入比较探讨了这些成本在每个模型中出现的位置。结果是ClickHouse用户不再害怕高基数：

“我们不再害怕基数……我们基本上可以把所有数据放在一个地方，并用它来回答所有问题。” Sierra

不仅仅是列

列式架构显然是ClickHouse在上述狭义上“赢得”可观测性存储和查询层的原因之一。但仅有列并不能解释为什么这么多工程团队和可观测性供应商选择了它。

对性能的执着

ClickHouse的架构解释了其在可观测性数据上的大部分性能。压缩减少了必须存储和读取的数据量，而列式I/O、向量化执行和并行性（节点内和节点间）减少了回答查询所需的工作。该项目还培养了一种围绕性能和资源效率的执着文化。Andy Pavlo在CMU关于查询执行的讲座中捕捉到了这一重点：

ClickHouse的创造者，也是这种性能关注点的来源，Alexey Milovidov，从项目内部解释了同样的工程哲学：

这项工作在可观测性中产生复合效应，在足够的量下，每一个不必要的字节读取和每一个浪费的CPU周期都成为运营成本。这种效率也改变了保留的经济性。ClickHouse对对象存储以及存储与计算分离有一流支持，允许以低成本保留大型数据集。结合压缩和选择性读取，这使团队能够保留全保真、未采样的遥测数据更长时间，而无需将其全部保存在本地磁盘上。

采样和汇总可以成为优化技术，而不是存储成本强加的要求。团队可以保留原始事件，并在知道哪些问题重要后再决定聚合什么。

我们的用户在实践中重视这种资源效率：

“用户现在可以查询长期时间范围内的数据，并实时分析原始数据，而不是依赖预聚合格式。” Tekion

“对于我们的用例，ClickHouse提供了市场上任何产品中最高的性能价格比。” Last9

所有信号的单一数据存储

许多团队不希望对每个遥测信号使用不同的后端。ClickHouse可以服务日志、追踪和某些指标工作负载（更多见下文），减少了团队必须学习和维护的具有不同扩展模型、故障模式、查询语言和运维需求的系统数量。这个机会超越了可观测性，ClickHouse还用于实时分析和数据仓库，允许遥测数据、运营数据和业务数据在同一引擎中查询和关联，而不是在应用层之后连接。在这些工作负载重叠的地方，整合意味着更简单的基础设施和更低的总维护成本。

Sierra很好地捕捉了这一点，认为可观测性和分析只是一个数据问题：

“如果我们不再将可观测性和分析视为两个不同的孤岛，而只是一个数据问题，由像ClickHouse这样真正好的计算引擎驱动，那将非常酷。”

SQL作为数据的通用语言

我们相信ClickHouse被广泛用于可观测性的另一个原因是其查询接口。SQL是一个开放、易于理解的标准，拥有成熟的工具生态系统，使工程师易于访问，并便于构建应用程序。它也在AI代理使用的训练数据和工具中得到了很好的体现。ClickHouse用大量的分析、统计、时间序列和字符串函数扩展了SQL，支持复杂的过滤、维度分组、连接、窗口函数和多阶段聚合。这些更丰富的分析工作流可能难以用为针对单一数据信号（如指标或日志）优化的数据存储而设计的查询语言来表达。

“我们希望能够对我们的数据提出有趣的问题，而不是受限于简单的领域特定语言。” Tesla

我们承认并非每个用户都需要这种控制水平，当然，这就是为什么ClickStack提供熟悉的构建器，并将Lucene风格的搜索转换为针对底层ClickHouse模式和索引优化的查询，以及拥有抽象复杂性的查询构建器。当这些抽象用尽时，原生SQL图表和警报为用户提供直接访问引擎的途径。同一平台可以支持快速日志搜索或定制仪表板，同时为想要更深入调查和分析可观测性数据的用户保留SQL。

开放生态系统

ClickHouse的开放生态系统是团队愿意采用它进行可观测性的另一个原因。我们的方法是让用户在他们所在的位置与我们见面，而不是要求他们采用一个完整的工作流程。 ClickStack是开源栈适用于想要集成体验的团队，而对Grafana插件的持续投资支持那些已经使用Grafana的用户。越来越多的合作伙伴集成给团队提供了更多收集、可视化和调查的选择，而无需更改底层存储。

同样的方法也塑造了我们对 OpenTelemetry 的投资。这包括在 Collector Contrib 发行版中针对clickhouse exporter 和 Datadog receiver的工作，帮助现有的遥测管道连接到兼容 OpenTelemetry 的后端。我们还为 Apache Arrow collector 项目做出贡献，支持 Arrow 作为摄取格式，以减少传输和序列化开销。ClickStack 的兼容 OpenTelemetry 的SDK 发行版增加了诸如会话回放和浏览器捕获等功能，而标准 SDK 并不直接提供这些功能。但最重要的是，采用 ClickHouse 不应要求用户放弃他们已有的工具和探针。

宽松的许可

如果不承认 ClickHouse 的 Apache 2.0 许可对其采用所做的贡献，那将是失职的。宽松的许可让团队可以在本地或自己的基础设施中运行 ClickHouse，根据需求进行修改，并在此基础上构建商业产品和 SaaS 服务。他们可以按自己的条件开始，并保留对数据库运行位置和方式的控制权。

“开源版本有明显的好处：‘上手快，久经考验，性能出色。’Anthropic

“团队欣赏 ClickHouse 的开源根源——‘我们所有的技术栈都是开源的’[尽管]他们最终选择运行 ClickHouse Cloud。”Laminar

如果以后运维数据库变成了一项分散精力的事务，这些团队可以选择 ClickHouse Cloud，并获得托管服务的常规好处。其存储与计算分离的特性在可观测性所见的规模下尤其具有吸引力：数据仅写入共享对象存储一次，避免了每个副本单独复制——计算服务可以读取这些数据并独立扩展，无需“写入税”。例如，团队可以将摄取与交互式查询隔离开来，这样摄取峰值就不会消耗用于调查的计算资源。开源让用户控制他们如何开始；ClickHouse Cloud 在他们需要时提供了另一种运行模式，而无需他们采用不同的数据库。

那么指标呢？

如果您已经读到这里，您可能会想，同样的存储和查询论证是否适用于指标。诚实的回答是既对也不对。

对于作为高基数事件字段承载的指标，答案是肯定的。这就是 Charity 所描述的模型：将测量值与产生它的上下文放在一起，然后在查询时进行聚合。您可以将这些记录视为附加了测量值的结构化日志。它们保留了服务、客户、请求、部署和其他维度，而这些维度在传统指标存储中会导致序列爆炸。ClickHouse 将这些维度视为列，因此向一个字段添加基数并不会使数据库必须维护的对象数量倍增。

Prometheus 风格的指标是另一个问题。Prometheus 和 OpenTelemetry 定义了不同的指标模型和协议（为什么需要可观测性，两者都是另一篇文章的问题），而且团队多年来围绕它们构建了仪表板、警报和操作习惯。满足用户的需求意味着支持这些工作流程，而不是要求每个人都把 PromQL 翻译成 SQL，或把每个指标重新建模为宽事件。

这种支持今天已经存在，但我们不会说它已经完成。ClickHouse 24.8引入了实验性的 TimeSeries 表引擎，支持 Prometheus 远程写入和远程读取。ClickHouse 25.8增加了初步的 PromQL 支持，并在2026 年 6 月ClickStack 公开了一个实验性的 PromQL 数据源和图表编辑器，由同一引擎支持。覆盖范围持续增长，但存储模型和 API 仍可能发生变化。依赖成熟 PromQL 语义进行仪表板和警报的团队，目前还不应将 ClickHouse 视为成熟 Prometheus 兼容系统的直接替代品。

直接替代 Prometheus 的兼容性和完善 TimeSeries 引擎现在是 ClickHouse 和 ClickStack 的主要投资领域。对于 ClickHouse 成为整个可观测性的默认存储和查询层而言，这可能是最大的剩余差距。日志、追踪和事件式指标的证据已经很充分。Prometheus 风格的指标是我们仍需努力的地方。

数据库并不能构成可观测性产品

ClickHouse 可能是合适的存储引擎，但由此产生的可观测性产品仍然可能很糟糕。采集、模式设计、信号关联、可视化、告警、调查流程和操作所有权都决定了系统能否帮助工程师找到事件的原因。选择不当的排序键会限制数据修剪。查询可能无法有效利用模式和索引。界面可能隐藏有用的上下文，或使常规调查变得不必要地困难。数据库提供了能力，但产品仍然必须将它们连贯地组装起来。

这一认识是我们构建 ClickStack 的原因之一，它本身也获得了强大的开源采用。

ClickStack 为我们提供了一个场所，将我们学到的知识转化为模式、生成查询和优化调查工作流的默认设置。我们对默认 ClickStack 的投资以加快查询速度的工作说明了这一点，其改进并非通过更改一个数据库设置而来。它需要对主键、文本索引、物化视图以及 UI 生成的查询进行协调更改，并针对代表性的可观测性工作负载进行测试。ClickHouse 使这种性能成为可能；您仍然需要做出正确的决策来展现它。

代理改变了游戏规则

可观测性的主要界面正在超越仪表板和搜索框，因为代理代表工程师进行调查、形成假设并查询遥测数据。现在，我们内部 LogHouse 集群超过 60% 的查询来自代理。

这改变了工作负载。一个代理在发现模式、验证结果、重试和深入探查时，可能会为一个问题发出数十个查询，而无需运维工程师的停顿。