本文字数9383估计阅读时间24分钟作者Mike Shi编者按本文译自 ClickHouse 原博客链接点文末-查看原文。 原文围绕「探讨 ClickHouse 作为可观测性底层引擎的优势与局限」展开。存储引擎的性能优势为可观测性奠定了基础但优秀的架构设计与产品化能力依然是不可或缺的关键环节。2026 年 7 月Mat Duggan 和 Charity Majors 分别撰文指出“ClickHouse 正在赢得可观测性之战”。这并非我们的授意读到这些文章我们深感荣幸也对这一观点的广泛传播感到惊喜。我们固然感激这些认可但同时也想聊聊为什么两位资深从业者兼行业领袖会基于生产环境的观察得出这一结论。ClickHouse 究竟在可观测性技术栈的哪个环节占据优势为什么它会成为主流选择哪些场景它并不适用为了保持竞争力我们还需要在哪些方面改进ClickHouse 正在帮助越来越多的团队实现降本增效这令我们倍感欣慰。不过借用 Lewis Hamilton 的话我是个铁杆 F1 车迷——“我们仍有未竟之事”。“赢得”到底意味着什么Mat 和 Charity 最终都将目光聚焦在存储与查询层这界定了“赢”的范畴因为这只代表了可观测性问题的其中一面。数据采集、模式设计、关联、可视化、告警和排查流程以及围绕这些环节的体验仍然需要构建。一个优秀的引擎奠定了基础但它无法代替你做出产品决策也不能决定你应当如何处理和理解遥测数据。正如 Charity 所言“再好的存储引擎也无法拯救糟糕的架构”在存储层ClickHouse 已成为许多自建可观测性系统的工程团队的默认选择。Netflix、Anthropic 和 OpenAI 的团队均使用它来大规模存储和查询遥测数据尤其是日志和追踪。“ClickHouse 在 Claude 4 的研发与发布中发挥了关键作用。它运行稳定查询极快且成本可控。在打造最先进语言模型的过程中ClickHouse 创造了巨大价值。” Anthropic“ClickHouse 里的数据比其他任何地方都好用。没有其他系统能让你如此灵活地拆解分析数据、提出深度问题并在合理时间内获得答案。目前市面上没有任何产品能与 ClickHouse 抗衡。” Tesla“许多同行都在完全相同的场景可观测性中使用 ClickHouse。它久经沙场是这项工作的理想工具。” OpenAI同样许多可观测性 SaaS 公司也在 ClickHouse 之上构建产品。他们将 ClickHouse 作为底层引擎同时保留对界面、工作流和产品决策的掌控。这些产品服务于不同的用户设计理念也不尽相同。有些产品围绕信息丰富的宽事件wide events展开另一些则保留了传统体验依然按日志、指标和链路追踪来组织数据。它们的共同点在于都利用了 ClickHouse 的列式架构这种架构天生契合遥测数据的形态与访问模式。我们认同 Charity 的观点与分散的信号相比以宽事件形式存在的可观测性数据往往更实用。将上下文集中在一起可以保留数据间的关联避免在不同格式间重复记录也能让团队根据需求灵活生成视图。不过许多团队已经围绕日志、追踪和指标建立了一套完整的插桩、模式与工作流他们不应为了享受 ClickHouse 的优势而被迫重构现有的遥测体系。ClickHouse 同样能出色地处理常规日志与链路追踪数据。生产环境的日志通常是结构化、宽字段且高基数的——本质上宽事件就是带有指标的结构化日志。即使是格式自由的文本消息也包含大量重复的词元和模板只要通过排序将相似内容聚集就能实现极高的压缩率。链路追踪的跨度trace spans本身就类似于宽事件它们都是包含时间戳、耗时、标识符、属性和状态的结构化记录。ClickStack 也采取了同样务实的策略。它整合了 ClickHouse、OpenTelemetry Collector 和 ClickStack UI在全面支持宽事件的同时也能接收既有的日志、链路追踪和指标数据。用户既能保留熟悉的工作流又不会丧失底层数据的关联与查询能力。各种产品在信号、模式和工作流的设计上可能各有千秋但在存储层的选择上却殊途同归。无论采用哪种模型ClickHouse 都已证明自己是卓越的存储和查询引擎。因此如果“赢”意味着成为构建可观测系统时的默认存储与查询层那么答案或许是肯定的。为什么 ClickHouse 如此适合作为存储层ClickHouse 作为一款列式数据库天然契合可观测性场景。无论是宽事件、日志记录还是追踪 span虽然设计理念不同但都具有典型的分析型特征单条记录字段多、数据规模庞大且查询时通常只需检索或聚合极少数关键字段。在行式数据库中同一条记录的各个值存储在一起。而列式数据库则将相同字段的值集中存储时间戳与时间戳相邻服务名与服务名相邻。这种布局非常符合可观测查询的需求因为这类查询通常只需在海量事件中扫描特定的几个字段。这一结论并非 ClickHouse 独有。Honeycomb 早就意识到这一点并围绕宽事件构建了自研的分布式列式存储 Retriever。Datadog 在 2022 年推出用于处理日志和事件的列式存储 Husky 时也得出了类似的架构结论。尽管产品模型不同——Honeycomb 主张上下文集中Datadog 倾向于传统体验——但在存储层两者都选择了列式结构。那么为什么列式架构如此契合可观测性数据磁盘层面的优势立竿见影。在每个数据片段内行按排序键排列列则单独存储。如果排序键匹配主要的访问模式相似的值就会聚集在一起。在通用压缩之前可以通过字典、增量和游程编码大幅缩减体积通用压缩也能从连续的相似值中获益。这些压缩优势通常是 ClickHouse 用户最先感知的特点“ClickHouse 的压缩效果令人惊叹。有些列的压缩比达到了 10 倍甚至 20 倍个别情况下甚至高达 50 倍。”Character.AI“我们仅用 20 个 CPU 核心就能实现每秒 300 万行的写入速度且在未加调优的情况下达到了 1:8 的压缩比。”Shopee磁盘上的数据布局也契合工程师的实际查询习惯。许多图表依赖聚合查询例如按时间统计请求量或计算平均延迟。这些查询可能扫描数十亿条记录但只会读取时间戳、聚合值等极少数列。ClickHouse 可以只读取所需的列从而消除不必要的 I/O 开销。其稀疏主索引能直接跳过不符合条件的数据颗粒跳数索引则进一步支持了多样化的访问模式。“约 80% 的查询仅涉及过去两天的数据因此这部分数据会被保留在磁盘上以便快速访问。”OpenAI“ClickHouse 能够基于时间跳过数据这让表的大小变得不再关键因为它能精准定位所需信息。”BENOCS当数据进入 CPU 处理阶段列式布局会继续发挥威力。ClickHouse 以数据块为单位处理列值而非逐行解析。在执行聚合时它可以对一批连续值执行相同操作。这提升了缓存局部性降低了单行处理开销并能充分利用处理器支持的 SIMD 指令。多个数据块也能跨 CPU 核心并行处理。这种并行能力延伸到了整个集群。分布式查询会被发送至存储数据的分片各节点同步扫描并聚合本地数据。这些部分结果随后汇总至发起节点。因此增加节点不仅能扩展存储还能线性提升查询算力。Parallel Replica 功能将查询分发至多个节点并行处理……使查询速度提升了 2.5 倍。Poizon大量使用 SIMD 指令确保数据结构对 CPU 缓存友好并采用专用算法来处理海量数据。RunRevealMat 的文章强调了 ClickHouse 的另一项特质扩容模式。他的观点是每天处理 10 TB 数据的 ClickHouse与每天处理 1 TB 时相比无非是多了几个分片而已。早期部署可以通过升级配置实现垂直扩展直到负载需要时再引入分片。随后在沿用相同引擎与模型的前提下通过增加分片实现水平扩展。虽然增加分片仍需容量规划和数据平衡但在整个增长过程中系统的核心架构始终保持一致。其他大规模运维 ClickHouse 的团队也提到了这种可预测性ClickHouse 是云原生的专为水平扩展而设计。这意味着在扩展写入与查询能力时运维成本相对较低。OpenAI聚合是常见的查询模式但在排查问题时工程师还需要搜索错误日志、按属性筛选并按图索骥寻找线索。告警和看板无法预见所有问题这种高度依赖搜索的工作流正是 Elasticsearch 成为主流日志后端的原因。ClickHouse 本就可以利用高度并行的字符串扫描执行文本搜索并借助布隆过滤器跳数索引排除无关数据。布隆过滤器确实有用但它是基于概率的且在颗粒级别生效可能产生误报并需要精细调优当词项分布过广时其过滤效果会大幅下降。在 2026 年 3 月全文搜索在 ClickHouse 中正式发布。其文本索引采用倒排索引将词元映射至行号。ClickHouse 无需扫描所有字符串即可确定候选行并在同一次查询中完成过滤和聚合。虽然这类索引会占用更多空间并增加写入开销但它提供了精确的行级查找并支持多词元与短语搜索。我们在 ClickStack 中应用这些索引来加速日志搜索与属性过滤。由于索引本身可搜索ClickStack 还可以通过前缀查找实现自动补全而无需扫描底层遥测列。倒排索引负责缩小范围后续分析则交给高效的列式引擎。用户反馈表明文本索引显著提升了搜索性能“ClickHouse 的全文搜索改变了我们的日志检索方式。过去使用线性扫描进行多词项搜索需要 30 到 45 秒。得益于倒排索引相同的查询现在只需约 400 毫秒。”Icite高基数在列式模型中的表现截然不同。在 Prometheus 等系统中标签的每种唯一组合都会生成独立的时间序列带来额外的元数据和索引开销。而 ClickHouse 只是直接写入新行。诸如TraceId或user_id等字段可能包含数百万个值但其成本仅局限于该列本身。虽然这类字段的压缩率可能稍低但绝不会影响其他字段的压缩效果。过滤操作取决于读取的列而非独立值的总数。对高基数字段使用选择性过滤能减少扫描量尤其在排序键支持该模式时更为明显。当然高基数仍有开销按数百万个值分组需要构建大量聚合状态会消耗更多内存。但在实际应用中用户很少需要同时展示数百万个序列。在我们关于 ClickHouse 与 Prometheus 基数的对比中探讨了这些差异。最终用户不再谈“基数”色变“我们不再对基数感到恐惧……我们能把所有数据集中在一处用来解答所有问题。”Sierra不仅仅在于列显然列式架构是 ClickHouse 胜出的核心原因之一。但单靠结构不足以解释为何如此多的团队和供应商会选择它。极致的性能追求ClickHouse 处理遥测数据的出色表现很大程度上归功于其架构。数据压缩减少了存储与读取量而列式 I/O、向量化执行以及并行处理则降低了查询负载。该项目还形成了一种执着于性能与资源效率的文化。Andy Pavlo 在 CMU 讲座中准确概括了这一关注点视频链接https://www.youtube.com/watch?vVy2t_wZx4Ist3579sClickHouse 创始人 Alexey Milovidov 从项目内部阐述了同样的工程理念视频链接https://www.youtube.com/watch?vCAS2otEoerM在可观测性领域这种优化效果会积少成多。当数据达到一定规模每一字节的冗余读取和每一周期的 CPU 浪费都会转化为运营成本。这种效率也重塑了数据保留的成本模型。ClickHouse 原生支持对象存储和存算分离能以极低成本保留庞大数据集。结合压缩与选择性读取团队可以将全量、未经采样的遥测数据保留更久。这样一来采样和上卷就成了优化手段而非受制于成本的硬性要求。团队可以保留原始事件等明确了分析需求后再决定对哪些数据进行聚合。用户在实际应用中非常认可这种资源效率“用户现在可以跨越更长的时间范围查询数据并实时分析原始数据而不必依赖预聚合格式。”Tekion“针对我们的应用场景ClickHouse 提供了市场上首屈一指的性价比。”Last9统一的遥测数据存储很多团队不想为每种信号维护独立的后端。ClickHouse 能够同时处理日志、链路追踪以及部分指标工作负载减少了需要学习和维护的系统数量。这种优势不仅限于可观测性ClickHouse 还常用于实时分析使得遥测数据、运维数据和业务数据能在同一个引擎中关联无需在应用层进行复杂的表连接。整合这些工作负载意味着基础架构更精简总体维护成本更低。Sierra 对此有着精准的概括他们将可观测性与数据分析视作同一种数据问题“如果我们不再把可观测性和数据分析看作两座孤岛而是统一视作一个数据问题并由 ClickHouse 驱动那将是一件非常棒的事。”SQL数据处理的通用语言SQL 的普及也是 ClickHouse 广泛应用的原因。作为一项开放标准SQL 拥有成熟的生态工程师极易上手AI 智能体也对其支持良好。ClickHouse 对 SQL 进行了扩展提供大量分析、统计和时间序列函数支持复杂的过滤、连接和多阶段聚合。相比之下针对单一信号优化的存储系统其查询语言往往难以表达这类丰富的分析流。“我们希望能对数据进行深入探索而不受限于过于简单的特定领域语言。”Tesla当然并非所有用户都需要精细控制。因此ClickStack 提供了查询构建器来隐藏复杂度能将 Lucene 风格的搜索 转换为优化的 SQL。当抽象无法满足需求时原生 SQL 图表与告警 允许用户直接调用引擎能力。同一个平台既能支持快速检索也能满足深度分析需求。拥抱开放生态ClickHouse 的开放生态让各团队能够放心使用。我们的理念是顺应用户习惯而非强制推行新流程。对于追求一体化体验的团队我们提供 ClickStack 开源技术栈对于 Grafana 用户我们通过 持续投入开发插件 提供支持。不断增加的合作伙伴集成让用户在不更换存储的前提下拥有更多选择。我们在 OpenTelemetry 上的投入也遵循同样的思路。这包括在 Collector Contrib 中对 clickhouse exporter 和 Datadog receiver 的改进。我们还参与了 Apache Arrow collector 项目以减少传输开销。对于标准 SDK 未涵盖的功能ClickStack 的 SDK 发行版补充了会话重放等能力。引入 ClickHouse 不应要求用户放弃现有的工具和插桩。友好的开源协议ClickHouse 的普及离不开 Apache 2.0 协议。这种宽松的协议允许团队在自己的基础设施中运行 ClickHouse并基于它构建商业产品。团队可以按自己的方式起步并保留对运行环境的完全控制。“开源版本的优势很明显上手快经过了充分测试且性能出色。”Anthropic“团队很看重 ClickHouse 的开源基因——‘我们的技术栈全都是开源的’。”Laminar如果运维压力过大团队可以选择 ClickHouse Cloud。其存算分离架构对大规模可观测场景极具吸引力数据只需写入一次共享存储无需为副本单独备份计算资源可独立扩容免去了“写入开销”。团队可以将写入与查询隔离确保写入峰值不影响排查。开源模式赋予了用户起步时的控制权而 ClickHouse Cloud 则提供了更省心的运行模式。那么指标数据表现如何读到这里你可能会问同样的逻辑是否适用于指标metrics坦白说答案是肯定的也是否定的。对于作为高基数事件字段存在的指标答案是肯定的。这就是 Charity 描述的模型将测量值与上下文保留在一起在查询时聚合。这保留了服务、客户、部署等维度而这些维度在传统存储中会导致序列爆炸。ClickHouse 将维度作为列处理增加基数并不会导致对象数量成倍增长。Prometheus 风格的指标则是另一回事。各团队已围绕其积累了多年的看板、告警和习惯。顺应现状意味着要支持这些现有工作流而不是要求所有人把 PromQL 转换成 SQL。目前这种支持已经存在但仍需完善。ClickHouse 24.8 引入了实验性的 TimeSeries 表引擎。ClickHouse 25.8 增加了对 PromQL 的初步支持而在 2026 年 6 月ClickStack 提供了实验性的 PromQL 数据源。虽然功能在扩大但模型仍可能变动。如果深度依赖 PromQL 语义目前还不应将 ClickHouse 视为 Prometheus 的直接替代品。视频链接https://www.youtube.com/watch?vAw94UjX0LQM完善 TimeSeries 引擎是目前的重点。要让 ClickHouse 成为全栈可观测性的默认层这可能是仅存的短板。它在日志、追踪和事件型指标方面的表现已获验证Prometheus 风格的指标则是我们正在攻克的堡垒。好产品不止于数据库ClickHouse 是优秀的引擎但最终的产品体验取决于多个环节。数据采集、Schema 设计、信号关联、可视化以及排查流程共同决定了系统能否帮工程师快速定位故障。Schema 选择不当会限制性能界面设计不佳会隐藏关键上下文。数据库提供底层能力产品则负责将能力合理组装。出于这种认知我们开发了 ClickStack该项目目前在开源社区获得了广泛应用。ClickStack 将我们的经验转化为 Schema 默认配置、查询生成逻辑和优化的排查流。我们在 ClickStack 默认配置上的性能投入 证明了这一点性能提升不仅源于数据库配置更源于对主键、文本索引、物化视图以及 UI 查询的协同调整。ClickHouse 提供了基础但仍需正确的决策才能发挥其潜力。智能体Agent重塑了交互模式随着 Agent 开始代替工程师排查故障、建立假设并查询数据可观测性的界面已不再局限于看板。目前我们内部 LogHouse 集群中超过 60% 的查询都由 Agent 发起。这改变了工作负载模式。为了解答一个问题Agent 可能会连续发起几十次查询去探索 Schema、验证结果并下钻分析中间没有人工操作时的停顿。查询延迟直接影响 Agent 的推理循环并发运行的 Agent 会引发突发查询。ClickHouse 在 Web 分析领域的积累使其天然适应低延迟与高并发。SQL 同样关键大模型在训练中吸收了大量 SQL 语料这为 Agent 提供了一种极具表现力的语言方便其进行复杂的过滤与关联。智能体也提升了数据保真度和留存率的价值。人类可以靠经验补全缺失信息而智能体只能基于检索到的上下文推理。巧妇难为无米之炊任何提示词都无法找回已被采样丢弃或过期的记录。全量遥测提供了更多调查路径长留存期则提供了区分异常所需的历史背景。ClickHouse 使保留这些上下文变得切实可行。快速的 SQL 引擎只是方案的一部分。模型可能会发出低效查询浪费资源。因此我们推出了 ClickStack MCP server。在评估中其针对可观测性的专属工具使调用次数减少了 27%结果一致性提升了 2.7 倍。以日志模式分析为例如果要求模型用正则规范化数百万条消息会引发大规模扫描。ClickStack 则通过采样匹配事件在 MCP 层利用算法聚类将模式返回给智能体。这样 Agent 获得了更优的调查组件分析循环更快也避免了不必要的计算。当预定义工具无法覆盖新问题时SQL 依然随时可用。尽管智能体将部分工作从看板转移到了自动化调查中但存储的重要性丝毫不减。Agent 对低延迟、高并发、灵活查询及全量数据的需求反而凸显了 ClickHouse 的核心优势也证明了它能支持这种演进中的交互方式。ClickHouse 的局限性当数据量、留存期、基数或成本压力凸显时ClickHouse 的优势才最关键。如果是规模较小的团队遥测数据量不大且更倾向于开箱即用的体验自行运维数据库可能并非最佳选择。过去我们会建议这些团队使用成品特别是当没人愿意设计 Schema 或编写 SQL 时。现在开源的 ClickStack 很大程度上弥补了这一差距。它提供了 OpenTelemetry 采集和熟悉的工作流用户无需从零搭建也不必为了日常排查去手写 SQL。不过用户仍需自行运维这套技术栈。Managed ClickStack 进一步减轻了负担同时保留了对采集器、Schema 和计算资源的控制权。在大规模场景下这种控制力能带来可观收益但其复杂度也超出了部分团队的需求。还有另一种合理的例外对于研发可观测性产品的公司如果其工作负载极其特殊或者认为存储技术是核心商业机密那么自研引擎是理性的。虽然成本高昂但在特定场景下对技术路线的绝对掌控至关重要。大多数用户既不打算开发数据库也不想参与该市场竞争。对于需要处理海量日志、追踪及指标数据的团队ClickHouse 依然是可靠的默认选择。那么ClickHouse 赢了吗我们不会宣称胜出——骄傲自满本身就是风险。但现有证据支持一个结论对于许多构建可观测系统的团队ClickHouse 已成为事实上的存储与查询引擎。在开发新产品时它理应成为首选后端。我们相信它能胜任大多数团队对遥测数据的处理需求。这一地位不仅归功于列式架构。全文索引弥补了检索空白对 PromQL 的支持正解决指标问题ClickStack 则将基础能力转化为完善的体验。相比宣称胜利持续推进产品落地才更重要。Severin Neumann 将可观测性形容为一场无限游戏。这场游戏没有终点数据量在增长留存要求在延长人类与智能体提出的问题也愈发复杂。今天的领先者明天仍需重新赢得地位。在存储与查询层ClickHouse 是一个出色的选择。但从整体来看可观测性从来不是单靠一个数据库就能打赢的仗。对我们而言一切工作才刚刚开始。关于我们ClickHouseclickhouse.com) 是面向 AI 时代打造的高性能实时分析数据库能够以极致性能处理海量数据分析任务。凭借高并发、低延迟和云原生架构ClickHouse 广泛应用于可观测性、数据仓库、实时分析及 AI 数据基础设施等场景。我们致力于帮助企业在公有云平台上构建安全、弹性且高性价比的实时分析与 AI 数据平台加速释放数据价值推动智能化创新与数字化转型。目前Trip.com、DiDi、Meta、Sony、Netflix、Deutsche Bank、Sierra、Cloudflare 等全球领先企业均在使用 ClickHouse 支撑其关键业务和数据分析平台。 
长河君 · 2026/10/21 2:21:23 · 阅读 1.2k ClickHouse 在可观测性存储领域的应用现状与挑战
本文字数9383估计阅读时间24分钟作者Mike Shi编者按本文译自 ClickHouse 原博客链接点文末-查看原文。 原文围绕「探讨 ClickHouse 作为可观测性底层引擎的优势与局限」展开。存储引擎的性能优势为可观测性奠定了基础但优秀的架构设计与产品化能力依然是不可或缺的关键环节。2026 年 7 月Mat Duggan 和 Charity Majors 分别撰文指出“ClickHouse 正在赢得可观测性之战”。这并非我们的授意读到这些文章我们深感荣幸也对这一观点的广泛传播感到惊喜。我们固然感激这些认可但同时也想聊聊为什么两位资深从业者兼行业领袖会基于生产环境的观察得出这一结论。ClickHouse 究竟在可观测性技术栈的哪个环节占据优势为什么它会成为主流选择哪些场景它并不适用为了保持竞争力我们还需要在哪些方面改进ClickHouse 正在帮助越来越多的团队实现降本增效这令我们倍感欣慰。不过借用 Lewis Hamilton 的话我是个铁杆 F1 车迷——“我们仍有未竟之事”。“赢得”到底意味着什么Mat 和 Charity 最终都将目光聚焦在存储与查询层这界定了“赢”的范畴因为这只代表了可观测性问题的其中一面。数据采集、模式设计、关联、可视化、告警和排查流程以及围绕这些环节的体验仍然需要构建。一个优秀的引擎奠定了基础但它无法代替你做出产品决策也不能决定你应当如何处理和理解遥测数据。正如 Charity 所言“再好的存储引擎也无法拯救糟糕的架构”在存储层ClickHouse 已成为许多自建可观测性系统的工程团队的默认选择。Netflix、Anthropic 和 OpenAI 的团队均使用它来大规模存储和查询遥测数据尤其是日志和追踪。“ClickHouse 在 Claude 4 的研发与发布中发挥了关键作用。它运行稳定查询极快且成本可控。在打造最先进语言模型的过程中ClickHouse 创造了巨大价值。” Anthropic“ClickHouse 里的数据比其他任何地方都好用。没有其他系统能让你如此灵活地拆解分析数据、提出深度问题并在合理时间内获得答案。目前市面上没有任何产品能与 ClickHouse 抗衡。” Tesla“许多同行都在完全相同的场景可观测性中使用 ClickHouse。它久经沙场是这项工作的理想工具。” OpenAI同样许多可观测性 SaaS 公司也在 ClickHouse 之上构建产品。他们将 ClickHouse 作为底层引擎同时保留对界面、工作流和产品决策的掌控。这些产品服务于不同的用户设计理念也不尽相同。有些产品围绕信息丰富的宽事件wide events展开另一些则保留了传统体验依然按日志、指标和链路追踪来组织数据。它们的共同点在于都利用了 ClickHouse 的列式架构这种架构天生契合遥测数据的形态与访问模式。我们认同 Charity 的观点与分散的信号相比以宽事件形式存在的可观测性数据往往更实用。将上下文集中在一起可以保留数据间的关联避免在不同格式间重复记录也能让团队根据需求灵活生成视图。不过许多团队已经围绕日志、追踪和指标建立了一套完整的插桩、模式与工作流他们不应为了享受 ClickHouse 的优势而被迫重构现有的遥测体系。ClickHouse 同样能出色地处理常规日志与链路追踪数据。生产环境的日志通常是结构化、宽字段且高基数的——本质上宽事件就是带有指标的结构化日志。即使是格式自由的文本消息也包含大量重复的词元和模板只要通过排序将相似内容聚集就能实现极高的压缩率。链路追踪的跨度trace spans本身就类似于宽事件它们都是包含时间戳、耗时、标识符、属性和状态的结构化记录。ClickStack 也采取了同样务实的策略。它整合了 ClickHouse、OpenTelemetry Collector 和 ClickStack UI在全面支持宽事件的同时也能接收既有的日志、链路追踪和指标数据。用户既能保留熟悉的工作流又不会丧失底层数据的关联与查询能力。各种产品在信号、模式和工作流的设计上可能各有千秋但在存储层的选择上却殊途同归。无论采用哪种模型ClickHouse 都已证明自己是卓越的存储和查询引擎。因此如果“赢”意味着成为构建可观测系统时的默认存储与查询层那么答案或许是肯定的。为什么 ClickHouse 如此适合作为存储层ClickHouse 作为一款列式数据库天然契合可观测性场景。无论是宽事件、日志记录还是追踪 span虽然设计理念不同但都具有典型的分析型特征单条记录字段多、数据规模庞大且查询时通常只需检索或聚合极少数关键字段。在行式数据库中同一条记录的各个值存储在一起。而列式数据库则将相同字段的值集中存储时间戳与时间戳相邻服务名与服务名相邻。这种布局非常符合可观测查询的需求因为这类查询通常只需在海量事件中扫描特定的几个字段。这一结论并非 ClickHouse 独有。Honeycomb 早就意识到这一点并围绕宽事件构建了自研的分布式列式存储 Retriever。Datadog 在 2022 年推出用于处理日志和事件的列式存储 Husky 时也得出了类似的架构结论。尽管产品模型不同——Honeycomb 主张上下文集中Datadog 倾向于传统体验——但在存储层两者都选择了列式结构。那么为什么列式架构如此契合可观测性数据磁盘层面的优势立竿见影。在每个数据片段内行按排序键排列列则单独存储。如果排序键匹配主要的访问模式相似的值就会聚集在一起。在通用压缩之前可以通过字典、增量和游程编码大幅缩减体积通用压缩也能从连续的相似值中获益。这些压缩优势通常是 ClickHouse 用户最先感知的特点“ClickHouse 的压缩效果令人惊叹。有些列的压缩比达到了 10 倍甚至 20 倍个别情况下甚至高达 50 倍。”Character.AI“我们仅用 20 个 CPU 核心就能实现每秒 300 万行的写入速度且在未加调优的情况下达到了 1:8 的压缩比。”Shopee磁盘上的数据布局也契合工程师的实际查询习惯。许多图表依赖聚合查询例如按时间统计请求量或计算平均延迟。这些查询可能扫描数十亿条记录但只会读取时间戳、聚合值等极少数列。ClickHouse 可以只读取所需的列从而消除不必要的 I/O 开销。其稀疏主索引能直接跳过不符合条件的数据颗粒跳数索引则进一步支持了多样化的访问模式。“约 80% 的查询仅涉及过去两天的数据因此这部分数据会被保留在磁盘上以便快速访问。”OpenAI“ClickHouse 能够基于时间跳过数据这让表的大小变得不再关键因为它能精准定位所需信息。”BENOCS当数据进入 CPU 处理阶段列式布局会继续发挥威力。ClickHouse 以数据块为单位处理列值而非逐行解析。在执行聚合时它可以对一批连续值执行相同操作。这提升了缓存局部性降低了单行处理开销并能充分利用处理器支持的 SIMD 指令。多个数据块也能跨 CPU 核心并行处理。这种并行能力延伸到了整个集群。分布式查询会被发送至存储数据的分片各节点同步扫描并聚合本地数据。这些部分结果随后汇总至发起节点。因此增加节点不仅能扩展存储还能线性提升查询算力。Parallel Replica 功能将查询分发至多个节点并行处理……使查询速度提升了 2.5 倍。Poizon大量使用 SIMD 指令确保数据结构对 CPU 缓存友好并采用专用算法来处理海量数据。RunRevealMat 的文章强调了 ClickHouse 的另一项特质扩容模式。他的观点是每天处理 10 TB 数据的 ClickHouse与每天处理 1 TB 时相比无非是多了几个分片而已。早期部署可以通过升级配置实现垂直扩展直到负载需要时再引入分片。随后在沿用相同引擎与模型的前提下通过增加分片实现水平扩展。虽然增加分片仍需容量规划和数据平衡但在整个增长过程中系统的核心架构始终保持一致。其他大规模运维 ClickHouse 的团队也提到了这种可预测性ClickHouse 是云原生的专为水平扩展而设计。这意味着在扩展写入与查询能力时运维成本相对较低。OpenAI聚合是常见的查询模式但在排查问题时工程师还需要搜索错误日志、按属性筛选并按图索骥寻找线索。告警和看板无法预见所有问题这种高度依赖搜索的工作流正是 Elasticsearch 成为主流日志后端的原因。ClickHouse 本就可以利用高度并行的字符串扫描执行文本搜索并借助布隆过滤器跳数索引排除无关数据。布隆过滤器确实有用但它是基于概率的且在颗粒级别生效可能产生误报并需要精细调优当词项分布过广时其过滤效果会大幅下降。在 2026 年 3 月全文搜索在 ClickHouse 中正式发布。其文本索引采用倒排索引将词元映射至行号。ClickHouse 无需扫描所有字符串即可确定候选行并在同一次查询中完成过滤和聚合。虽然这类索引会占用更多空间并增加写入开销但它提供了精确的行级查找并支持多词元与短语搜索。我们在 ClickStack 中应用这些索引来加速日志搜索与属性过滤。由于索引本身可搜索ClickStack 还可以通过前缀查找实现自动补全而无需扫描底层遥测列。倒排索引负责缩小范围后续分析则交给高效的列式引擎。用户反馈表明文本索引显著提升了搜索性能“ClickHouse 的全文搜索改变了我们的日志检索方式。过去使用线性扫描进行多词项搜索需要 30 到 45 秒。得益于倒排索引相同的查询现在只需约 400 毫秒。”Icite高基数在列式模型中的表现截然不同。在 Prometheus 等系统中标签的每种唯一组合都会生成独立的时间序列带来额外的元数据和索引开销。而 ClickHouse 只是直接写入新行。诸如TraceId或user_id等字段可能包含数百万个值但其成本仅局限于该列本身。虽然这类字段的压缩率可能稍低但绝不会影响其他字段的压缩效果。过滤操作取决于读取的列而非独立值的总数。对高基数字段使用选择性过滤能减少扫描量尤其在排序键支持该模式时更为明显。当然高基数仍有开销按数百万个值分组需要构建大量聚合状态会消耗更多内存。但在实际应用中用户很少需要同时展示数百万个序列。在我们关于 ClickHouse 与 Prometheus 基数的对比中探讨了这些差异。最终用户不再谈“基数”色变“我们不再对基数感到恐惧……我们能把所有数据集中在一处用来解答所有问题。”Sierra不仅仅在于列显然列式架构是 ClickHouse 胜出的核心原因之一。但单靠结构不足以解释为何如此多的团队和供应商会选择它。极致的性能追求ClickHouse 处理遥测数据的出色表现很大程度上归功于其架构。数据压缩减少了存储与读取量而列式 I/O、向量化执行以及并行处理则降低了查询负载。该项目还形成了一种执着于性能与资源效率的文化。Andy Pavlo 在 CMU 讲座中准确概括了这一关注点视频链接https://www.youtube.com/watch?vVy2t_wZx4Ist3579sClickHouse 创始人 Alexey Milovidov 从项目内部阐述了同样的工程理念视频链接https://www.youtube.com/watch?vCAS2otEoerM在可观测性领域这种优化效果会积少成多。当数据达到一定规模每一字节的冗余读取和每一周期的 CPU 浪费都会转化为运营成本。这种效率也重塑了数据保留的成本模型。ClickHouse 原生支持对象存储和存算分离能以极低成本保留庞大数据集。结合压缩与选择性读取团队可以将全量、未经采样的遥测数据保留更久。这样一来采样和上卷就成了优化手段而非受制于成本的硬性要求。团队可以保留原始事件等明确了分析需求后再决定对哪些数据进行聚合。用户在实际应用中非常认可这种资源效率“用户现在可以跨越更长的时间范围查询数据并实时分析原始数据而不必依赖预聚合格式。”Tekion“针对我们的应用场景ClickHouse 提供了市场上首屈一指的性价比。”Last9统一的遥测数据存储很多团队不想为每种信号维护独立的后端。ClickHouse 能够同时处理日志、链路追踪以及部分指标工作负载减少了需要学习和维护的系统数量。这种优势不仅限于可观测性ClickHouse 还常用于实时分析使得遥测数据、运维数据和业务数据能在同一个引擎中关联无需在应用层进行复杂的表连接。整合这些工作负载意味着基础架构更精简总体维护成本更低。Sierra 对此有着精准的概括他们将可观测性与数据分析视作同一种数据问题“如果我们不再把可观测性和数据分析看作两座孤岛而是统一视作一个数据问题并由 ClickHouse 驱动那将是一件非常棒的事。”SQL数据处理的通用语言SQL 的普及也是 ClickHouse 广泛应用的原因。作为一项开放标准SQL 拥有成熟的生态工程师极易上手AI 智能体也对其支持良好。ClickHouse 对 SQL 进行了扩展提供大量分析、统计和时间序列函数支持复杂的过滤、连接和多阶段聚合。相比之下针对单一信号优化的存储系统其查询语言往往难以表达这类丰富的分析流。“我们希望能对数据进行深入探索而不受限于过于简单的特定领域语言。”Tesla当然并非所有用户都需要精细控制。因此ClickStack 提供了查询构建器来隐藏复杂度能将 Lucene 风格的搜索 转换为优化的 SQL。当抽象无法满足需求时原生 SQL 图表与告警 允许用户直接调用引擎能力。同一个平台既能支持快速检索也能满足深度分析需求。拥抱开放生态ClickHouse 的开放生态让各团队能够放心使用。我们的理念是顺应用户习惯而非强制推行新流程。对于追求一体化体验的团队我们提供 ClickStack 开源技术栈对于 Grafana 用户我们通过 持续投入开发插件 提供支持。不断增加的合作伙伴集成让用户在不更换存储的前提下拥有更多选择。我们在 OpenTelemetry 上的投入也遵循同样的思路。这包括在 Collector Contrib 中对 clickhouse exporter 和 Datadog receiver 的改进。我们还参与了 Apache Arrow collector 项目以减少传输开销。对于标准 SDK 未涵盖的功能ClickStack 的 SDK 发行版补充了会话重放等能力。引入 ClickHouse 不应要求用户放弃现有的工具和插桩。友好的开源协议ClickHouse 的普及离不开 Apache 2.0 协议。这种宽松的协议允许团队在自己的基础设施中运行 ClickHouse并基于它构建商业产品。团队可以按自己的方式起步并保留对运行环境的完全控制。“开源版本的优势很明显上手快经过了充分测试且性能出色。”Anthropic“团队很看重 ClickHouse 的开源基因——‘我们的技术栈全都是开源的’。”Laminar如果运维压力过大团队可以选择 ClickHouse Cloud。其存算分离架构对大规模可观测场景极具吸引力数据只需写入一次共享存储无需为副本单独备份计算资源可独立扩容免去了“写入开销”。团队可以将写入与查询隔离确保写入峰值不影响排查。开源模式赋予了用户起步时的控制权而 ClickHouse Cloud 则提供了更省心的运行模式。那么指标数据表现如何读到这里你可能会问同样的逻辑是否适用于指标metrics坦白说答案是肯定的也是否定的。对于作为高基数事件字段存在的指标答案是肯定的。这就是 Charity 描述的模型将测量值与上下文保留在一起在查询时聚合。这保留了服务、客户、部署等维度而这些维度在传统存储中会导致序列爆炸。ClickHouse 将维度作为列处理增加基数并不会导致对象数量成倍增长。Prometheus 风格的指标则是另一回事。各团队已围绕其积累了多年的看板、告警和习惯。顺应现状意味着要支持这些现有工作流而不是要求所有人把 PromQL 转换成 SQL。目前这种支持已经存在但仍需完善。ClickHouse 24.8 引入了实验性的 TimeSeries 表引擎。ClickHouse 25.8 增加了对 PromQL 的初步支持而在 2026 年 6 月ClickStack 提供了实验性的 PromQL 数据源。虽然功能在扩大但模型仍可能变动。如果深度依赖 PromQL 语义目前还不应将 ClickHouse 视为 Prometheus 的直接替代品。视频链接https://www.youtube.com/watch?vAw94UjX0LQM完善 TimeSeries 引擎是目前的重点。要让 ClickHouse 成为全栈可观测性的默认层这可能是仅存的短板。它在日志、追踪和事件型指标方面的表现已获验证Prometheus 风格的指标则是我们正在攻克的堡垒。好产品不止于数据库ClickHouse 是优秀的引擎但最终的产品体验取决于多个环节。数据采集、Schema 设计、信号关联、可视化以及排查流程共同决定了系统能否帮工程师快速定位故障。Schema 选择不当会限制性能界面设计不佳会隐藏关键上下文。数据库提供底层能力产品则负责将能力合理组装。出于这种认知我们开发了 ClickStack该项目目前在开源社区获得了广泛应用。ClickStack 将我们的经验转化为 Schema 默认配置、查询生成逻辑和优化的排查流。我们在 ClickStack 默认配置上的性能投入 证明了这一点性能提升不仅源于数据库配置更源于对主键、文本索引、物化视图以及 UI 查询的协同调整。ClickHouse 提供了基础但仍需正确的决策才能发挥其潜力。智能体Agent重塑了交互模式随着 Agent 开始代替工程师排查故障、建立假设并查询数据可观测性的界面已不再局限于看板。目前我们内部 LogHouse 集群中超过 60% 的查询都由 Agent 发起。这改变了工作负载模式。为了解答一个问题Agent 可能会连续发起几十次查询去探索 Schema、验证结果并下钻分析中间没有人工操作时的停顿。查询延迟直接影响 Agent 的推理循环并发运行的 Agent 会引发突发查询。ClickHouse 在 Web 分析领域的积累使其天然适应低延迟与高并发。SQL 同样关键大模型在训练中吸收了大量 SQL 语料这为 Agent 提供了一种极具表现力的语言方便其进行复杂的过滤与关联。智能体也提升了数据保真度和留存率的价值。人类可以靠经验补全缺失信息而智能体只能基于检索到的上下文推理。巧妇难为无米之炊任何提示词都无法找回已被采样丢弃或过期的记录。全量遥测提供了更多调查路径长留存期则提供了区分异常所需的历史背景。ClickHouse 使保留这些上下文变得切实可行。快速的 SQL 引擎只是方案的一部分。模型可能会发出低效查询浪费资源。因此我们推出了 ClickStack MCP server。在评估中其针对可观测性的专属工具使调用次数减少了 27%结果一致性提升了 2.7 倍。以日志模式分析为例如果要求模型用正则规范化数百万条消息会引发大规模扫描。ClickStack 则通过采样匹配事件在 MCP 层利用算法聚类将模式返回给智能体。这样 Agent 获得了更优的调查组件分析循环更快也避免了不必要的计算。当预定义工具无法覆盖新问题时SQL 依然随时可用。尽管智能体将部分工作从看板转移到了自动化调查中但存储的重要性丝毫不减。Agent 对低延迟、高并发、灵活查询及全量数据的需求反而凸显了 ClickHouse 的核心优势也证明了它能支持这种演进中的交互方式。ClickHouse 的局限性当数据量、留存期、基数或成本压力凸显时ClickHouse 的优势才最关键。如果是规模较小的团队遥测数据量不大且更倾向于开箱即用的体验自行运维数据库可能并非最佳选择。过去我们会建议这些团队使用成品特别是当没人愿意设计 Schema 或编写 SQL 时。现在开源的 ClickStack 很大程度上弥补了这一差距。它提供了 OpenTelemetry 采集和熟悉的工作流用户无需从零搭建也不必为了日常排查去手写 SQL。不过用户仍需自行运维这套技术栈。Managed ClickStack 进一步减轻了负担同时保留了对采集器、Schema 和计算资源的控制权。在大规模场景下这种控制力能带来可观收益但其复杂度也超出了部分团队的需求。还有另一种合理的例外对于研发可观测性产品的公司如果其工作负载极其特殊或者认为存储技术是核心商业机密那么自研引擎是理性的。虽然成本高昂但在特定场景下对技术路线的绝对掌控至关重要。大多数用户既不打算开发数据库也不想参与该市场竞争。对于需要处理海量日志、追踪及指标数据的团队ClickHouse 依然是可靠的默认选择。那么ClickHouse 赢了吗我们不会宣称胜出——骄傲自满本身就是风险。但现有证据支持一个结论对于许多构建可观测系统的团队ClickHouse 已成为事实上的存储与查询引擎。在开发新产品时它理应成为首选后端。我们相信它能胜任大多数团队对遥测数据的处理需求。这一地位不仅归功于列式架构。全文索引弥补了检索空白对 PromQL 的支持正解决指标问题ClickStack 则将基础能力转化为完善的体验。相比宣称胜利持续推进产品落地才更重要。Severin Neumann 将可观测性形容为一场无限游戏。这场游戏没有终点数据量在增长留存要求在延长人类与智能体提出的问题也愈发复杂。今天的领先者明天仍需重新赢得地位。在存储与查询层ClickHouse 是一个出色的选择。但从整体来看可观测性从来不是单靠一个数据库就能打赢的仗。对我们而言一切工作才刚刚开始。关于我们ClickHouseclickhouse.com) 是面向 AI 时代打造的高性能实时分析数据库能够以极致性能处理海量数据分析任务。凭借高并发、低延迟和云原生架构ClickHouse 广泛应用于可观测性、数据仓库、实时分析及 AI 数据基础设施等场景。我们致力于帮助企业在公有云平台上构建安全、弹性且高性价比的实时分析与 AI 数据平台加速释放数据价值推动智能化创新与数字化转型。目前Trip.com、DiDi、Meta、Sony、Netflix、Deutsche Bank、Sierra、Cloudflare 等全球领先企业均在使用 ClickHouse 支撑其关键业务和数据分析平台。