Elasticsearch 作为统一平台：引入第二套数据系统究竟要付出什么代价

作者：来自 Elastic Yannis Roussos 及 Bharath Aleti

在五套系统中分别运行搜索、分析、指标、日志和向量检索，成本远不只是五份许可证。下面看看在实践中使用一个统一平台是什么样的。

如果你统计一下技术栈中的数据引擎数量，就会发现全文搜索运行在一个系统中，而分析运行在数据仓库中。指标存储在时序数据库中，日志则存放在日志聚合器里。向量检索又有自己专用的向量数据库。于是，同一类运营数据的五种形态对应着五套引擎，而许可证费用反而是最便宜的部分。

我们之前在 Elasticsearch 为什么正在成为列式数据库 中介绍过整合这些数据形态背后的架构。本文关注的是账本的另一面：这种拆分实际上要付出什么代价？而"在一个平台上进行搜索和分析"究竟意味着什么？我们希望把这些问题讲清楚，让它们经得起概念验证（PoC）的检验。

运行五套数据引擎的实际成本

任何同时维护两套相同业务账本的人都知道，时间究竟花在哪里。创建第二本账很快，但让两本账保持一致才是真正耗费一周时间的事情。

每套引擎都需要自己的数据摄取路径，因此同一批事件需要被解析两次并发送两次。这意味着你需要面对两套故障模式，当消息代理变慢时，还需要处理两套积压数据。同时还会产生数据漂移：某个字段重命名可能先出现在其中一个副本中，而另一个副本还没有更新。于是，在一段时间内，这两个系统对同一小时的数据会给出不同的结果。解决这种不一致是真实的工程工作，但在商业成本分析中却很少被计算进去。

每套引擎还会带来一套查询语言，而真正的成本并不在语法本身，而在于所有使用这种语言编写的内容，包括 Dashboard、告警规则、保存的查询、运行手册，以及当周负责值班的人员所掌握的运维知识。两套语言意味着所有这些东西都要各维护一套，并行维护。

然后是数据关联问题。你在日志聚合器中找到失败的请求，接着切换到数据仓库，统计它本周发生了多少次，然后再切换到指标存储，检查发生故障时主机是否已经达到资源饱和。这些切换中的每一次关联，实际上都是由一个处于高压状态的人手工完成的一次 Join，而每一次都可能让故障排查多花几分钟。

数据保留策略会进一步放大这些问题。每个系统都有自己的生命周期策略，因此那个成本较低的系统可能还保留着数据，而成本较高的系统早在几周前就已经删除了这些数据。等到你真正需要查看历史数据时，却发现数据存在于那个无法快速回答你问题的引擎中。

为什么搜索和分析会拆分到两个系统

这种拆分是对现实约束的一种合理回应。文档引擎和列式引擎最初就是为了回答不同的问题而构建的。_文档引擎_擅长查找符合查询条件的记录，并按照相关性对它们进行排序；而_列式引擎_擅长从 50 个列中读取其中 3 个，并在数十亿行数据上进行聚合。

多年来，同时运行两套系统是合理的选择，因为没有任何单一系统能够让人信服地同时做好这两类工作。Elasticsearch 9.5 引入完整的列式引擎后，这种拆分就从必需变成了可选。想了解完整的发展历程以及具体发生了哪些变化，可以查看 列式存储文章。

一个统一平台在实践中意味着什么

在"统一平台"真正具有实际意义之前，需要满足三个条件。

1. 第一是统一的_查询语言_ 。Elasticsearch Query Language（ES|QL）可以跨日志、指标、traces、安全事件和文档运行，这意味着只需要掌握一套技能，并维护一套 Dashboard。由于它使用的是一种统一语言，而不是将多个系统联合起来，因此查询可以组合：时间序列聚合可以与 LOOKUP JOIN 或 INLINE STATS 放在同一个查询中，而仅围绕 PromQL 构建的系统无法做到这一点。

2. 第二是统一的_存储基座_。Doc values 是 Elasticsearch 自 2013 年以来就内置的列式存储，也是每种 index mode 底层读写的数据存储结构。不同模式会针对不同的数据形态对这一存储基座进行调优。Elasticsearch 的时间序列引擎（TSDB）在 9.4 中实现了完全列式化，这是目前最明确的证据，证明这种方法确实可行。Columnar Mode 和 Columnar Logs 在 Elasticsearch 9.5 中均处于 technical preview，它们进一步将相同的处理方式扩展到分析型和日志型数据。

3. 第三是统一的_运维体系_。使用的是同一个集群、相同的 API、集成、agents、访问控制、备份和升级路径，这些都是你已经在运行的基础设施。

多种 index mode 共享同一个列式存储，而一种查询语言可以在单个集群中查询所有这些数据。这比"一个引擎解决所有问题"的说法更加严谨，也是经得起实际测试的说法。

什么时候专用数据库仍然是正确的选择？

专用系统在专门的基准测试中始终会占据优势。如果你的工作负载只有一种数据形态和一种查询模式，那么一定会有一个专门为此打造的引擎在这方面胜过我们。与其假装并非如此，我们更愿意坦诚地承认这一点。

整合的价值在于那些跨越多种数据形态的数据，而这正是大多数生产环境的情况。

不过，成为通用平台并不意味着在每一种数据形态上都只能屈居第二。我们已经走过一次这样的发展曲线。TSDB 从 Elasticsearch 8.7 开始就用于存储指标数据，早期的工作重点是提高存储效率，而不是与专用指标存储系统竞争。

随后，从 Elasticsearch 9.1 到 9.4 的一系列版本更新，将它发展成了一个列式指标引擎：现在，OpenTelemetry（OTel）指标每个数据点的存储成本已经降至 3.75 字节，而一年前还是 25 字节；存储成本比 Prometheus 低 2.5 倍，比 ClickHouse 低 2 倍。Gauge 平均值和 Counter rate 查询的速度最高可以达到 Prometheus 和 Mimir 的 30 倍。在高基数基准测试中，Elasticsearch 可以在不到 2 秒的时间内扫描覆盖 50 万条时间序列的 4 小时数据，而其他系统则需要超过 30 秒。完整的方法论和每个查询的结果，请参阅 比 Prometheus 快 30 倍：Elasticsearch 如何重构为领先的列式指标数据存储。

Columnar Mode 正处于同一条发展曲线的起点。Elasticsearch 9.5 中提供 technical preview，并在 Elasticsearch 9.6 中正式发布（GA），后续版本将逐步改进存储、数据摄取和查询性能。

指标数据经过一年的这类工作才达到现在的水平，我们预计日志和分析型数据也会沿着相同的路径发展，而不是用更短的时间完成。

哪些工作负载应该继续使用文档模式

有些工作负载应该保持现状。

1. 以搜索为核心的应用，例如商品目录和知识库。这类场景需要返回排名最靠前的 10 个相关文档，是现有文档模式擅长的领域，而且这些模式都没有被弃用。

2. 频繁进行单个文档更新的工作负载同样适合使用文档模式。

3. 嵌套数据模型 也是如此。如果数据模型确实依赖嵌套结构，那么应该继续使用文档模式，因为 Columnar Mode 会将字段扁平化为 key/value 对，并且不支持 nested 字段类型。在 Elasticsearch 9.5 中，semantic_text 和 dense_vector 字段也无法在 Columnar Mode 中使用；针对向量检索的列式方案将在后续版本推出。

采用 Columnar Mode 是按 index 单独选择并主动启用的。现有 indices 会继续按照当前方式运行，API 不需要改变，而且你的 Dashboard 也不会因此失效。

Columnar Mode 的现状：Elasticsearch 9.5 Preview、9.6 正式发布

存储和性能方面的数据将在另一篇 technical deep dive 中单独介绍。如果你希望反馈自己的工作负载需求，Columnar Mode 和 Columnar Logs 的公开 roadmap issue 是最合适的地方。

如果你想真正量化自己需要为"五套工具"付出的代价，可以先统计两件事：将相同事件发送到多个目标的数据摄取 pipeline 数量 ，以及使用两种不同查询语言回答同一个问题的 Dashboard 数量。在大多数生产环境中，第二个数字往往更让人意外。

本文所述任何功能或特性的发布时间和推出计划均由 Elastic 自行决定。目前尚不可用的功能或特性可能无法按时交付，也可能根本不会交付。

原文：Elasticsearch data platform consolidation | Elasticsearch Labs