从发布到爆发：ClickStack 半年进化史，ClickHouse 可观测性全面起飞

本文字数：7666；估计阅读时间：20 分钟

作者：ClickStack team

本文在公众号【ClickHouseInc】首发

介绍 

很难相信 ClickStack 是在去年五月底才正式发布的(https://clickhouse.com/blog/clickstack-a-high-performance-oss-observability-stack-on-clickhouse)。从那以后，产品演进的速度更像是走过了完整的一年，而不是短短 7 个月。在这段时间里，ClickStack 先后引入了原生 JSON 支持、仪表盘的导入与导出、对物化视图 (Materialized Views) 的支持，在各个层面都实现了性能提升，构建了完整的告警系统，并推出了 Service Maps 等重要功能(https://clickhouse.com/#november:-what%E2%80%99s-new---service-maps-and-attribute-highlighting)。

除了按月发布新版本之外，我们还将 ClickStack 引入了 ClickHouse Cloud(https://clickhouse.com/blog/announcing-clickstack-in-clickhouse-cloud)，这是迈向“可观测性与分析并存”的统一环境的第一步。而这还远未结束。到了 2026 年，我们将把能力边界再次推高，带来更深度的 Cloud 集成、完全托管的 ClickStack 体验、AI 驱动的笔记本、异常检测能力、开箱即用的集成方案，以及更多经过深思熟虑的默认配置，让团队几乎不需要投入额外运维成本，就能轻松采用可观测性体系。

本文将回顾我们从五月到十二月走过的这段历程：随着整个技术栈不断成熟，每个月陆续推出的关键功能，让 ClickStack 成长为一个远比最初发布时强大得多的系统。这里列出的内容并不试图涵盖全部，而是聚焦于我们最引以为傲的一些特性。最后，我们还会展望未来，分享接下来重点投入的方向，以及用户在 2026 年可以从 ClickStack 中期待哪些变化。

五月：ClickStack 正式发布

ClickStack 的诞生，源于我们多年来反复观察到的一个明显趋势。像 Netflix 和 Anthropic 这样的大规模团队，早已将 ClickHouse 作为其可观测性系统的基础，充分利用它在存储和查询高基数、上下文丰富的宽事件方面的优势。但他们始终缺少一个有清晰设计理念、真正端到端的整体体验。HyperDX 改变了这一局面。2024 年末，该项目将下一代 UI 开源，为我们带来了一个专门围绕 ClickHouse 优势打造的现代工作流层：极速搜索、快速聚合，以及一个既能生成高效查询、又不掩盖 SQL 强大能力的 UI。将 HyperDX 与 ClickHouse 结合在一起，让我们有机会补齐生态中长期缺失的一块拼图：一个完整的开源可观测性技术栈，全面拥抱 OpenTelemetry，在同一平台中统一提供日志、指标、追踪和会话回放。

这一愿景在五月随着 ClickStack 的发布真正落地。首个版本集成了一个具有明确设计取向的 OpenTelemetry 收集器，以及通过 HyperDX 提供的 ClickHouse 原生 UI。它提供了一套即开即用的工作流，覆盖数据摄取、搜索、仪表盘和问题调试，同时也为高级用户保留了对 SQL 的完全掌控权，以及根据需要自定义数据模式的灵活性。最初只是对成熟组件的一次整合，很快演变为一个完整而统一的产品，其核心理念非常明确：可观测性本质上是一个数据问题，而列式存储配合为其量身打造的体验，正是解决这一问题的最佳方式。

更重要的是，ClickStack 让此前只有大型工程团队才能享受到的能力，变得人人可及。过去，ClickHouse 在可观测性场景下的全部潜力，只属于那些有资源自行构建数据摄取链路、模式设计和 UI 层的组织。开源的 ClickStack 打破了这一门槛。它提供了一种从设计之初就高度协同的统一体验，让 UI、数据模式和引擎自然配合，在充分释放 ClickHouse 性能的同时，保持开放、易用，并且几乎无需额外成本即可上手。

七月：原生 JSON 支持到来 

在正式发布仅仅数周之后，七月就迎来了原生 JSON 类型支持的落地(https://clickhouse.com/blog/whats-new-clickstack-july-2025#clickstack-supports-the-json-type-for-faster-queries)。JSON 在 ClickHouse 内部已经经历了多个版本周期的持续演进，逐步成熟为一种高性能、具备列感知能力的数据格式，在保留结构和类型信息的同时，还能够实现子列裁剪。到七月时，这一特性已经可以支撑生产级工作负载，而 ClickStack 也成为最早在大规模场景中采用它的产品之一。从基于 Map 的属性存储切换到原生 JSON，对于某些工作负载而言可以带来非常显著的收益，例如显著减少 I/O 开销，以及在无需扁平化或手动预处理的情况下，直接处理深度嵌套的可观测性数据。

在 ClickStack 的早期阶段引入 JSON，意味着更快的查询性能、更具表达力的数据模式，以及一种更加贴合现代 OpenTelemetry 数据形态的摄取模型。但这还只是开始。我们仍在持续探索 JSON 适用的最佳场景，研究如何将它与不同的索引策略组合使用，以及它在高吞吐量可观测性工作负载下的行为表现。随着最佳实践的不断完善，以及对 JSON 在大规模实时、高基数遥测数据场景下潜力的深入挖掘，未来几个月内我们还会带来更多指导和基准测试结果。

八月：ClickStack 走进 ClickHouse Cloud

八月是 ClickStack 发展的一个重要里程碑，基于 HyperDX 的 UI 首次直接集成进 ClickHouse Cloud(https://clickhouse.com/blog/announcing-clickstack-in-clickhouse-cloud)。这不仅仅是为了使用上的方便，更意味着 ClickStack 从一个自托管的开源方案，正式升级为一个与 Cloud 深度集成的一等产品形态。用户第一次可以在无需部署任何基础设施、无需单独配置认证、也几乎没有额外运维负担的情况下启动 ClickStack，并立即将可观测性工作流与他们已经用于分析的同一个实时数仓结合起来。这一能力让 ClickStack 覆盖了三类关键用户：已经在 Cloud 上运行 ClickStack、现在可以减少一个组件运维负担的现有用户；正在从专有可观测性厂商迁移大规模工作负载、需要一种兼顾成本与性能替代方案的企业；以及已经使用 ClickHouse Cloud 进行分析的应用团队，他们如今只需一次点击，就能为系统引入可观测性能力。

这次 Cloud 集成也让我们更宏大的愿景真正落地——在同一个系统中实现可观测性与分析的统一。借助 Cloud 中的 ClickStack，团队不再将遥测数据视为一个独立孤立的系统，而是可以直接将追踪、日志和指标与应用数据、产品事件以及运营 KPI 进行关联分析。这使得可观测性从单纯的事后排查工具，演进为一个高度关联的分析型工作流，在其中，业务影响、性能回退以及用户行为都能够通过同一个引擎被全面理解。这一切的核心理念，正是我们在过去一年中反复强调的原则：

我们相信，可观测性只是另一种数据问题。而它理应与业务关键型分析数据存放在同一个数据库中。借助 ClickHouse Cloud，你可以同时获得实时数仓的性能、对象存储的规模与灵活性，以及现代可观测性 UI 带来的可见性——所有能力，尽在同一个技术栈之中。

自从 ClickStack 在 Cloud 中上线以来，我们持续稳步地引导客户使用，并收集了当今一些在可观测性场景下大规模使用 ClickHouse 的组织的反馈。其中包括 Anthropic 和 character.AI 这样高度扩展的团队，他们的实际使用经验深刻影响了 UI 在高数据量、高基数工作负载下的表现方式。这些真实场景不断推动产品向前演进，从性能优化到工作流简化，几乎每一个方面都受到了影响。八月不仅仅是一次功能发布，更是一个全新阶段的开始——ClickStack 成为了 ClickHouse Cloud 的原生组成部分，也成为我们将在 2026 年持续构建统一可观测性体验的基石。

与此同时，我们还引入了更多面向大规模场景的性能优化，并对 ClickHouse 新推出的倒排索引 (inverted index) 提供了早期支持，旨在提升对日志正文的全文搜索能力。尽管这一功能目前仍处于实验阶段，但我们正在积极评估其效果，并且它也将在我们迈入 2026 年 1 月之后继续成为重点投入方向。

九月：仪表盘导入/导出、自定义收集器配置与更智能的查询 

九月为 ClickStack 带来了最具影响力的早期体验改进之一：仪表盘导入与导出。这一功能让团队能够在内部共享仪表盘、将其与代码一起进行版本管理，并在新服务或新团队接入时，快速复用已经验证过的视图，从而更快地获得价值。更重要的是，它为构建一个由社区推动的共享仪表盘生态奠定了基础。整个一年里，我们持续完善文档，提供适用于常见集成和入门场景的开箱即用仪表盘，而导入/导出能力也将让用户更容易把自己的实践模式回馈给更广泛的 ClickStack 社区。我们的期望很简单：仪表盘应该像支撑它们的 SQL 一样，具备良好的可移植性和可组合性。

九月还引入了一项扩展数据摄取工作流的关键能力：自定义 OpenTelemetry 收集器配置。用户现在可以在 ClickStack 默认发行版之上叠加自己的流水线和接收器，这在从 Kafka 等来源消费日志、直接采集主机文件，或加入自定义处理器时尤为重要。这一变化不仅让更复杂的生产部署成为可能，也支撑了我们持续发布的更丰富的集成指南，使 ClickStack 能够更轻松地适配各种运行环境。

在摄取能力增强的同时，查询性能也取得了显著进展。我们为搜索引入了时间窗口分块机制，使 ClickStack 能够优先读取最近的数据，并在获取到足够结果后提前结束查询。这一优化后来成为多项性能提升的基础，包括更快的图表渲染和更灵敏的直方图查询。它清楚地展示了九月的一系列渐进式改进，是如何最终影响并塑造整个技术栈性能表现的。

最后，九月还在 UI 中加入了对自定义聚合的支持，让用户可以直接调用 ClickHouse 聚合引擎的全部能力。

十月：告警、灵活的 Event Deltas 与仪表盘过滤器 

十月通过在 ClickHouse Cloud 中引入基于阈值的告警功能，标志着 ClickStack 的又一个重要里程碑。用户现在可以直接从搜索结果或图表中创建告警，用于监控延迟、错误率、吞吐量，或任何通过 SQL 派生出来的指标。初始版本还内置了对 PagerDuty 和 Incident.io 的集成，并提供通用的 webhook 以支持自定义流水线。更关键的是，这为真正的大规模告警场景打下了架构基础。借助 ClickHouse Cloud 的读写分离与计算池模型，告警工作负载可以运行在专用计算资源上，从而确保数据摄取和分析查询互不干扰。这为成千上万个告警稳定、独立地运行铺平了道路，后续更新还将引入异常检测逻辑，并提供新的开箱即用目标。

十月的另一大亮点是 Event Deltas 的持续演进。Event Deltas 已经成为 ClickStack 最具代表性的功能之一。它的核心能力在于，允许用户选取一组较慢的 span，与一个基线总体进行对比，并自动找出与性能回退最相关的属性和值。这在查询阶段提供了一种轻量级的异常检测方式，其基础是真实的数据分布，而不是启发式规则。在十月，我们让 Event Deltas 变得完全可配置。用户不再局限于基于 span 持续时间进行分析，而是可以在任何数值字段上构建 delta，例如数据库延迟或队列等待时间。这极大地提升了灵活性，也解锁了全新的问题排查工作流。

我们还引入了仪表盘过滤器，这项可用性改进几乎立刻得到了用户的认可——此前，用户需要手动输入过滤条件。一些可观测性工具要求预先定义变量才能实现过滤，从而带来额外的配置负担。在 ClickStack 中，仪表盘过滤只需选择一个列即可完成，UI 会自动判断合适的过滤类型并以内联方式呈现。随后，过滤条件会自动应用到仪表盘中所有使用相同数据源的可视化组件上。用户可以自然地对仪表盘进行切分和细化，而无需额外配置或模板工程。从多个角度来看，十月很好地体现了 ClickStack 的产品理念：功能强大、工作流简单，整体体验持续变得更快、更直观。

十一月：新功能 —— Service Maps 与属性高亮

十一月带来了 ClickStack 中最受期待的功能之一：Service Maps，目前以 beta 形式提供。Service Maps 将追踪数据转化为服务之间交互关系的可视化图景，使团队能够快速理解流量路径、服务依赖以及故障模式。更重要的是，ClickStack 不仅提供了独立的 Service Maps 视图，还将其融入到具体上下文中。当用户查看单条 trace 时，一个聚焦的服务地图会与瀑布图并排显示，清晰呈现该请求在系统中的实际路径。尽管当前的 beta 版本已经能够提供有价值的洞察，我们仍计划在 2026 年初进一步提升其性能和可扩展性，包括探索 ClickHouse 内部能力，例如可刷新的物化视图，以支持高吞吐量、实时的图结构构建。

我们还引入了可配置的属性高亮功能，这是一项轻量但非常实用的增强，适用于日志和追踪场景。用户可以指定在查看 span 或日志条目时需要自动展示的字段，这些字段会立即显示在侧边栏或 trace 头部，使关键标识符、标签或元数据无需在完整属性中翻找即可一目了然。被高亮的属性还可以定义自定义搜索表达式，并支持自动识别的可点击链接，帮助团队构建更具针对性、贴合自身领域结构的调试工作流。

最后，我们加入了折线图对比功能，这是一项体量很小却迅速成为社区最受欢迎特性的改进。只需切换一次，用户就可以在任意时间序列图表中叠加上一周期的数据，使性能回退或优化效果无需创建额外仪表盘或手动计算偏移即可立即显现。这一简单的增强显著提升了探索式分析的效率，也再次体现了我们专注于打造快速、直观工具的方向，持续缩短从数据到理解之间的距离。

十二月：物化视图解锁新的可扩展性边界 

十二月以迄今为止最大的一次性能跃升为这一年画上了句号——ClickStack 中完全集成的物化视图 (Materialized Views) 正式落地。此前，ClickStack 虽然允许用户对单个图表进行物化，但这种方式存在明显局限：一旦过滤条件或分组方式发生变化，查询就会回退到底层表，导致性能提升并不稳定。新的设计彻底改变了这一现状。用户现在可以直接在 ClickHouse 中创建增量物化视图 (Incremental Materialized Views)，将其注册为数据源的一部分，并由 ClickStack 的查询层在执行时自动选择最合适的视图。系统能够理解每个视图的时间粒度、可用维度以及对外暴露的指标，并在查询阶段借助 ClickHouse 的 EXPLAIN ESTIMATE，判断哪个候选视图需要扫描的 granule 数量最少。由此一来，HyperDX 中的任何查询——无论是搜索、仪表盘、直方图视图还是图表——都可以在无需用户额外操作的情况下实现大规模性能加速。

这不仅仅是一次性能优化，而是为 ClickStack 打开了一个全新的可扩展性层级。增量物化视图会随着数据写入仅计算发生变化的部分，将少量计算前移到摄取阶段，同时显著降低下游分析工作流的查询复杂度。因此，即使在数据规模极大的情况下，系统依然能够保持接近实时的响应体验。目前该功能仍处于 beta 阶段，我们计划在 2026 年初持续打磨，包括引入更智能的视图选择策略，以及未来根据用户访问模式自动生成物化视图的能力。以物化视图作为年度收官，为整个技术栈奠定了一类全新的性能优化基础，也成为 ClickStack 持续通过充分释放 ClickHouse 引擎能力而不断演进的最清晰例证之一。

展望 2026 

迈入 2026 年，我们的核心目标是让 ClickStack 成为在大规模场景下运行 OpenTelemetry 团队的事实标准开源技术栈。今年从原生 JSON 支持到物化视图所构建的基础，将继续在整个技术栈中释放新的性能提升和工作流优化。在 2026 年初，我们计划直接基于这些能力，为高吞吐量环境带来更快的仪表盘、搜索和直方图体验。

客户呼声最高的两项功能——RBAC 和审计日志——也正在稳步推进。RBAC 将允许管理员直接在 ClickStack 中创建和管理角色，为完整的可观测性工作流提供企业级的访问控制能力。审计日志则会带来更清晰的使用可见性和变更追踪，这是受监管环境以及大规模组织不可或缺的能力。

与此同时，我们正在大力投入全新的分析体验。一个 AI 驱动的笔记本功能预计将以私有预览的形式向部分用户开放，为数据探索、查询生成，以及在同一工作空间中融合可观测性与分析提供一种更顺畅的方式。用于告警的异常检测同样是重中之重，我们希望在现有基于阈值的告警之上，引入基于统计模型的能力，减少噪声，并帮助团队更早发现性能回退。

集成相关的工作也将持续提速。你可以期待不断增长的预构建仪表盘目录、更紧凑清晰的入门指南，以及针对常见运行环境更加简化的数据摄取路径。我们尤其关注 CSP 集成，例如 CloudWatch，并致力于让从 Kafka 拉取数据变得尽可能简单、配置成本最低。从长期来看，我们还将持续改进对 Prometheus 风格指标的支持，包括 ClickHouse 中即将推进的 PromQL 相关能力。

但在所有规划之中，最重要的里程碑，是迈向 ClickHouse Cloud 中完全托管的 ClickStack 形态。团队只需将遥测数据发送到平台，即可获得一个由 ClickStack 驱动、持续自动优化的完整可观测性体验。这一步虽然雄心勃勃，但它代表了平台演进的自然方向，也是一条从五月开启、逐步落地的愿景的终点——一个快速、可扩展、开放，并且几乎无需额外成本即可采用的可观测性平台。

最后，祝所有读者新年快乐，我们也期待在 2026 年的各类线下活动和线上与大家相见。

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com