作者：來自 Elastic?Sean Story
從二進制文件中提取內(nèi)容是一個常見的用例。一些 PDF 文件可能非常龐大 — 考慮到幾 GB 甚至更多。Elastic 在處理此類文檔方面已經(jīng)取得了長足的進步，今天，我們很高興地介紹我們的新工具 —— 數(shù)據(jù)提取服務：
- 發(fā)布于 8.9 版本，
- 截至目前，沒有報告任何錯誤！
- 截至今天，代碼是免費且開放的！
為了將這一切放在其背景下，本博客將帶領(lǐng)你了解我們的旅程如何走到了這一步：
從在 Workplace Search 中使用 Apache Tika 作為庫開始，具有 20 MB 的下載限制 通過利用 Elasticsearch 附件處理器，繞過此限制，將其提升至 100 MB 通過我們的新工具——數(shù)據(jù)提取服務，徹底摧毀限制，攝取以 GB 為單位的文件內(nèi)容 我們對未來發(fā)展的愿景
- 首先使用 Apache Tika 作為 Workplace Search 中的庫，下載限制為 20 MB
- 利用 Elasticsearch attachment processor 突破此限制并達到 100 MB
- 使用我們的新工具數(shù)據(jù)提取服務完全消除限制并提取千兆字節(jié)的文件內(nèi)容
- 我們對未來發(fā)展的愿望
背景
在 Elastic 公司，特別是在搜索團隊中，我們長期以來一直致力于從二進制數(shù)據(jù)格式中提取和檢索文本數(shù)據(jù)。大量企業(yè)數(shù)據(jù)存在于 PDF、Microsoft Word 文檔、Powerpoint 演示文稿等格式中。如果你從未嘗試過使用 vim、nano 或 cat 打開這些文件，你可能會驚訝地發(fā)現(xiàn)，這些文件并不是以人類可讀的文本形式存儲在你的硬盤上。
上面的圖像是當你在 Mac 上使用 TextEdit 應用程序?qū)卧~ “test” 保存為 Microsoft Word 2007 (.docx) 文檔，并嘗試在 nano 中打開時所得到的結(jié)果。
與深入研究不同格式及其結(jié)構(gòu)的細節(jié)相比，這里要強調(diào)的是，當我們談論 “二進制” 內(nèi)容時，指的就是這樣的內(nèi)容。這些內(nèi)容的字節(jié)實際上不是人類可讀的字符串，與 .txt、.rtf、.md、.html、.csv 等格式的情況不同。
為什么這很重要？
相關(guān)性
搜索相關(guān)性幾乎是我們在 Elastic 所做的一切的核心。 為了使文本搜索具有相關(guān)性，Elasticsearch 確實需要文本數(shù)據(jù)。 雖然我絕對可以對上述 .docx 內(nèi)容進行 Base64 編碼并將其發(fā)送到 Elasticsearch，但它們在索引中不會非常有價值，并且對字符串 “test” 的任何查詢都不會匹配這樣的文檔。
因此，如果我們想要在企業(yè)數(shù)據(jù)上實現(xiàn)良好的搜索體驗，我們就需要能夠從這些二進制格式中提取出純文本內(nèi)容。
這就是 Apache Tika 登場的原因。這個開源庫一直是文本提取的黃金標準，貫穿了我的整個職業(yè)生涯（約自2014年起），盡管它至少從 2007 年就存在了。建立在 JVM 上，Tika 相對容易實現(xiàn)以下功能：
- 判斷給定字節(jié)序列是否是垃圾數(shù)據(jù)或與已知格式規(guī)范匹配
- 如果匹配任何已知格式，則識別匹配的格式是哪種
- 如果匹配已知格式，則根據(jù)該格式解析數(shù)據(jù)，并提取文本和元數(shù)據(jù)屬性
因此，有一個穩(wěn)定的、行業(yè)標準的工具適用于各種格式。問題在哪里呢？為什么這個主題值得寫成博客文章呢？
架構(gòu)和性能。
在 Elastic，我們重視 speed、scale、relevance。我們已經(jīng)在注意到在搜索時，與二進制內(nèi)容相比，文本內(nèi)容更受青睞時部分解決了相關(guān)性的問題。接下來，讓我們談談規(guī)模。
規(guī)模
在我上述的 .docx 文件中的 “test” 示例中，文件內(nèi)容為 3.4KB。同一個 “test” 字符串在 .txt 文件中只有 4B。這是存儲大小的 x850 增加！此外，當讀入 Java 對象內(nèi)存模型（Tika 用于解析的）時，這很可能會顯著擴展。這意味著，在代表性的數(shù)據(jù)規(guī)模上，內(nèi)存問題變得非常真實。看到幾 MB 大小的 PDF 并不罕見，甚至看到幾 GB 大小的 PDF 也并非聞所未聞。所有這些數(shù)據(jù)都是文本數(shù)據(jù)嗎？幾乎可以肯定不是。我最喜歡的一個事實是，托爾斯泰的整部小說《戰(zhàn)爭與和平》只有大約 3MB 的純文本。希望沒有太多的辦公文檔超過 60萬字。但即使輸出的純文本幾乎可以保證只在 MB 級別，這也不保證解析原始文件所需的 RAM 會這么低。根據(jù)解析器以及你的代碼讀取它的智能程度，你可能需要將整個文件保存在內(nèi)存中，使用 Java 對象模型。你可能還需要它的多個副本。考慮到以上情況，這意味著，在實踐中，你通常需要 GB 級別的 RAM（特別是對于 Java/Tika 來說是 “堆”），以確保一個異常的大文件不會導致你的整個進程崩潰。
速度
現(xiàn)在，讓我們談談速度。如果我有 N 份文檔要處理，處理它們的最快方式是 “并行化” —— 同時處理多個（或全部）文檔。這在很大程度上受到規(guī)模的影響。如果 N=10，而給定文檔大約需要 1 秒鐘處理時間，那么等待 10 秒可能并不算長。但如果 N=1,000,000,000，那么 31 年很可能就太慢了。因此，在大規(guī)模情況下，需要更大的并行化。
然而，當考慮到我們上面討論的規(guī)模的內(nèi)存成本時，這就加劇了你的內(nèi)存需求。一次處理一份文檔可能只需要幾 GB 的內(nèi)存來應對最糟糕的情況，但如果我試圖同時并行處理 1000 份文檔，我可能突然發(fā)現(xiàn)自己需要 TB 級別的 RAM 來應對最糟糕的情況。
有了這個背景，不難理解為什么 Workplace Search，自 7.6.0 起就是 Elastic 提供的產(chǎn)品之一，始終對從二進制文檔中提取文本的并行處理和文檔大小設置了相當嚴格的限制。每個內(nèi)容源一次只能處理一個二進制文檔，將二進制文檔的輸入大小限制在 20 MB 以內(nèi)，甚至將輸出長度限制在 100KB（默認情況下 - 這是可配置的）。這些限制相當保守，但考慮到處理任何二進制文件的 JVM 是運行 Enterprise Search 服務器及其所有其他后臺工作的同一個 JVM，這些限制是有道理的。因此，Workplace Search 必須非常小心，不要消耗超過其份額的資源，或者冒著影響其他 Enterprise Search 功能的風險。
這些保守的限制，連同其他因素，是我們正在努力將客戶從 Workplace Search 轉(zhuǎn)移出去的部分原因。（要了解更多關(guān)于這種轉(zhuǎn)變的信息，請查看 Workplace Search 的演變博客文章。）在過去幾年中，我們看到越來越多的客戶需要處理大量文檔，像 Workplace Search 那樣一次只處理一個文檔已經(jīng)不夠用了。
引入附件處理器（Attachment Processor）。最初是作為單獨安裝的 Elasticsearch 插件，附件處理器也利用 Apache Tika 從二進制文檔中提取純文本。然而，與 Workplace Search 中的文本提取不同，這個工具運行在 Elasticsearch 內(nèi)部，并且可以在 Elastic Ingest Pipelines 中利用。搜索團隊開始在大約 8.3.0 版本時大量使用 Ingest Pipelines，首先是在我們的 App Search Crawler 中，然后是在我們的 Connector Packages 中，最近是在我們的 Native 和 Client Connectors 中。將其用于我們的架構(gòu)帶來了一些好處：
- Elasticsearch 不需要將文檔的輸入大小限制在區(qū)區(qū) 20MB。
- Elasticsearch 已經(jīng)建立了在攝取時進行分布式處理的能力，通過其 Ingest Nodes（這意味著我們可以輕松地水平擴展，并一次處理多于 1 份文檔）
- 通過使用 Elasticsearch 的一個功能，我們可以確保我們的文本提取行為與其他 Elastic 使用案例保持一致。
這對我們的新連接器尤其重要，這些新連接器旨在運行在 Enterprise Search 服務器之外，并且不應該被限制在單一生態(tài)系統(tǒng)中。通過使用 Elasticsearch 進行文本提取，我們?nèi)コ宋覀兊倪B接器內(nèi)部需要運行 Tika（記得是 JVM 嗎？）的要求，但通過不更換工具，仍然保持了一致的文本提取行為。
這無疑幫助我們提高了攝取速度，并成為我們策略中的一個重要部分，持續(xù)了多個版本。在查看附件處理器的一些遙測數(shù)據(jù)后，很明顯，Enterprise Search 使用它的份額是最大的。鑒于我們所有的連接器和爬蟲默認使用附件處理器，這并不令人驚訝。它是我們 ent-search-generic-ingestion 管道中的第一個處理器 —— 所有新連接器和爬蟲的默認管道。
事實上，附件處理器對我們的用例變得如此重要，以至于我們是將附件插件轉(zhuǎn)換為開箱即用的模塊（自動隨 Elasticsearch 一起使用）的驅(qū)動動機。
然而，這也帶來了一些權(quán)衡。
首先，雖然 Elasticsearch 沒有我們在企業(yè)搜索中遇到的同樣的 20MB 限制，但它確實有一個最大負載大小的硬性限制為 100MB（由 http.max_content_length 定義）。你可以通過多部分表單數(shù)據(jù)來繞過這一限制，但 Elasticsearch 核心開發(fā)者強烈建議我們不要追求這種思路，因為 100MB 的限制是有其原因的。實際上，雖然這個限制在技術(shù)上是可配置的，我們強烈建議不要增加它，因為我們歷史上觀察到這樣做可能會大大降低 Elasticsearch 集群的穩(wěn)定性。
其次，雖然 Workplace Search 過于積極地處理二進制文件可能導致企業(yè)搜索服務器失敗，但如果附件處理器被賦予過大的工作量，它可能會威脅到 Elasticsearch 集群的健康。通常情況下，這種情況更糟。雖然 Elasticsearch 能夠在攝入時進行分布式處理（CPU）工作負載，但這不是它的主要關(guān)注點。Elasticsearch 主要設計用于搜索，其進行分布式處理的能力不是主要焦點。它不應該（也不會）為處理多個大型 PDF 文件的重型工作負載而優(yōu)化。
相反，我們的團隊轉(zhuǎn)向了一種新的方法 —— 構(gòu)建一個專門用于二進制內(nèi)容提取的獨立服務，該服務在當前的一系列流程之外運行。
介紹：數(shù)據(jù)提取服務
這項服務是在 Elastic 8.9.0 版本發(fā)布時（作為 Beta 版本）推出的。它是一個專用的獨立服務器，能夠通過 REST API 接收你的二進制文檔作為輸入，并響應其純文本內(nèi)容，以及一些最小的元數(shù)據(jù)。
通過將該流程與我們的連接器和 Elasticsearch 分離開來，我們創(chuàng)建了一個可以輕松水平擴展的服務。這樣，成本和速度之間的權(quán)衡就可以輕松控制，你不必為其中一個進行優(yōu)化而被束縛。
此外，該服務的分離允許你在邊緣附近部署它，以避免大型文件負載的額外網(wǎng)絡跳躍。通過在連接器和數(shù)據(jù)提取服務在同一文件系統(tǒng)上共存時利用文件指針，我們可以完全消除從源系統(tǒng)獲取文件后通過網(wǎng)絡發(fā)送文件的需求。
目前，該服務主要只是 Tika Server 的一個包裝器。然而，我們希望（有一天）能夠?qū)ξ覀內(nèi)绾谓馕?處理每種文件類型進行細粒度控制。也許對于某些文件類型 X，有些工具比 Tika 更高效。例如，一些個別證據(jù)表明，工具 pdf2txt 在解析 PDF 文件時可能比 Tika 更有效率。如果進一步的實驗證實了這一點，那么使用最適合工作的工具將有利于我們的產(chǎn)品。
我們通過將數(shù)據(jù)提取服務構(gòu)建為一個可以定義自己 REST API 的 Nginx 反向代理，并動態(tài)將傳入請求路由到各種后端來為此做了架構(gòu)設計。這是通過一些自定義的 Lua 腳本實現(xiàn)的（這是 Nginx 的一個特性）。
此工具的初步反饋極為正面。到目前為止，我們收到的 “bug” 報告只有：
- 找到它的 Docker 鏡像太難了。
- 代碼不是開源的。
我們收到的增強功能請求要多得多，我們很興奮能夠優(yōu)先考慮這些請求，這也顯示了人們對這個項目有多少熱情。
不過，關(guān)于錯誤，我們已經(jīng)修復了 docker 映像的歧義，你現(xiàn)在可以在這里輕松瀏覽我們的所有工件：https://www.docker.elastic.co/r/enterprise-search/data-extraction-service。 關(guān)于源代碼，我非常高興地宣布 GitHub 存儲庫現(xiàn)已公開 - 使數(shù)據(jù)提取服務代碼免費且開放！
接下來呢？
首先，我們希望通過開放代碼倉庫，進一步吸引我們充滿熱情的用戶社區(qū)。我們希望集中處理增強功能請求，并開始征集更多的公開反饋。我們絕對歡迎社區(qū)的貢獻！我們相信，這是確保這個項目繼續(xù)有機演進，使所有人受益的最佳方式。
長遠愿景是什么？
注意，Elastic 并沒有承諾這一點。整個團隊甚至可能不會完全同意。但是出于熱情的原因，我想與你分享我的個人愿景。
我希望將這項服務發(fā)展到不僅僅是從辦公文檔中提取純文本?？伤阉鞯臄?shù)據(jù)存在于圖像（掃描/復印的文檔、圖形橫幅/幻燈片）、音頻文件（音樂、播客、有聲書、電話錄音、Zoom 音頻）和視頻文件（電影、電視節(jié)目、Zoom 視頻）中。即使是純文本中也包含了嵌入其中的次文本數(shù)據(jù)，可以通過現(xiàn)代機器學習技術(shù)（情感分析、實體識別、語義文本、GenAI）來訪問。所有這些都共享著需要大文件和文檔處理來實現(xiàn)一流搜索體驗的共同問題。它們都將受益于 Elasticsearch 提供的相關(guān)搜索，但可能不都適合于需要大量 CPU 的攝入工作負載。所有這些都可能受益于擁有一個專用的、水平可擴展的提取服務，可以位于 “邊緣”，以改善大規(guī)模攝入速度。
這還不是現(xiàn)實。 這是一個目標。 一顆北極星。 隨著我們越來越接近愿景，愿景可能會發(fā)生變化，但這不會阻止我們朝著目標邁出戰(zhàn)略性的小步驟。
如果你想幫助我們實現(xiàn)這一目標，請訪問 https://github.com/elastic/data-extraction-service，并加入該項目。 歡迎新貢獻者。
準備好將 RAG 構(gòu)建到你的應用程序中了嗎？ 想要嘗試使用向量數(shù)據(jù)庫的不同 LLMs？
在 Github 上查看我們的 LangChain、Cohere 等示例筆記本，并參加即將開始的 Elasticsearch 工程師培訓！文章來源：http://www.zghlxwxcb.cn/news/detail-846797.html
原文：Evolving How We Ingest Binary Document Formats — Elastic Search Labs文章來源地址http://www.zghlxwxcb.cn/news/detail-846797.html
到了這里，關(guān)于Elasticsearch：我們?nèi)绾窝莼幚矶M制文檔格式的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
