核心内容摘要
网站，你应该明白我的意思吗？——那些心照不宣的沟通密码
本文字数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.Wangclickhouse.com