基于 SQL 的可观测性现状

“未来已经到来——只是尚未均匀分布。”
经济学人，2003 年 - 威廉·吉布森

工程和计算机科学中许多成功的范式都是两种截然不同的方法相互碰撞的结果，从而带来了更广泛、更强大的应用。

以人工智能为例，自动驾驶汽车的普及直接受益于深度学习与计算机视觉的进步。同样，强化学习与机器人的结合也推动了机器人自主控制系统的进步。另一个最近的例子是机器学习与自然语言处理的结合，这导致了能够以更自然、更人性化的方式理解和响应用户查询的对话式聊天机器人的出现。

在下面的博文中，我们将探讨两个既定范式的并行背景：SQL 和可观测性。我们将解释它们是如何碰撞并共同创造可观测性领域一系列新机遇的。最后，我们为读者提供了必要的要素来回答以下问题：**基于 SQL 的可观测性是否适用于我的用例？**

如果您没有时间阅读整篇文章（约 10 分钟），您可以在摘要部分找到主要要点。

明年将是 SQL（结构化查询语言）的50 周年纪念。如果您的工作或爱好与技术、数据或软件相关，那么您很可能之前已经使用过 SQL。根据2023 年 StackOverflow 开发者调查，SQL 被评为第三大最受欢迎的编程语言，超过一半的 67,000 名受访专业开发人员使用过它（有些人可能会说它不是真正的编程语言，是吗？）。我们还必须注意，根据设计，这些数字偏向于软件开发人员，并且仅部分包括也精通 SQL 的分析师或数据工程师/科学家。

在这个快节奏的数字时代，SQL 的长寿和流行是一个例外，证明了它优雅的简洁性和适应性

上面列出的前 5 种编程语言中，除了 SQL 之外，其他所有语言都是 20 世纪 90 年代或之后创建的，平均年龄约为 25 年。在这个快节奏的数字时代，SQL 的长寿和流行是一个例外，证明了它优雅的简洁性和适应性。

不过，半个世纪以来并非一帆风顺，因为多年来出现了许多语言，并在处理数据方面声称具有优越性。许多人记得 NoSQL 时代，当时负担得起的计算和存储资源的出现使 NoSQL 运动打破了 SQL 长期以来的统治地位。然而，十多年后，数据领域大多回到了 SQL，这再次证明了其持久优势。

多年来，SQL 已被建模并适应于不同的应用程序，大致分为两类：OLTP 和 OLAP（联机事务处理和联机分析处理）。OLTP 数据库几乎从一开始就得到了广泛采用，包括 IBM Db2 和 Oracle 等专有系统，以及 MySQL 和 Postgres 等开源对应系统。这是因为这些系统在几乎所有应用程序的后端和真实来源中都发挥着关键作用。

有趣的是，OLAP 术语是由 E. F. Codd大约 30 年前首次提出的（即使类似 OLAP 的系统早些时候就存在）。OLAP 的采用故事与 OLTP 不同，因为分析系统并不总是被视为“必备”的，并且根据数据集的大小和业务需求的性质，一些适度的分析需求可以通过 OLTP 系统来满足。这意味着最初，只有能够证明对 Essbase 或 Microsoft SSAS 等专有解决方案进行投资的大型组织才采用 OLAP 系统，或者最近采用 SAP Hana 和 Vertica 等系统。

十多年前，云数据仓库的兴起是 OLAP 广泛采用的一个重要催化剂，这主要归功于三驾马车：Snowflake、Google BigQuery 和 Amazon Redshift。在开源方面，Apache Druid（2011 年）、Apache Pinot（2013 年）和 ClickHouse（2009 年启动，2016 年开源）等替代方案开始出现。开源 OLAP 数据库的出现有助于降低进入门槛，提供具有成本效益的替代方案，并允许组织根据其特定需求定制围绕实时分析的解决方案。我们在之前的博文中详细介绍了开源 OLAP 系统如何有效地实现实时数据仓库。

由于可观测性是一项面向实时分析的任务，因此在本博文中，我们将交替使用 SQL 首字母缩写词来指代查询语言本身及其在 OLAP 用例中的应用。

令人惊讶的是，可观测性的根源甚至比 SQL 更早。工程师 Rudolf E. Kálmán是第一个在 20 世纪 60 年代使用该术语的人，将其作为衡量系统内部状态可以通过其外部输出的知识推断出来的程度。然后，计算机和 IT 系统的出现导致了监控和日志记录方法的激增。我认为另一个重要的里程碑发生在 20 世纪 80 年代，当时 Eric Allman 作为 Sendmail 项目的一部分开发了“syslog”。1998 年，Joshua Weinberg 描述了如何使用 syslog 集中来自异构系统的日志，以帮助系统管理员完成日常任务借助几个 Perl 脚本。因此，集中的日志记录的想法诞生了，这后来成为可观测性的第一个支柱。值得注意的是，这种最初的方法更侧重于在 IT 网络中传输日志的机制，而没有解决存储问题，将日志视为普通文件。

快进到 2013 年，当时 Twitter 的快速增长导致了前所未有的可扩展性挑战。这迫使它的工程团队快速行动，从单体架构转向大规模分布式系统，同时保持服务正常运行。Twitter 当时在其有影响力的博客文章"Twitter 的可观测性"中记录了他们的方法。

“可观测性团队的使命是利用我们统一的平台来收集、存储和呈现指标，从而分析此类问题……随着 Twitter 的不断发展，它变得越来越复杂，服务也越来越多。数千个服务实例和数百万个数据点需要高性能的可视化和自动化，以便智能地将有趣的或异常的信号呈现给用户。”.

作为一家以技术为中心的公司，并且由于当时没有现成的可观测性解决方案可用，Twitter 工程师在内部构建了大部分组件来满足这些需求，包括一个构建在领先的 NoSQL 存储 Apache Cassandra 之上的自定义时间序列数据库。与此同时，在无数其他组织中，人们也注意到，像 Elasticsearch 这样的全文搜索引擎也可以用于存储日志和遥测数据。这种方法，在 ELK 堆栈或 Splunk 等专有解决方案的出现推动下，将其他 NoSQL 存储作为事实上的可观测性存储。

从那时起，世界已经赶上了潮流，每个组织都比以往任何时候都更加重视技术。因此，自然而然地，许多工具和供应商出现在了可观测性领域，提供开箱即用、本地部署或 SaaS 解决方案，以便公司不必像 Twitter 在 2013 年那样自己构建。由此产生的可观测性领域包含了 NoSQL 存储和通常使用 NoSQL 存储作为后端的交钥匙 SaaS 解决方案的混合体。这也导致了可观测性术语定义的“扩展”，涵盖了一套工具和实践，使组织能够有效地监控和操作其资产。

2013 年的 Twitter 文章（上面引用）已经设定了标准的可观测性管道，它包括收集、存储、可视化和告警（请注意，Twitter 将告警称为“监控”）。

这个管道的结构基本上仍然相同；许多可观测性供应商为端到端的体验提供所有组件，从收集代理和数据聚合器到存储层和展示 GUI。但是，在可观测性管道的每个步骤中，都出现了新的想法和项目，提供替代解决方案，有效地将 SQL 带回了可观测性领域。所以，让我们深入探讨每个步骤。

在可观测性管道的每个步骤中，都出现了新的想法和项目，提供替代解决方案，有效地将 SQL 带回了可观测性领域。

开源在这个数据收集步骤中发挥了它的魔力，社区创建了像OpenTelemetry（简称 OTel）这样的项目来专门解决可观测性收集问题。OpenTelemetry 是一个 CNCF 孵化项目，它提供了一套与供应商无关的 API、SDK 和工具，用于检测、生成、收集和导出遥测数据，例如跟踪、指标和日志。重要的是，OTel 正在缓慢但稳步地确立其作为行业标准的地位。这种标准化使得与不同的存储层和前端集成变得更加容易，并摆脱了锁定环境。

存储层是可观测性堆栈的引擎，需要能够实时摄取和公开不断增长的海量数据的系统。作为 OLAP 列存储，ClickHouse 适用于几乎任何规模的数据，并且拥有使其特别适合可观测性数据的特性。

ClickHouse 以毫秒级速度运行，并充分利用所有可用的系统资源，尽可能快地处理每个分析查询。这对于摄取速度也是如此，每秒达到数百万行并不罕见。这是由于磁盘上数据的列式结构以及实现最快 OLAP 数据库所需对底层实现（例如向量化查询引擎）的关注相结合而实现的。

将相似的数据分组到列中不仅有利于分析查询，还可以最大化同构列文件的压缩率，受益于排序的局部性效应。相比之下，基于 NoSQL 索引的存储的主要挑战之一是磁盘上数据的大小膨胀。

ClickHouse 带有压缩算法，可以在摄取和查询时动态处理数据。这对于可观测性数据尤其重要，因为预计会有大量的冗余数据。例如，在最近的一项研究中，我们发现 ClickHouse 管理的日志数据获得了 14 倍的压缩率，同时仍然能够在最小的硬件占用空间上实现出色的性能。

ClickHouse 可以部署在共享无状态架构中（每个节点管理自己的存储和计算）。这适用于许多用例，但缺点是引入了严格的可扩展性模型和一些脆弱性，因为磁盘往往很昂贵且不可靠。

数据存储的另一个转变发生在“存储和计算分离”的概念中。与通过磁盘为 ClickHouse 节点提供支持相比，部署使用对象存储支持的“共享存储”方法通常更具吸引力。ClickHouse Cloud 更进一步，在"共享一切"架构中实现了存储和计算的完全分离。基于 S3 的架构还简化了数据管理：无需预先调整集群/存储的大小，甚至无需对数据进行分片。

这牺牲了一部分查询性能，以换取降低操作复杂性（例如，如果将 SSD NVMe 与基于 S3 的系统进行比较）。但是，我们的测试显示，在 Clickhouse Cloud 规模下，优势更大，这使得它对数据负载不断增长的可观测性工作负载具有吸引力。

支持99 种数据格式、20 多个内置集成引擎以及数百个第三方集成，作为更广泛、更活跃的开源集成生态系统的一部分，互操作性并非事后才考虑，而是 ClickHouse 的主要特性。这使得它能够轻松地集成到几乎任何现有的堆栈中，并降低复杂性和部署时间。这也意味着数据永远不会锁定到平台中，并且可以轻松复制、移动或简单地通过不同的方式就地查询。

例如，您可以决定使用 S3 表函数将大量遥测数据以 Parquet 格式存储在远程对象存储桶中以供归档，从而有效地扩展您的保留功能（例如，为了遵守合规性），同时仍然能够远程查询数据。

ClickHouse SQL 支持超过 1474 个聚合和分析函数，使实时数据探索变得简单而强大。物化视图等功能通常用于在插入时转换数据，这支持常见的任务，例如从非结构化日志中提取结构，并结合分区、TTL 管理、动态列选择、物化列等等。由像dbt（数据构建工具）这样的工具驱动的服务器端数据转换，也使 ClickHouse 成为一个强大的数据存储，可以简化和组织数据转换工作流程。

此外，对分位数、uniq、采样、LTTB和许多其他的有效近似值是改变游戏规则的关键，因为它们可以对大范围数据进行闪电般的快速查询。

上面提到的因素的组合导致基于 ClickHouse 的平台的总体 TCO 降低，同时释放数据的全部潜力。我们最近在一个最小的 ClickHouse Cloud 设置上进行了一个实验，结果表明，您可以实现出色的性能，最多可处理 14TiB 的日志，每月只需花费 300 美元。随着您添加更多数据，这种比较变得更加有趣，它清楚地表明成本和容量的增长速度会根据平台的不同而有所不同。

数据的展示层可以采用各种形式。在这个领域，ClickHouse 得益于一个充满活力的集成生态系统。

作为可观测性可视化功能的领先提供商，我们与 Grafana Labs 密切合作，开发了clickhouse-datasource，以确保用户体验流畅并利用所有相关的 ClickHouse 功能。Grafana 还提供了内置的告警功能和广泛的连接器目录，可以在同一个仪表盘中组合各种数据源。

一些我们的用户也通过利用用于日志记录的替代开源可视化和BI工具（如Metabase）获得了成功，而其他用户则构建了自定义工具。这表明开放的生态系统能够促进创新型应用程序的蓬勃发展。

将可观测性数据暴露在像ClickHouse这样的SQL数据库中的另一个重要方面是，几乎任何与SQL兼容的客户端都可以通过支持的接口（原生、HTTP、ODBC、JDBC、MySQL）与之交互。从SQL客户端到数据可视化和BI工具以及语言客户端。这扩展了实现自定义替代方案以摆脱锁定体验的可能性。

最后，即使SQL的学习曲线通常很短，但应用于代码生成的生成式AI的普及也使得从自然语言输入生成SQL查询比以往任何时候都更容易，而不是编写查询。这使得SQL学习曲线论点变得不那么重要。ClickHouse Cloud的用户已经可以将查询写成自然语言问题，并将其留给控制台根据可用表的上下文将其转换为SQL查询。同样的方法用于自动修复用户查询。

我们之前讨论过的SQL和可观测性并行时间线表明，在技术方面，从诞生到全球采用和普及的路径可以有多种形式。

我们认为，目前，高效实时OLAP存储的易用性以及开源可观测性标准的成熟度，使得将经过验证和时间考验的SQL原则应用于可观测性用例成为可能。此外，将可观测性视为另一种数据用例会导致其商品化，从而加速其全球采用。

由此产生的基于SQL的可观测性堆栈简单且不拘泥于特定观点，为用户提供了许多选项，以便在现有的IT环境中进行个性化、调整和集成。例如，一些架构将利用消息队列（如Apache Kafka）来帮助收集和缓冲数据，然后再将其摄取到ClickHouse中（我们在最近的示例中使用WarpStream展示了这种架构）。其他示例可能会部署多个可视化工具，以除了经典仪表板之外，还提供自助服务可视化功能。

我们最近估计，LogHouse与领先的商业SaaS可观测性提供商相比，成本节约率高达300倍。

我们在ClickHouse部署了上述堆栈，作为ClickHouse Cloud的集中式日志记录平台，代号为“LogHouse”。这是一个多区域的ClickHouse Cloud部署，利用OpenTelemetry Kubernetes集成进行收集，ClickHouse Cloud进行存储，以及Grafana进行仪表板和日志探索。它目前管理着超过10PB的遥测数据，压缩后仅剩600TB（压缩率为16倍！），并成功地满足了我们对所有管理服务的日志记录需求。我们最近估计，LogHouse与领先的商业SaaS可观测性提供商相比，成本节约率高达300倍。

同样，许多运行大规模用例的用户已经成功实现了基于SQL的可观测性管道。示例包括

• 在eBay上使用Kubernetes进行监控的OLAP
• 使用ClickHouse每秒处理600万个请求的HTTP分析，在Cloudflare
• 使用Clickhouse构建经济高效的PB级日志记录平台，在Zomato
• 快速可靠的与模式无关的日志分析平台，在Uber
• ClickHouse用于可观测性，在Gitlab
• LLM监控，在Helicone
• ClickHouse用于OpenTelemetry跟踪，在Resmo

ClickHouse也被用作一些最流行的可观测性SaaS提供商的后端，包括

• Signoz.io
• Highlight.io
• Qryn
• BetterStack

虽然上一节详细列出了优点，但踏上基于SQL的可观测性旅程的用户必须了解当前的局限性，以便做出明智的决定（截至2023年12月）。

可观测性传统上分为三个支柱：日志记录、指标和跟踪。根据我们自身以及与客户合作在规模上运行ClickHouse以实现可观测性的经验，我们认为，在生态系统当前的成熟度水平下，日志记录和跟踪是最容易解决的两个支柱。我们在之前的两篇博文中对这些用例进行了广泛的记录：日志和跟踪。

另一方面，指标用例目前由Prometheus主导，它既是维度数据模型又是查询语言。虽然我们看到许多用例成功地利用ClickHouse处理指标，但我们认为，一个交钥匙的指标体验将受益于ClickHouse中的PromQL支持。因此，我们已决定投资于这一领域。

最后，正在考虑基于SQL的可观测性的用户需要通过考虑内部团队/用户的技能和概况来考虑采用问题。即使SQL是数据操作的通用语言，并且可以通过AI辅助轻松生成，可观测性用户也可能来自不同的背景（SRE、分析师、DevOps或管理员），并且根据您希望为他们创建的体验类型（即自助服务与预先准备好的仪表板和警报），SQL的学习曲线可能或可能没有意义，并且需要进行评估。

如果您想为您的用例考虑基于SQL的可观测性，以下是对您需要了解内容的总结列表（我保证这不是通过要求ChatGPT总结这篇文章生成的）。

如果以下情况适用，则基于SQL的可观测性适合您

• 您或您的团队熟悉SQL（或希望学习它）。
• 您更喜欢遵守OpenTelemetry等开放标准，以避免锁定并实现可扩展性。
• 您愿意运行一个由开源创新推动的生态系统，从收集到存储和可视化。
• 您预计管理的可观测性数据量会增长到中等或大规模（甚至非常大规模）。
• 您希望控制TCO（总拥有成本）并避免可观测性成本螺旋式上升。
• 您无法或不想仅仅为了管理成本而将可观测性数据的保留期限制为较短的时间。

如果以下情况适用，则基于SQL的可观测性可能不适合您

• 学习（或生成！）SQL对您或您的团队没有吸引力。
• 您正在寻找一种打包的、端到端的可观测性体验。
• 您的可观测性数据量太小，无法产生任何重大差异（例如，<150 GiB），并且预计不会增长。
• 您的用例以指标为主，需要PromQL。在这种情况下，您仍然可以在Prometheus用于指标的同时，将ClickHouse用于日志和跟踪，并在表示层使用Grafana进行统一。
• 您更愿意等待生态系统更加成熟，并使基于SQL的可观测性变得更加交钥匙。

通过这篇文章，我们尽最大努力对基于SQL的可观测性的现状进行诚实的评估。这基于我们对用例的了解、我们在该领域每天观察到的趋势以及我们自身运行可观测性管道的经验。我们希望这些要素能够帮助您自己做出决定，并对基于SQL的可观测性是否适合您做出明智的判断。

此外，这代表了撰写本文时（2023年12月）该领域的现状。这一领域正在持续改进和快速扩展，对我们上面讨论的一些核心要求提出了挑战。例如，ClickHouse最近对倒排索引的支持现在与日志探索和搜索更相关。语言支持也在随着最近添加Kusto查询语言（KQL）到ClickHouse而快速发展，KQL是一种面向管道的查询语言，特别适用于遥测数据的分析，并在安全分析社区中很流行。最后，如上所述，应用于代码生成的生成式AI飞跃使人们能够通过简单的自然语言（或您首选的语言）与可观测性数据进行交互，从而降低了进入门槛。

希望这些增强功能以及开源堆栈的成熟度能够共同加速可观测性的商品化，从而促进其在组织中的广泛采用，并使几乎每个人都能受益于更可靠的最终解决方案。