ClickHouse可观测性的故事终于完整了，基于 SQL的技术演进依然在持续

ClickHouse在可观测性领域的新进展

最新推荐文章于 2025-12-03 12:12:23 发布

原创

最新推荐文章于 2025-12-03 12:12:23 发布 · 867 阅读

23 ·

CC 4.0 BY-SA版权

文章标签：

#clickhouse #sql #数据库

本文字数：15051；估计阅读时间：38 分钟

作者：Dale McDiarmid & Ryadh Dahimene

本文在公众号【ClickHouseInc】首发

引言

大约一年前，我们发布了一篇关于基于 SQL的可观测性现状的博文，分析了 SQL 和可观测性这两个领域的发展背景。我们解释了它们如何结合，带来了在可观测性领域的新机遇，同时回答了“SQL 可观测性何时适用于我的用例？”这篇文章引起了广泛关注，对新用户理解 ClickHouse 在可观测性领域的作用帮助很大。

虽然这篇文章的主要观点仍然适用，但一年时间对 ClickHouse 的发展来说意味着许多变化！多个新功能进一步推动 ClickHouse 成为可观测性数据的默认数据库，同时其生态系统也在成熟，使新用户更易于上手。

在本文中，我们将探讨一些新功能，并展示一些实验性的工作，这些工作可能成为 ClickHouse 在可观测性领域中指标管理的基础。

2023 年的基于 SQL 的可观测性

我们最初的文章提出，将可观测性视为一个数据问题，而 SQL 和 OLAP 系统（例如 ClickHouse）可以很好地解决这一问题。我们回顾了集中式日志记录的历史，并探讨了 Splunk 和 ELK 堆栈如何从 syslog 和 NoSQL 时代中发展而来。尽管 NoSQL 盛行，SQL 以其独特优势依然是第三大广泛应用的结构化数据管理语言。

当我们将可观测性重新定义为数据问题时，提出可以用 OLAP 原则和 SQL 构建其存储层。这种方法带来显著优势：高效压缩降低存储需求，快速的数据摄入和检索，结合对象存储实现无限扩展。以 ClickHouse 为例，它支持多种数据格式和集成引擎，便于在不同的可观测性管道中使用。SQL 提供的丰富分析功能进一步降低了可观测性数据的总体成本（TCO）。

OpenTelemetry 是这一趋势的重要推动力，它将跨平台的数据收集标准化，将数据收集从差异化功能变成了普及功能。一年之后，我们可以自信地说 OTel 正在“收集器之战”中占据主导地位。

行业内的广泛采用降低了厂商绑定，使基于 SQL 的存储解决方案与可观测性数据的集成更加便捷。

我们总结认为，基于 SQL 的可观测性架构简洁而灵活，为用户提供了丰富的个性化、适应和集成选项，更便于在现有 IT 环境中使用。

为帮助用户确定基于 SQL 的可观测性是否适合自身，我们提供了一个简单的检查表：

基于 SQL 可观测性适合于您，如果：

您和团队熟悉 SQL（或希望学习 SQL）
您倾向于使用 OpenTelemetry 等开放标准，以避免厂商绑定并实现扩展性
您愿意使用由开源驱动的生态系统，从数据收集到存储和可视化
您预计可观测性数据量会增长至中或大规模（甚至非常大）
您希望控制总成本（TCO），避免可观测性项目的成本失控
您不希望仅为了节省成本而限制数据保留时间

基于 SQL 可观测性不适合于您，如果：

您和团队对学习或使用 SQL 不感兴趣
您需要一个打包的端到端可观测性体验
您的可观测性数据量很小（例如低于 150 GiB）且没有增长预期
您的用例主要以指标为主，且需要使用 PromQL。在这种情况下，您仍可用 ClickHouse 处理日志和追踪数据，同时在 Grafana 中将其与 Prometheus 指标统一展示
您更愿意等待生态系统进一步成熟，使基于 SQL 的可观测性更加便捷

随着 2024 年接近尾声，问题是：鉴于 ClickHouse 的发展，这些建议是否需要刷新？

ClickHouse 对 JSON 的支持！可观测性领域的颠覆性功能？

在介绍 JSON 支持的最新进展前，先来探讨一下我们所说的 JSON 支持究竟指的是什么，为什么它对可观测性如此重要，以及用户目前面临的那些挑战。

什么是 JSON 支持？

ClickHouse 早已在数据输入输出上就支持 JSON 格式，这也促成了它与可观测性工具的早期整合。用户可以通过 ClickHouse 的原生接口或 HTTP 接口发送 JSON 数据，并选择多种输出格式满足需求。这种灵活性使 ClickHouse 更容易集成 OpenTelemetry、Grafana 等工具，实现流畅的数据摄取与可视化。同时，它让用户能轻松构建自定义接口，使 ClickHouse 能适应多种可观测性应用场景。

然而，将 JSON 集成作为输入输出格式与将 JSON 作为一种列类型支持是不同的——后者在可观测性中尤为关键。我们指的是能够定义 JSON 列，用于存储嵌套的动态结构，其中相同路径的值可能有不同的数据类型（可能互不兼容且不能预先确定）。

为什么 JSON 支持如此重要？

在可观测性解决方案中，用户希望能“直接发送事件”，而无需为模式精细化和优化操心。即使在有时间定义模式的情况下，集中式可观测系统通常会聚合来自多样化来源的数据——这些数据结构各异、不断变化，可能来自不同的应用、团队，甚至是不同组织（尤其是在 SaaS 解决方案中）。要实现所有数据的统一命名规则或模式非常困难。

虽然结构化日志和 OpenTelemetry 的标准和语义规范在一定程度上帮助解决了此问题，用户仍需要记录任意标签和字段。这些字段的数量、类型和嵌套层次可能因数据来源不同而差异巨大。为此，设计一种“非结构化 JSON”列非常有用，可灵活存储动态属性，如 Kubernetes 标签或特定应用的自定义元数据。

理想情况下，ClickHouse 支持 JSON 列类型，这样用户就可以直接发送半结构化数据。这种方式在功能、压缩和性能上与传统数据类型相同，同时大大简化了模式管理和定义的工作量。