Elasticsearch：我们如何演化处理二进制文档格式

作者：来自 Elastic Sean Story

从二进制文件中提取内容是一个常见的用例。一些 PDF 文件可能非常庞大 — 考虑到几 GB 甚至更多。Elastic 在处理此类文档方面已经取得了长足的进步，今天，我们很高兴地介绍我们的新工具 —— 数据提取服务：

• 发布于 8.9 版本，
• 截至目前，没有报告任何错误！
• 截至今天，代码是免费且开放的！

为了将这一切放在其背景下，本博客将带领你了解我们的旅程如何走到了这一步：

从在 Workplace Search 中使用 Apache Tika 作为库开始，具有 20 MB 的下载限制 通过利用 Elasticsearch 附件处理器，绕过此限制，将其提升至 100 MB 通过我们的新工具——数据提取服务，彻底摧毁限制，摄取以 GB 为单位的文件内容 我们对未来发展的愿景

• 首先使用 Apache Tika 作为 Workplace Search 中的库，下载限制为 20 MB
• 利用 Elasticsearch attachment processor 突破此限制并达到 100 MB
• 使用我们的新工具数据提取服务完全消除限制并提取千兆字节的文件内容
• 我们对未来发展的愿望

背景

在 Elastic 公司，特别是在搜索团队中，我们长期以来一直致力于从二进制数据格式中提取和检索文本数据。大量企业数据存在于 PDF、Microsoft Word 文档、Powerpoint 演示文稿等格式中。如果你从未尝试过使用 vim、nano 或 cat 打开这些文件，你可能会惊讶地发现，这些文件并不是以人类可读的文本形式存储在你的硬盘上。

上面的图像是当你在 Mac 上使用 TextEdit 应用程序将单词 “test” 保存为 Microsoft Word 2007 (.docx) 文档，并尝试在 nano 中打开时所得到的结果。

与深入研究不同格式及其结构的细节相比，这里要强调的是，当我们谈论 “二进制” 内容时，指的就是这样的内容。这些内容的字节实际上不是人类可读的字符串，与 .txt、.rtf、.md、.html、.csv 等格式的情况不同。

为什么这很重要？

相关性

搜索相关性几乎是我们在 Elastic 所做的一切的核心。 为了使文本搜索具有相关性，Elasticsearch 确实需要文本数据。 虽然我绝对可以对上述 .docx 内容进行 Base64 编码并将其发送到 Elasticsearch，但它们在索引中不会非常有价值，并且对字符串 “test” 的任何查询都不会匹配这样的文档。

因此，如果我们想要在企业数据上实现良好的搜索体验，我们就需要能够从这些二进制格式中提取出纯文本内容。

这就是 Apache Tika 登场的原因。这个开源库一直是文本提取的黄金标准，贯穿了我的整个职业生涯（约自2014年起），尽管它至少从 2007 年就存在了。建立在 JVM 上，Tika 相对容易实现以下功能：

1. 判断给定字节序列是否是垃圾数据或与已知格式规范匹配
2. 如果匹配任何已知格式，则识别匹配的格式是哪种
3. 如果匹配已知格式，则根据该格式解析数据，并提取文本和元数据属性

因此，有一个稳定的、行业标准的工具适用于各种格式。问题在哪里呢？为什么这个主题值得写成博客文章呢？

架构和性能。

在 Elastic，我们重视 speed、scale、relevance。我们已经在注意到在搜索时，与二进制内容相比，文本内容更受青睐时部分解决了相关性的问题。接下来，让我们谈谈规模。

规模

在我上述的 .docx 文件中的 “test” 示例中，文件内容为 3.4KB。同一个 “test” 字符串在 .txt 文件中只有 4B。这是存储大小的 x850 增加！此外，当读入 Java 对象内存模型（Tika 用于解析的）时，这很可能会显著扩展。这意味着，在代表性的数据规模上，内存问题变得非常真实。看到几 MB 大小的 PDF 并不罕见，甚至看到几 GB 大小的 PDF 也并非闻所未闻。所有这些数据都是文本数据吗？几乎可以肯定不是。我最喜欢的一个事实是，托尔斯泰的整部小说《战争与和平》只有大约 3MB 的纯文本。希望没有太多的办公文档超过 60万字。但即使输出的纯文本几乎可以保证只在 MB 级别，这也不保证解析原始文件所需的 RAM 会这么低。根据解析器以及你的代码读取它的智能程度，你可能需要将整个文件保存在内存中，使用 Java 对象模型。你可能还需要它的多个副本。考虑到以上情况，这意味着，在实践中，你通常需要 GB 级别的 RAM（特别是对于 Java/Tika 来说是 “堆”），以确保一个异常的大文件不会导致你的整个进程崩溃。

速度

现在，让我们谈谈速度。如果我有 N 份文档要处理，处理它们的最快方式是 “并行化” —— 同时处理多个（或全部）文档。这在很大程度上受到规模的影响。如果 N=10，而给定文档大约需要 1 秒钟处理时间，那么等待 10 秒可能并不算长。但如果 N=1,000,000,000，那么 31 年很可能就太慢了。因此，在大规模情况下，需要更大的并行化。

然而，当考虑到我们上面讨论的规模的内存成本时，这就加剧了你的内存需求。一次处理一份文档可能只需要几 GB 的内存来应对最糟糕的情况，但如果我试图同时并行处理 1000 份文档，我可能突然发现自己需要 TB 级别的 RAM 来应对最糟糕的情况。

有了这个背景，不难理解为什么 Workplace Search，自 7.6.0 起就是 Elastic 提供的产品之一，始终对从二进制文档中提取文本的并行处理和文档大小设置了相当严格的限制。每个内容源一次只能处理一个二进制文档，将二进制文档的输入大小限制在 20 MB 以内，甚至将输出长度限制在 100KB（默认情况下 - 这是可配置的）。这些限制相当保守，但考虑到处理任何二进制文件的 JVM 是运行 Enterprise Search 服务器及其所有其他后台工作的同一个 JVM，这些限制是有道理的。因此，Workplace Search 必须非常小心，不要消耗超过其份额的资源，或者冒着影响其他 Enterprise Search 功能的风险。

这些保守的限制，连同其他因素，是我们正在努力将客户从 Workplace Search 转移出去的部分原因。（要了解更多关于这种转变的信息，请查看 Workplace Search 的演变博客文章。）在过去几年中，我们看到越来越多的客户需要处理大量文档，像 Workplace Search 那样一次只处理一个文档已经不够用了。

引入附件处理器（Attachment Processor）。最初是作为单独安装的 Elasticsearch 插件，附件处理器也利用 Apache Tika 从二进制文档中提取纯文本。然而，与 Workplace Search 中的文本提取不同，这个工具运行在 Elasticsearch 内部，并且可以在 Elastic Ingest Pipelines 中利用。搜索团队开始在大约 8.3.0 版本时大量使用 Ingest Pipelines，首先是在我们的 App Search Crawler 中，然后是在我们的 Connector Packages 中，最近是在我们的 Native 和 Client Connectors 中。将其用于我们的架构带来了一些好处：

1. Elasticsearch 不需要将文档的输入大小限制在区区 20MB。
2. Elasticsearch 已经建立了在摄取时进行分布式处理的能力，通过其 Ingest Nodes（这意味着我们可以轻松地水平扩展，并一次处理多于 1 份文档）
3. 通过使用 Elasticsearch 的一个功能，我们可以确保我们的文本提取行为与其他 Elastic 使用案例保持一致。

这对我们的新连接器尤其重要，这些新连接器旨在运行在 Enterprise Search 服务器之外，并且不应该被限制在单一生态系统中。通过使用 Elasticsearch 进行文本提取，我们去除了我们的连接器内部需要运行 Tika（记得是 JVM 吗？）的要求，但通过不更换工具，仍然保持了一致的文本提取行为。

这无疑帮助我们提高了摄取速度，并成为我们策略中的一个重要部分，持续了多个版本。在查看附件处理器的一些遥测数据后，很明显，Enterprise Search 使用它的份额是最大的。鉴于我们所有的连接器和爬虫默认使用附件处理器，这并不令人惊讶。它是我们 ent-search-generic-ingestion 管道中的第一个处理器 —— 所有新连接器和爬虫的默认管道。

事实上，附件处理器对我们的用例变得如此重要，以至于我们是将附件插件转换为开箱即用的模块（自动随 Elasticsearch 一起使用）的驱动动机。

然而，这也带来了一些权衡。

首先，虽然 Elasticsearch 没有我们在企业搜索中遇到的同样的 20MB 限制，但它确实有一个最大负载大小的硬性限制为 100MB（由 http.max_content_length 定义）。你可以通过多部分表单数据来绕过这一限制，但 Elasticsearch 核心开发者强烈建议我们不要追求这种思路，因为 100MB 的限制是有其原因的。实际上，虽然这个限制在技术上是可配置的，我们强烈建议不要增加它，因为我们历史上观察到这样做可能会大大降低 Elasticsearch 集群的稳定性。

其次，虽然 Workplace Search 过于积极地处理二进制文件可能导致企业搜索服务器失败，但如果附件处理器被赋予过大的工作量，它可能会威胁到 Elasticsearch 集群的健康。通常情况下，这种情况更糟。虽然 Elasticsearch 能够在摄入时进行分布式处理（CPU）工作负载，但这不是它的主要关注点。Elasticsearch 主要设计用于搜索，其进行分布式处理的能力不是主要焦点。它不应该（也不会）为处理多个大型 PDF 文件的重型工作负载而优化。

相反，我们的团队转向了一种新的方法 —— 构建一个专门用于二进制内容提取的独立服务，该服务在当前的一系列流程之外运行。

介绍：数据提取服务

这项服务是在 Elastic 8.9.0 版本发布时（作为 Beta 版本）推出的。它是一个专用的独立服务器，能够通过 REST API 接收你的二进制文档作为输入，并响应其纯文本内容，以及一些最小的元数据。

通过将该流程与我们的连接器和 Elasticsearch 分离开来，我们创建了一个可以轻松水平扩展的服务。这样，成本和速度之间的权衡就可以轻松控制，你不必为其中一个进行优化而被束缚。

此外，该服务的分离允许你在边缘附近部署它，以避免大型文件负载的额外网络跳跃。通过在连接器和数据提取服务在同一文件系统上共存时利用文件指针，我们可以完全消除从源系统获取文件后通过网络发送文件的需求。

目前，该服务主要只是 Tika Server 的一个包装器。然而，我们希望（有一天）能够对我们如何解析/处理每种文件类型进行细粒度控制。也许对于某些文件类型 X，有些工具比 Tika 更高效。例如，一些个别证据表明，工具 pdf2txt 在解析 PDF 文件时可能比 Tika 更有效率。如果进一步的实验证实了这一点，那么使用最适合工作的工具将有利于我们的产品。

我们通过将数据提取服务构建为一个可以定义自己 REST API 的 Nginx 反向代理，并动态将传入请求路由到各种后端来为此做了架构设计。这是通过一些自定义的 Lua 脚本实现的（这是 Nginx 的一个特性）。

此工具的初步反馈极为正面。到目前为止，我们收到的 “bug” 报告只有：

1. 找到它的 Docker 镜像太难了。
2. 代码不是开源的。

我们收到的增强功能请求要多得多，我们很兴奋能够优先考虑这些请求，这也显示了人们对这个项目有多少热情。

不过，关于错误，我们已经修复了 docker 映像的歧义，你现在可以在这里轻松浏览我们的所有工件：https://www.docker.elastic.co/r/enterprise-search/data-extraction-service。 关于源代码，我非常高兴地宣布 GitHub 存储库现已公开 - 使数据提取服务代码免费且开放！

接下来呢？

首先，我们希望通过开放代码仓库，进一步吸引我们充满热情的用户社区。我们希望集中处理增强功能请求，并开始征集更多的公开反馈。我们绝对欢迎社区的贡献！我们相信，这是确保这个项目继续有机演进，使所有人受益的最佳方式。

长远愿景是什么？

注意，Elastic 并没有承诺这一点。整个团队甚至可能不会完全同意。但是出于热情的原因，我想与你分享我的个人愿景。

我希望将这项服务发展到不仅仅是从办公文档中提取纯文本。可搜索的数据存在于图像（扫描/复印的文档、图形横幅/幻灯片）、音频文件（音乐、播客、有声书、电话录音、Zoom 音频）和视频文件（电影、电视节目、Zoom 视频）中。即使是纯文本中也包含了嵌入其中的次文本数据，可以通过现代机器学习技术（情感分析、实体识别、语义文本、GenAI）来访问。所有这些都共享着需要大文件和文档处理来实现一流搜索体验的共同问题。它们都将受益于 Elasticsearch 提供的相关搜索，但可能不都适合于需要大量 CPU 的摄入工作负载。所有这些都可能受益于拥有一个专用的、水平可扩展的提取服务，可以位于 “边缘”，以改善大规模摄入速度。

这还不是现实。 这是一个目标。 一颗北极星。 随着我们越来越接近愿景，愿景可能会发生变化，但这不会阻止我们朝着目标迈出战略性的小步骤。

如果你想帮助我们实现这一目标，请访问 https://github.com/elastic/data-extraction-service，并加入该项目。 欢迎新贡献者。

准备好将 RAG 构建到你的应用程序中了吗？ 想要尝试使用向量数据库的不同 LLMs？
在 Github 上查看我们的 LangChain、Cohere 等示例笔记本，并参加即将开始的 Elasticsearch 工程师培训！

原文：Evolving How We Ingest Binary Document Formats — Elastic Search Labs