从 Elasticsearch 到 Apache Doris：升级可观察性平台

可观察性平台类似于免疫系统。就像免疫细胞在人体中无处不在一样。可观察平台会巡逻设备、组件和架构的每个角落，识别任何潜在威胁并主动缓解它们。然而我这个比喻可能有点过分了，因为直到今天，我们还没有发明出像人体一样复杂的系统，但我们总能取得进步。

升级可观测平台的关键是提高数据处理速度、降低成本。这是基于两个原因：

• 从数据中识别异常的速度越快，就越能遏制潜在的损害。
• 可观测性平台需要存储大量数据，而低存储成本是实现可持续发展的唯一途径。

这篇文章是关于 GuanceDB 这个可观察性平台如何通过用 Apache Doris 替换 Elasticsearch 作为其查询和存储引擎来在这两方面取得进展。结果是存储成本降低了 70%，数据查询性能提高了 200%～400%。

关策数据库

GuanceDB 是一个全方位的可观测性解决方案。它提供包括数据分析、数据可视化、监控警报、安全检查等服务。从 GuanceDB 中，用户可以了解其对象、网络性能、应用程序、用户体验、系统可用性等。

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

数据整合

对于数据集成，GuanceDB 使用其自制工具 DataKit。它是一款一体化数据收集器，可以从不同的终端设备、业务系统、中间件和数据基础设施中提取数据。它还可以预处理数据并将其与元数据关联起来。它为数据提供广泛的支持，从日志、时间序列指标到分布式跟踪数据、安全事件以及来自移动应用程序和 Web 浏览器的用户行为。为了满足多场景的多样化需求，它保证了与各种开源探针和收集器以及自定义格式数据源的兼容性。

查询和存储引擎

DataKit收集的数据经过核心计算层到达 GuanceDB，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：对于查询执行，如果 Doris 支持查询 SQL 语义或函数，Guance-Select 会将查询下推到 Doris Frontend 进行计算；如果没有，它将选择后备选项：通过 Thrift RPC 接口获取 Arrow 格式的柱状数据，然后在 Guance-Select 中完成计算。问题是它无法将计算逻辑下推到 Doris Backend，因此它可能比在 Doris Frontend 中执行查询稍慢。

观察结果

存储成本降低 70%，查询速度提高 300%

此前，Elasticsearch集群使用20个云虚拟机（16vCPU 64GB），并且有独立的索引写入服务（另外20个云虚拟机）。现在使用 Apache Doris，他们总共只需要 13 个相同配置的云虚拟机，成本降低了 67%。这是由 Apache Doris 的三个功能贡献的：

• 高写入吞吐量：在1GB/s的一致写入吞吐量下，Doris保持CPU占用率低于20%。这相当于 2.6 个云虚拟机。CPU占用率低，系统更稳定，更能应对突发的写入高峰。

• 高数据压缩比：Doris在列式存储之上采用ZSTD压缩算法。可实现8:1的压缩比。与 Elasticsearch 中的 1.5:1 相比，Doris 可以降低 80% 左右的存储成本。
• 分层存储：Doris允许以更经济有效的方式存储数据：将热数据放在本地磁盘，冷数据对象存储。一旦设置了存储策略，Doris 就可以自动管理热数据的“冷却”过程，并将冷数据移至对象存储。这样的数据生命周期对于数据应用层来说是透明的，因此对用户友好。此外，Doris 通过本地缓存加速冷数据查询。

由于存储成本较低，Doris 不会影响查询性能。它将返回单行和返回结果集的查询的执行速度提高了一倍。对于无需采样的聚合查询，Doris 的运行速度是 Elasticsearch 的 4 倍。

综上所述，Apache Doris 只消耗 Elasticsearch 1/3 的存储成本，实现了 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`)
...

-- Retrieve the latest 10 records of Client IP "8.8.8.8"
SELECT * FROM httplog WHERE clientip = '8.8.8.8' ORDER BY ts DESC LIMIT 10;
-- Retrieve the latest 10 records with "error" or "404" in the "request" field
SELECT * FROM httplog WHERE request MATCH_ANY 'error 404' ORDER BY ts DESC LIMIT 10;
-- Retrieve the latest 10 records with "image" and "faq" in the "request" field
SELECT * FROM httplog WHERE request MATCH_ALL 'image faq' ORDER BY ts DESC LIMIT 10;
-- Retrieve the latest 10 records with "query error" in the "request" field
SELECT * FROM httplog WHERE request MATCH_PHRASE 'query error' ORDER BY ts DESC LIMIT 10;

作为全文搜索的强大加速器，Doris 中的倒排索引非常灵活，因为我们见证了按需调整的需要。在Elasticsearch中，索引在创建时是固定的，因此需要很好地规划哪些字段需要建立索引，否则，对索引的任何更改都将需要完全重写。

相比之下，Doris 允许动态索引。您可以在运行时为字段添加倒排索引，该索引会立即生效。您还可以决定在哪些数据分区上创建索引。

用于动态模式更改的新数据类型

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

环顾数据库格局，您会发现静态模式是常态。有些数据库更进一步。例如，Elasticsearch通过映射实现动态模式。但是，此功能很容易因字段类型冲突或未过期的历史字段而中断。

Doris 的动态模式解决方案是一种新引入的数据类型：Variant，GuanceDB 是最早尝试它的公司之一。（它将在 Apache Doris V2.1 中正式提供。）

Variant 数据类型是 Doris 拥抱半结构化数据分析的举措。它可以解决很多经常困扰数据库用户的问题：

• JSON 数据存储：Doris中的Variant列可以容纳任何合法的JSON数据，并且可以自动识别子字段和数据类型。
• 字段过多导致模式爆炸：频繁出现的子字段会以列的方式存储，以方便分析，而不太常见的子字段将合并到同一列中，以简化数据模式。
• 数据类型冲突导致写入失败：Variant列允许同一字段存在不同类型的数据，并且针对不同的数据类型采用不同的存储。

变体映射和动态映射之间的区别

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

例如，如果用户今天更改了业务逻辑并重命名了一些 Variant 字段，那么旧的字段名称将保留在今天之前的分区上，但从明天开始将不会出现在新分区上。因此，数据类型冲突的风险较低。

当同一分区的字段类型冲突时，两个字段将更改为JSON类型，以避免数据错误或数据丢失。例如，status用户的业务系统中有两个字段：一个是字符串，一个是数字，那么在查询时，用户可以决定是查询字符串字段，还是查询数字字段，或者两者都查询。（例如，如果您在过滤器中指定status = "ok"，则查询将仅在字符串字段上执行。）

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

目前，Variant 类型需要额外的类型断言，我们计划在 Doris 的未来版本中自动化此过程。GuanceDB在这方面快了一步。他们已经实现了 DQL 查询的自动类型断言。在大多数情况下，类型断言基于 Variant 字段的实际数据类型。在极少数情况下，当存在类型冲突时，Variant 字段将升级为 JSON 字段，然后类型断言将基于 DQL 查询中运算符的语义。

结论

GuanceDB 从 Elasticsearch 到 Apache Doris 的过渡展示了在提高数据处理速度和降低成本方面的一大进步。为此，Apache Doris 在数据处理的两个主要方面进行了自身优化：数据集成和数据分析。它扩展了无模式支持，以灵活地容纳更多数据类型，引入了倒排索引和分层存储等功能，以实现更快、更经济高效的查询。进化是一个持续的过程。Apache Doris 从未停止过自我完善。我们正在开发许多新功能，Doris社区欢迎任何意见和反馈。

原文作者：Apache Doris