可观测性（Observability）是指通过系统的外部输出数据，推断其内部状态的能力。可观测性平台通过采集、存储、可视化分析三大可观测性数据：日志（Logging）、链路追踪（Tracing）和指标（Metrics），帮助团队全面洞察分布式系统的运行状态，支撑资源优化、预警机制、故障分析等，提升系统可靠性与用户体验。

SelectDB 针对可观测性场景进行倒排索引、全文检索、写入性能、存储空间等多方面优化，助力企业构建高性能、低成本、开放的可观测性平台，相对于 Elasticsearch 和云上日志服务，性能提升的同时成本降低数倍。

• 高性能： 写入性能是 Elasticsearch 的 5 倍，日志查询性能是其 2 倍，聚合统计分析性能是其 6～21 倍。
• 低成本： 以日增 100TB、保存 30 天、热数据 3 天的需求，SelectDB Cloud 成本大约 20 万/月 ，Elasticsearch 大约 140 万/月 ，云厂商日志服务大约 135 万/月。
• 易用性： 兼容 MySQL 语法；架构简洁，支持无停服自动升级、弹性扩缩容及自动负载均衡；并提供可视化集群管理 Cluster Manager。
• 开放性： 在全球主流云上（阿里云、腾讯云、华为云、AWS、Azure、GCP）提供服务，支持 OpenTelemetry、Grafana、 Kibana 等开源和商业生态，保持生态开放性和中立性。

接下来，我们将从多个角度深入分析和介绍，包括可观测性场景需求、可观测数据的特征以及各种方案之间的对比。帮助读者全面地理解可 SelectDB 可观测性方案的优势和适用性。

为什么可观测性越来越重要

可观测性平台在提升系统稳定性、优化运维效率和支持业务创新方面发挥着关键作用，近年来，可观测性的地位日益提升，主要源于以下两方面因素：

1. 业务和 IT 系统越来越复杂： 随着云计算和微服务的发展，业务系统日益复杂。例如，一个 GenAI 应用的请求可能涉及到 App、服务网关、鉴权服务、计费服务、RAG 引擎、Agent 引擎、向量数据库、业务数据库、分布式缓存、消息队列、大模型 API 等数十个服务。传统依赖登录服务器查询运行状态和分析故障的方式，在复杂系统中已经不再有效。而可观测性平台统一采集和存储 Log、Trace、Metrics 数据，提供统一可视化分析，能够有效快速发现问题。
2. 业务可靠性要求显著提高： 系统故障及其恢复效率直接影响用户体验。可观测性通过全域数据打通和全景可视化分析，支持团队快速定位问题根源，缩短业务中断时间，保障服务可用性。同时，依托全局数据分析和预测，能够提前发现系统资源瓶颈，预防故障发生。

如何选择可观测性解决方案

可观测性数据的特征

可观测性解决方案的核心在于如何高效应对海量数据的存储与分析挑战，而可观测性数据本身具有以下显著特征：

1. 数据存储量大且对成本敏感： 可观测性数据特别是 Log 和 Trace 规模极为庞大且持续生成。对于中大型企业而言，每天产生的可观测性数据高达 100 TB 甚至 PB 量级。为了满足业务需求或监管要求，这些数据往往需要存储半年甚至更长时间，存储总量长期维持在 PB 甚至 EB 级别，带来高昂的存储成本。而随着时间的推移，这些数据的价值也在逐渐下降，因此对于可观测性平台来说，存储成本也变的更加敏感。
2. 数据写入吞吐高且需要实时： 面对每天 TB 甚至 PB 量级新增数据，要求平台具备 1 ～ 10GB/s、百万 ～ 千万条/s 的高吞吐写入能力；同时，考虑到可观测性数据常用于故障排查、安全追踪等时效要求很高的场景，还要求平台保证秒级写入延迟，确保数据的实时性和可用性。
3. 需要实时分析且支持全文检索： Log 和 Trace 数据中有大量的文本，如何在其中快速检索关键词和短语是该场景的核心需求。由于数据规模庞大，传统的全量扫描和字符串匹配方式在性能和扩展性上往往无法达到实时响应的要求，特别是在上述高吞吐低延迟实时写入的前提下，实时文本检索更加困难。
4. 数据模式不固定且经常扩展： Log 最初始形态为非结构化原始日志，以 Free Text 的形式存在，逐步演变为以 JSON 为主的半结构化 Log 和 Trace，可自主增减 JSON 内部的字段，其数据的 Schema 非常灵活。传统严格的数据库和数据仓库已难以应对，数据湖系统虽然具备存储灵活性，但在处理性能和实时性方面却无法满足分析需求。
5. 需要对接多种数据源和分析工具： 可观测性生态中包含众多数据采集器和可视化分析工具，存储与分析引擎需兼容多种生态工具，满足与多样化数据和工具的高效集成。

可观测性方案的选择

当前市场呈多元化竞争态势，Elasticsearch 、Clickhouse、SelectDB 及各大云厂商均提供了可观测性方案。如何选择合适的方案，企业需从性能、成本、易用性、开发性等方面综合评估：

1. 性能：包括写入性能和查询性能。 可观测性常用于故障排查等紧急情况，一方面要求查询响应要快，特别是 Log、Trace 数据中的文本，需要实时全文检索支撑用户迭代式探索分析；另一方面要能查询到最新产生的数据，至少需查询到最近几秒的新鲜数据。

   1. Elasticsearch 以倒排索引和全文检索著称，提供秒级实时检索的能力，但在高吞吐下写入性能较低，高峰期容易出现写入拒绝和延迟过高的问题。其次，它的聚合统计分析能力性能也不太理想。
   2. SelectDB 采用列式存储和向量化引擎，针对可观测性分析场景对倒排索引进行了优化，其性能优于 Elasticsearch ，写入性能是 Elasticsearch 的 5 倍，查询性能是其 2 倍，聚合统计分析性能是 Elasticsearch 的 6～21 倍。
   3. Clickhouse 通过列式存储和向量化引擎，在写入和聚合查询上有显著优势，但全文检索性能相较于 Elasticsearch 或 SelectDB 存在数倍至数十倍的差距，并且当前仍处于实验阶段。
   4. 云厂商日志服务通过丰富的资源满足写入和查询性能，同时也带来下面的成本问题。

2. 成本：包括存储成本和计算成本。 相比于业务数据，可观测性数据的存储量庞大、价值密度更低，而且随着时间的推移，这些数据的价值持续下降，迫使企业更关注存储成本。同时，海量数据写入和查询带来的计算成本也很高，GB/s 的数据写入、TB 甚至 PB 级的数据检索往往需要大量的计算资源。

   1. Elasticsearch 成本问题众所周知，它采用原始数据行存 + 倒排索引 + docvalue 列存的存储模式，压缩比只有 1.5：1。同时，JVM 性能开销和构建倒排导致写入时 CPU 占用很高，计算资源成本也较高。对于日增 100TB、保存 30 天、热数据 3 天的需求，Elasticsearch 成本大约 140 万/月。
   2. SelectDB 在可观测性场景进行性能和成本双重优化，同等负载下成本较 Elasticsearch 缩减 50% ～ 80%。存储上包括倒排索引、列式存储、ZSTD 压缩的优化，压缩比可达 5:1 ～ 10:1，结合冷热存储分层可进一步压缩成本。写入上包括单副本写入、时序 compaction 减少写放大、向量化索引构建等优化。对于日增 100TB、保存 30 天、热数据 3 天的需求，SelectDB Cloud 成本大约 20 万/月。
   3. Clickhouse 采用列式存储和向量化引擎，存储和写入成本也较低。
   4. 云厂商日志服务的成本也很高，对于日增 100TB、保存 30 天、热数据 3 天的需求，成本大约 135 万/月。

3. 易用性：包括易用性和易维护性。 由于数据量庞大，可观测性平台通常采用分布式架构，其部署、扩容、缩容和升级等运维操作的便捷性直接影响平台的扩展能力。同时，系统接口设计也至关重要，既决定了平台调用底层存储的开发效率，也关系到终端用户的使用体验。

   1. 在 Elasticsearch 的 ELK 生态中，Kibana 提供了直观易用的 Web 界面，且易于维护管理。然而，其提供的 DSL 查询语言复杂，学习门槛很高，对于可观测性平台对接和应用开发带来较大挑战。
   2. SelectDB 提供与 Kibana 类似的交互式分析界面，并将对接 Kibana 和 Grafana 原生界面，查询语言采用标准 SQL 并兼容 MySQL 语法，可观测性平台开发的开发门槛和使用难度均较低。其次，SelectDB 架构简洁，支持无停服自动升级、弹性扩缩容及自动负载均衡，同时提供可视化 Cluster Manager 高效管理集群。
   3. Clickhouse 虽提供 SQL 接口，但语法采用独立体系，存在一定学习成本。且 Clickhouse 在维护管理上也面临很多挑战，比如本地表 + 分布式表的概念、扩缩容无法自动均衡等等，通常需要开发一套运维系统来支撑。
   4. 云厂商日志服务提供 SaaS 服务，用户无需自行维护系统，使用也比较方便。

4. 开放性：包括开源开放和多云中立。 可观测性平台的建设还需要考虑是否会被绑定，需重点评估开源程度、多云服务支持能力及生态开放性，这些因素直接影响平台的灵活性和长期可用性。

   1. Elasticsearch 提供开源和商业版本，在多个云上提供服务。它的 ELK 生态比较独立，难以与其他生态打通，比如 Kibana 只支持 Elasticsearch 而且很难扩展到其他系统。
   2. SelectDB 是基于 Apache Doris 开源项目的商业版本，也是 Doris 社区的最大的贡献者，在全球主流云上（阿里云、腾讯云、华为云、AWS、Azure、GCP）提供服务。SelectDB 支持 OpenTelemetry、Grafana、 Kibana 等开源生态和商业生态，保持生态开放性和中立性。
   3. Clickhouse 提供开源和商业版本，在多个云上提供服务。Clickhouse 支持 OpenTelemetry、Grafana 等开源生态，同时收购了一家可观测性商业公司，在生态支持上将很难保持中立性。
   4. 云厂商日志服务会和自己的云绑定，不提供开源的选项，不同云厂商之间的产品，很难保持一致的体验或者便捷的迁移。

基于上述分析，可知 SelectDB 可以实现高性能写入和查询的同时保持很低的成本，且其架构简单、易于维护和扩展，提供简单易用的标准 SQL 接口，支持开源版本、商业版本和云上服务，确保私有化和多云部署体验一致，是构建可观测性平台的理想选择。

基于 SelectDB 的可观测性解决方案

SelectDB 针对可观测性场景的特点，在 MPP 分布式架构，结合向量化执行引擎、CBO 优化器基础增加了倒排索引以及极速全文检索能力，实现了写入性能和存储空间极致优化，能够很好的应对可观测性数据提出的挑战，使用户可基于 SelectDB 构建高性能、低成本、开放的可观测性平台。

系统架构

基于 SelectDB 的可观测性平台主要由 3 大核心部分组成：

• 数据采集和预处理：支持多种可观测性数据采集工具，包括开放的 OpenTelemetry 生态和 ELK 生态中的 Logstash、Filebeat，可通过 HTTP API 将 Log、Trace、 Metrics 数据写入 SelectDB。
• 数据存储和分析引擎：SelectDB 提供高性能、低成本的统一可观测性数据存储，并可通过 SQL 接口提供丰富的检索和分析能力。
• 查询分析和可视化：对接最常用的可观测性可视化分析工具，包括广泛使用的 Grafana 和 ELK 生态中的 Kibana，为用户提供简单易用的界面，以进行检索、分析，并设置告警规则，实现实时监控和快速响应。

基于 SelectDB 的可观测性解决方案有以下特点及优势：

• 高性能
  • 高吞吐、低延迟写入：支持每天 PB 级 (10GB/s ） 的 Log、Trace、Metrics 数据持续稳定写入，同时保持延迟在秒级甚至毫秒级。
  • 高性能倒排索引和全文检索：支持倒排索引、全文检索、日志场景关键词检索，并能在秒级响应，实测性能是 Clickhouse 的 3～10 倍。
  • 高性能聚合分析：基于 MPP 分布式架构和向量化 Pipeline 执行引擎，充分利用集群分布式和 CPU 多线程资源，在 ClickBench 测试中实现全球领先性能，可很好支撑可观测性场景的趋势分析、监控告警等常见查询。
• 低成本
  • 高压缩率和低成本存储：支持 PB 级海量存储，压缩率可达 5:1 ～ 10:1 甚至更高（包括索引），比 Elasticsearch 存储成本节省 50% ～ 80% ，支持冷数据存储到 S3/HDFS，存储成本再降 50%。
  • 低成本写入：同样的写入流量， SelectDB 的 CPU 资源消耗比 Elasticsearch 至少降低 70% 。
• Flexible Schema
  • 顶层字段变更：可以通过 Light Schema Change 发起 ADD / DROP COLUMN / INDEX 增加 / 删除列 / 索引，并能够在秒级完成 Schema 变更。用户在规划可观测平台时，只需关注当前需要哪些字段需要创建索引。
  • 字段内部变更：专门为可扩展的 JSON 数据设计了半结构化数据类型 VARIANT，可以自动识别 JSON 中的字段名和类型，并自动拆分频繁出现的字段进行列式存储，提高压缩率和分析性能。相对于 Elasticsearch 的 Dynamic Mapping，VARIANT 允许字段的类型发生变化。
• 易用性
  • 标准易用的 SQL 接口：SelectDB 支持标准 SQL、兼容 MySQL 协议和语法，基于 SelectDB 构建的可观测性平台能够使用 SQL 进行查询，对工程师和数据分析师非常友好。
  • 拥抱可观测生态：兼容 OpenTelemetry 和 ELK 生态，无缝对接 Grafana 和 Kibana 等主流可视化工具，便于用户采集数据以及可视化分析。
  • 运维方便：无需停服即可在线扩缩容、自动均衡；私有化部署提供可视化 Cluster Manager 和 K8s Operator 工具；云上提供开箱即用的免运维服务。
• 开放性
  • 开源开放：SelectDB 是基于 Apache Doris 开源项目的商业版本，也是开源社区最大的贡献者，支持 OpenTelemetry Grafana 等开源生态和商业生态。
  • 多云中立：SelectDB 已与主流云厂商（阿里云、腾讯云、华为云、AWS、Azure、GCP）合作，为用户提供多云一致的体验。

Demo & Screenshot

以下，我们通过 OpenTelemetry 社区的全方位演示 Demo ，来展示基于 SelectDB 构建的可观测性平台能力。

如下方视频所示：被观测的业务系统是一个十多个模块组成的电商网站，压力模拟程序 Load Generator 持续请求入口服务，在整个电商系统中产生大量的可观测性数据（Log、Trace、Metrics），这些数据使用 OpenTelemetry 的各种语言 SDK 进行采集，发送给 OpenTelemetry Collector，Collector 中的 Processors 进行预处理，然后经过 OpenTelemetry Doris Exporter 写入到 SelectDB，在通过 Grafana 进行可视化分析。

Grafana 通过 MySQL Datasource 连接到 SelectDB，提供统一的 Log、Trace、Metrics 可视化分析，还可以实现 Log 和 Trace 的联动。

Log

Trace

Metrics

Grafana 的 Log 可视化和分析能力相对于 Kibana 来说是比较简单的，因此在 SelectDB Studio 中实现了类似 Kibana Discover 的检索分析能力，未来也会集成到 Grafana Doris datasource 中，提供更好的统一 Log Trace Metrics 可视化分析能力。

此外，在未来一个季度，SelectDB 将通过兼容 Elasticsearch 查询协议，实现原生 Kibana 直接连接到 SelectDB。对于 ELK 用户而言，如果将 Elasticsearch 替换为 SelectDB，可在不改变日志采集和可视化分析使用习惯的前提下，实现降本增效的目标、降低了原用户的使用门槛。

用户声音

案例 1：观测云

观测云使用 Doris 的商业化版本 SelectDB 替代了云上的 Elasticsearch。通过 SelectDB 的倒排索引能力、Variant 数据类型、冷热数据存储分层等特性，为观测云日志存储和分析场景服务注入强大的动力，实现存储成本降低 70% 的同时，查询性能提升 2-4 倍，最终实现整体性价比 10 倍提升。

案例 2 ：中信银行信用卡

为确保业务系统的稳定运行、提升运维效率和用户体验，中信银行信用卡中心建立了大规模的日志云分析平台。支持实时监控和故障排查、满足金融监管对日志审计的严格要求。目前，平台每日新增日志数据突破百 TB，全量归档日志量达 PB 级。

早期基于 Elasticsearch 构建的日志云平台面临存储成本高、实时写入性能差、文本检索慢以及日志分析能力不足等问题。因此，卡中心引入 Apache Doris 替换 Elasticsearch，实现资源投入降低 50%、查询速度提升 2～4 倍，同时显著提高了运维效率。

案例 3：MiniMax

MiniMax 引入阿里云数据库 SelectDB 版构建了覆盖国内及海外业务的日志可观测中台，总体数据规模超过数 PB，日均新增日志写入量达数百 TB。系统在 P95 分位查询场景下的响应时间小于 3 秒，峰值时刻实现了超过 10GB/s 的读写吞吐。通过存算分离、高压缩比算法和单副本热缓存等技术手段，MiniMax 在优化性能的同时显著降低了建设成本，计算资源用量降低 40%，热数据存储用量降低 50%，为未来业务的高速发展和技术演进奠定了坚实基础。

结束语

基于 SelectDB 的高性能倒排索引、高吞吐量写入和高压缩存储，用户可以构建出性能高于Elasticsearch 10 倍的可观测性平台，并支持国内外多个云上便捷使用 SelectDB Cloud 的开箱即用服务。

SelectDB 将在可观测性内核能力和生态支持上持续进化，未来几个月将推出以下新功能：

1. 通过 es2doris proxy 实现与原生 Kibana 的可视化分析对接，结合现有的 Logstash Doris Output Plugin，帮助 ELK 生态的用户平滑迁移到 SelectDB。
2. 通过 Grafana Doris Datasource 提供 Grafana Native Support，并将类似 Kibana Discover 的交互式检索分析能力集成到 Grafana，让 Grafana 用户也能获得更好的检索分析体验。
3. 增强倒排索引和全文检索能力，支持更多分词器，如 ik、icu、edge ngram，同时允许自定义组合分词器。
4. 增强半结构化数据分析 VARIANT，支持不频繁字段的合并存储，并根据字段名指定类型和索引等。