基于 SQL 的可观测性现状

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

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

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

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

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

明年将是 SQL (结构化查询语言) 50 周年。如果您的工作或爱好与技术、数据或软件相关，那么您很有可能以前处理过 SQL。《2023 年 StackOverflow 开发者调查》将 SQL 评为第三大最受欢迎的编程语言，超过一半的 6.7 万名专业开发者使用它（有些人可能会说它不是真正的编程语言，或者说是吗？）。我们还必须注意，从设计上讲，这些数字偏向于软件开发者，并且仅部分包括分析师或数据工程师/科学家，他们也是 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 系统来满足。这意味着最初，OLAP 系统仅被能够证明对 Essbase 或 Microsoft SSAS 等初始专有解决方案或 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 项目的一部分。1998 年，Joshua Weinberg 描述了如何使用系统日志来集中来自异构系统的日志，以帮助系统管理员完成日常任务，借助几个 Perl 脚本。因此，集中日志记录的想法诞生了，这将成为可观测性的第一个支柱。值得注意的是，这种初始方法更侧重于 IT 网络中日志的传输机制，而没有解决存储问题，而是将日志视为普通文件。

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

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

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

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

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

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

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

开源在这个数据采集步骤中发挥了其魔力，社区创建了像 OpenTelemetry（简称 OTel）这样的项目，专门用于解决可观测性采集问题。OpenTelemtry 是一个 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 成为简化和组织数据转换工作流程的强大数据存储。

此外，分位数、唯一值、抽样、LTTB 和 更多的有效近似值是跨大数据跨度进行闪电般快速查询的变革性因素。

上述因素的结合导致基于 ClickHouse 的平台的总体 TCO 降低，同时释放了数据的全部潜力。我们最近在最小的 ClickHouse Cloud 设置上进行了一项实验，结果表明，对于高达 14TiB 的日志，您只需每月 300 美元即可获得出色的性能。随着您添加更多数据，这种比较变得更加有趣，因为它清楚地表明，成本和容量往往以不同的速度增长，具体取决于平台。

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

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

我们的一些 用户也发现 在利用 Metabase 等替代开源可视化和 BI 工具进行日志记录方面取得了成功，而其他用户则构建了 自定义工具。这表明开放的生态系统允许创新应用蓬勃发展。

在像 ClickHouse 这样的 SQL 数据库中公开可观测性数据的另一个重要方面是，几乎任何 SQL 兼容的客户端都可以通过支持的接口（Native、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 进行仪表板和日志探索。它目前管理着超过 10 PB 的遥测数据，压缩到 Clickhouse 中仅 600 TB（压缩比为 x16！），并成功地满足了我们管理的所有服务的日志记录要求。我们最近估计 LogHouse 与领先的商业 SaaS 可观测性提供商相比，成本节省比率为 300 倍。

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

• 在 Kubernetes 上使用 ClickHouse 进行监控的 OLAP，在 eBay
• 使用 ClickHouse 每秒处理 600 万个请求的 HTTP 分析，在 Cloudflare
• 使用 Clickhouse 构建经济高效的 PB 级日志记录平台，在 Zomato
• 快速可靠的与模式无关的日志分析平台，在 Uber
• 用于可观测性的 ClickHouse，在 Gitlab
• LLM 监控，在 Helicone
• 用于 OpenTelemetry 追踪的 ClickHouse，在 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 最近对 倒排索引 的支持现在更适用于日志探索和搜索。语言支持也在快速发展，ClickHouse 最近添加 了 Kusto 查询语言 (KQL)，这是一种面向管道的查询语言，特别适合分析遥测数据，并在安全分析社区中很受欢迎。最后，如上所述，应用于代码生成的生成式 AI 的飞跃，允许通过简单地用通俗英语（或您喜欢的语言）与可观测性数据交互来降低入门门槛。

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