大连网站制作的公司哪家好,厦门移动网站建设哪家专业,免费网站制作作业,wordpress 小论坛作者#xff1a;来自 Elastic Sean Story
从二进制文件中提取内容是一个常见的用例。一些 PDF 文件可能非常庞大 — 考虑到几 GB 甚至更多。Elastic 在处理此类文档方面已经取得了长足的进步#xff0c;今天#xff0c;我们很高兴地介绍我们的新工具 —— 数据提取服务来自 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 相对容易实现以下功能
判断给定字节序列是否是垃圾数据或与已知格式规范匹配如果匹配任何已知格式则识别匹配的格式是哪种如果匹配已知格式则根据该格式解析数据并提取文本和元数据属性
因此有一个稳定的、行业标准的工具适用于各种格式。问题在哪里呢为什么这个主题值得写成博客文章呢
架构和性能。
在 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 份文档要处理处理它们的最快方式是 “并行化” —— 同时处理多个或全部文档。这在很大程度上受到规模的影响。如果 N10而给定文档大约需要 1 秒钟处理时间那么等待 10 秒可能并不算长。但如果 N1,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 中。将其用于我们的架构带来了一些好处
Elasticsearch 不需要将文档的输入大小限制在区区 20MB。Elasticsearch 已经建立了在摄取时进行分布式处理的能力通过其 Ingest Nodes这意味着我们可以轻松地水平扩展并一次处理多于 1 份文档通过使用 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” 报告只有
找到它的 Docker 镜像太难了。代码不是开源的。
我们收到的增强功能请求要多得多我们很兴奋能够优先考虑这些请求这也显示了人们对这个项目有多少热情。
不过关于错误我们已经修复了 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
