从Elasticsearch到Apache Doris：GuanceDB观测平台升级记

可观察性平台类似于免疫系统。就像免疫细胞遍布人体一样，可观察性平台会巡查你设备、组件和架构的每一个角落，识别任何潜在威胁并主动缓解它们。不过，这个比喻可能有点过了，因为我们至今尚未发明像人体一样复杂的系统，但我们总是可以在进步的道路上不断前行。

提升可观测性平台的关键在于加快数据处理速度并降低成本，这有两大原因。

1. 你越快地从数据中发现异常，就能越快地控制潜在的损害。
2. 一个可观测平台需要存储海量数据，而低成本存储是使其可持续的唯一方法。

这篇帖子是关于GuanceDB，一个可观测性平台，通过将Apache Doris作为其查询和存储引擎，取代了Elasticsearch，在存储成本和数据查询性能两方面取得了进展。结果是存储成本减少了70%，而数据查询性能则提升了200%～400%。

GuanceDB 是一个全方位可观测性解决方案。它提供了数据分析、数据可视化、监控及告警等服务，并进行安全检查。用户可以借助 GuanceDB 了解他们的资源、网络状况、应用程序、用户体验、系统的可用性等。

从数据管道的角度来看的话，GuanceDB可以分为两个部分：数据摄入以及数据分析。我将一一解释它们。

数据整合

对于数据集成，GuanceDB 使用其自主研发的工具 DataKit。这是一站式数据收集和处理工具，可以从不同的终端设备、业务系统、中间件和数据基础设施中提取数据并进行初步处理。它还可以对数据进行预处理并关联元数据。它为各种类型的数据提供了广泛的支持，包括日志、时间序列指标，以及来自移动 APP 和网页浏览器的用户行为、安全事件和分布式跟踪数据。为了满足各种场景下的需求，它保证了与各种开源探针和采集器兼容以及各种自定义格式的数据源。

DataKit收集的数据会经过核心计算层处理，然后进入GuanceDB这一多模型数据库。这是一个融合了多种数据库技术的多模型数据库。它包括查询引擎层和存储引擎层。通过解耦查询引擎和存储引擎，从而实现了可插拔和可互换的架构设计。

对于时间序列数据方面，他们开发了名为Metric Store的，是基于VictoriaMetrics的自研存储引擎。在日志方面，他们集成了Elasticsearch和OpenSearch。在这个架构中，GuanceDB的表现令人满意，而Elasticsearch则还有改进的余地。

• 数据写入：Elasticsearch 消耗了大量的 CPU 和内存资源。这不仅耗费大量资源，还会干扰查询执行。
• 无模式支持：Elasticsearch 通过动态映射提供了无模式支持，但在这种情况下，这还不够灵活，以处理大量用户自定义的字段。这可能导致字段类型冲突，从而造成数据丢失。
• 数据聚合：大型聚合任务常常导致 Elasticsearch 超时错误。

所以升级就在这里发生。GuanceDB 尝试并用 Apache Doris 替换了原来的 Elasticsearch。

在 GuanceDB 可观测性平台中，几乎所有的查询都涉及基于时间戳的过滤。同时，大多数数据聚合需要在指定的时间范围内进行。此外，还需要在时间窗口内对每个序列的时间序列数据进行聚合。在 SQL 中表达这些需求通常需要嵌套子查询，从而使得语句变得复杂且繁琐。

这就是GuanceDB开发自己的数据查询语言（DQL）的原因。因此，这种DQL具有简化了的语法元素和优化了的可观察性用例计算功能，可以查询指标、日志、对象数据，以及分布式追踪中的数据。

这是DQL如何与Apache Doris协同工作的样子。GuanceDB找到了一种充分发挥Doris的分析能力，同时完善其SQL功能的方法。

如下所示，Guance-Insert 是负责数据写入的部分，而 Guance-Select 则是 DQL 查询引擎。

• Guance-Insert : 它允许不同租户的数据可分批积累，并在写入吞吐量和写入延迟之间取得平衡。当日志生成量巨大时，它能保持2~3秒的低延迟。
• Guance-Select : 对于查询执行，如果查询SQL语义或功能在Doris中得到支持，Guance-Select将把查询推送到Doris前端进行计算；如果未得到支持，则会退而求其次，通过Thrift RPC接口以Arrow格式获取列数据，并在Guance-Select中完成计算任务。但有个问题是，它无法将计算逻辑推送到Doris后端，因此相比在Doris前端直接执行查询，速度可能会稍慢一些。

此前，使用 Elasticsearch 集群时，他们用了 20 台云虚拟机（每台 16vCPU 64GB），并且有独立的索引写入服务（另外 20 台云虚拟机）。现在使用 Apache Doris，他们只需要总共有 13 台相同配置的云虚拟机，相当于成本减少了67%。这得益于 Apache Doris 的三个特点：

• 高写入吞吐量：在稳定的写入吞吐量为1GB/s的情况下，Doris保持低于20%的CPU使用率，相当于约2.6台云虚拟机。低的CPU使用率使得系统更为稳定，并且能更好地应对突发的写入高峰。

• 高压缩比：Doris 在列式存储的基础上使用了 ZSTD 压缩算法，可以实现 8:1 的压缩比。与 Elasticsearch 的 1.5:1 压缩比相比，Doris 可以将存储成本降低约 80%。
• 分级存储：Doris 提供了一种更经济的方式来存储数据：将热数据存放在本地磁盘，冷数据则存放在对象存储。一旦设置了存储策略，Doris 可以自动管理热数据的“降温”过程，并将冷数据移至对象存储。这种数据生命周期对上层应用是透明的，非常方便用户。此外，Doris 利用本地缓存加快冷数据查询速度。

由于更低的存储成本，Doris 在不影响查询性能的情况下，将单行查询和返回结果集的查询执行速度提高了两倍。在没有采样的聚合查询中，Doris 的运行速度比 Elasticsearch 快四倍。

总的来说，Apache Doris 的查询速度比 Elasticsearch 快 2 到 4 倍，而所需的存储空间只有它的三分之一。

倒排索引就像是日志分析的魔法药水，因为它能显著提升全文检索速度，并减少查询时间。

在这些情况下特别有用：

• 使用 MATCH_ALL，MATCH_ANY 和 MATCH_PHRASE 进行全文搜索。MATCH_PHRASE 结合倒排索引可以作为 Elasticsearch 全文搜索功能的替代选项。
• 支持等值查询（=, !=, IN）、范围查询（>, >=, <, <=）以及数值、日期时间及字符串。

    CREATE TABLE httplog  
    (  
     `ts` DATETIME,  
     `clientip` VARCHAR(20),  
     `request` TEXT,  
     INDEX idx_ip (`clientip`) USING INVERTED,  
     INDEX idx_req (`request`) USING INVERTED PROPERTIES("parser" = "english")   
    )  
    DUPLICATE KEY(`ts`)  
    ...  
    ​  
    -- 查看最新的10条记录，Client IP为"8.8.8.8"  
    SELECT * FROM httplog WHERE clientip = '8.8.8.8' ORDER BY ts DESC LIMIT 10;  
    -- 查找请求字段包含'error'或'404'的最新10条记录  
    SELECT * FROM httplog WHERE request MATCH 任意 'error 404' ORDER BY ts DESC LIMIT 10;  
    -- 查找请求字段同时包含'image'和'faq'的最新10条记录  
    SELECT * FROM httplog WHERE request MATCH 全部 'image faq' ORDER BY ts DESC LIMIT 10;  
    -- 查找请求字段包含'query error'的最新10条记录  
    SELECT * FROM httplog WHERE request MATCH 短语 'query error' ORDER BY ts DESC LIMIT 10;

在全文搜索中，它是一个非常强大的加速器，Doris 的倒排索引因为它能够根据需要灵活调整。而在 Elasticsearch 中，索引一旦创建就不能再改变，因此，在创建时需要谨慎规划需要索引的字段，否则，任何索引的更改都需要重新构建整个索引。

相比之下，Doris 允许动态索引。你可以在运行时添加逆向索引，更改会立刻生效。你还可以选择在哪些数据分区上创建索引。

本质上，一个可观测性平台需要支持动态模式(schema)，因为它收集的数据容易发生变化。用户每次点击网页可能向数据库添加一个新的指标。

浏览数据库领域，你会发现静态结构是常态。一些数据库走得更远。例如，Elasticsearch 通过映射实现了动态结构。然而，这种功能可能因以下原因而中断：字段类型冲突或保留的历史字段。

Doris 新引入了一种名为 Variant 的数据类型，用于动态模式解决方案。GuanceDB 是首批尝试这一功能的数据库之一。(该功能将在 Apache Doris V2.1 版本中正式提供。)

Variant 数据类型是 Doris 引入的半结构化数据分析工具。它可以解决许多常常困扰数据库用户的问题：

• JSON 数据存储：Doris 的 Variant 列可以容纳任何合法的 JSON 数据，并能自动识别子字段及其数据类型。
• 由于字段过多导致的模式膨胀：频繁出现的子字段将以列式存储方式存储，便于分析，而较少出现的子字段则会被合并到同一个列中，简化数据模式。
• 由于数据类型冲突导致的写入失败：Variant 列允许同一字段中包含不同类型的值，并对不同数据类型采用不同的存储。

变体和动态映射的区别

从功能上讲，Doris 中的 Variant 和 Elasticsearch 中的 Dynamic Mapping 来说，最大的区别在于，Dynamic Mapping 的作用范围贯穿整个表的生命周期，而 Variant 的作用范围可以限制在当前数据分区。

例如，如果用户今天更改了业务逻辑并重命名了一些变量子，那么今天之前的分区中仍会保留旧字段名，但是，从明天起新分区中将不再出现这些旧字段名。因此，数据类型冲突的风险较小。

在同一个分区中出现字段类型冲突的情况下，可以将这两个字段改为 JSON 类型以避免数据错误或数据丢失。例如，用户业务系统中有两个 status 字段：一个是字符串，另一个是数值。因此，在查询时，用户可以选择查询字符串字段、数值字段，或者两者一起查询。例如，如果您在过滤器中设置了 status = "ok"，查询将仅针对字符串字段进行。

从用户的角度来说，他们可以像使用其他数据类型一样简单地使用Variant类型。他们可以根据需要添加或删除Variant字段，不需要额外的语法或注释。

目前，Variant 类型需要额外的类型断言，我们计划在未来的 Doris 版本中自动完成这个步骤。相比之下，GuanceDB 在这方面更加领先一步，他们已经在 DQL 查询中实现了自动类型断言。通常，类型断言是根据 Variant 字段的实际数据类型来判断的。在少数类型的冲突情况下，Variant 字段会转换为 JSON 字段，接下来，类型断言将基于 DQL 查询中的操作符含义。

GuanceDB从Elasticsearch转向Apache Doris展示了在提高数据处理速度和降低成本方面的一大进展。为了达到这些目标，Apache Doris在数据集成和数据分析这两大数据处理主要方面进行了优化。它扩展了无模式支持以灵活支持更多数据类型，并引入了诸如倒排索引和分层存储等特性，以实现更快和更经济的查询。进化是一个持续的过程。Apache Doris从未停止自我提升。我们有许多正在开发的新功能，Doris 社区 欢迎任何建议和反馈。

查看 GitHub 上的 Apache Doris,仓库,

在 Slack 上找到 Apache Doris 的开发者