背景

《搜索引擎onesearch1.0-設(shè)計與實現(xiàn).docx》介紹了1.0特性，表達(dá)式搜索，搜索schema，agg，映射等，同時附錄介紹未來規(guī)劃，其主要特性是文檔索引，隨著分布式dataX完成，技術(shù)基礎(chǔ)已完備。

本文介紹分布式文檔索引，包括tika的原理源碼分析

關(guān)鍵詞

Tika原理源碼分析，內(nèi)容類型識別，內(nèi)容抓取，分布式datax

參考資料

《搜索引擎onesearch 1.0-設(shè)計與實現(xiàn).docx》

《分布式dataX架構(gòu)設(shè)計》

《分布式dataX詳細(xì)(落地)設(shè)計》

規(guī)劃特性與發(fā)布計劃

M1 大規(guī)模/分布式文件索引

• 文檔抓取

1. 文檔內(nèi)容抓取組件，metadata(base+extras)+content

2. 抓取組件隔離機(jī)制

• 索引引擎，基于分布式dataX，支持批量/增量

M2 精確搜索/多元搜索

• 裝配/映射 增加支持query，目前已支持映射為filter

1. full text查詢映射策略

match

match_phrase

query_string

。。。

2. 高亮 (已有，未測試)

3. 返回字段，目前全返回

4. 批量操作，引擎層已實現(xiàn)

5. nested查詢, nested索引已支持

• springboot starter

M3 智能搜索

• 搜索權(quán)限，搜出就能看到

• 聯(lián)想詞

1. 自動糾正

2. 自動補(bǔ)全

onesearch總體架構(gòu)

• schema模塊，定義索引字段，索引策略，搜索策略等，管理索引及其搜索特性

• 聚合搜索(agg)模塊，基于schema模塊，支持xml定義agg，零編碼增加agg主題

• 查詢模塊，負(fù)責(zé)構(gòu)建通用表達(dá)式(如，((f1=‘a(chǎn)’or f2=’b’)and f3=‘c’))，作為搜索輸入條件

• 映射引擎，映射通用表達(dá)式為最優(yōu)的es dsl，支持=，!=，like，in，range，prefix，not/and/or，大小括號，點(.)等操作符映射，解決es dsl難使用，難復(fù)用的痛點

• 抽象搜索引擎接口，無縫接入不同的搜索引擎，如，elasticsearch，opensearch，solrcloud等，更可同時使用多種引擎

• 同步，全量同步/增量同步，接入分布式dataX

索引組件架構(gòu)

下圖是面向索引組件的架構(gòu)視圖

索引組件實現(xiàn)為dataX的reader/writer，接入分布式dataX，實現(xiàn)高吞吐，分布式的文檔索引

內(nèi)容抓取組件文檔遍歷/內(nèi)容抓取，引入tika

搜索引擎支持批量操作的索引服務(wù)，自定義索引策略，索引模式

內(nèi)容抓取組件

內(nèi)容抓取是索引的第一步，抓取文檔屬性和內(nèi)容

tika分析

引入tika作為內(nèi)容抓取引擎，分析一下tika原理

下面詳細(xì)介紹各個模塊

配置(config)

TikaConfig 兩個職責(zé)，配置容器(xml格式)；Detector，Parser等組件的構(gòu)建工廠

TikaConfig提供默認(rèn)即可用的配置，同時支持用戶自定義配置

TikaConfig構(gòu)建的Detector，Parser都是Composite類型對象，Composite類型對象聚合不同的實現(xiàn)，使用規(guī)則，策略調(diào)用具體的探測器和分析器，盡可能提高成功率

XmlLoader 對應(yīng)TikaConfig的兩個職能，配置容器和對象構(gòu)造

XmlLoader 構(gòu)建組件，特別地，支持構(gòu)建復(fù)合類型組件，4個主要的方法

loadOverall 讀取輸入的配置，調(diào)用loadOne構(gòu)建單個(非復(fù)合類型)組件；調(diào)用createComposite，傳入組件集合，構(gòu)建組件復(fù)合類型的實例

loadOne 構(gòu)建單個組件，實際可能返回復(fù)合類型，loadOverall方法有判斷處理

createComposite 具體組件具體實現(xiàn)，利用反射，構(gòu)造函數(shù)構(gòu)建對象實例

createDefault 沒有輸入配置，默認(rèn)構(gòu)建方法，使用ServiceLoader載入組件類型，構(gòu)建復(fù)合類型實例

類型(mime)

Tika內(nèi)容類型數(shù)據(jù)庫，支持自定義；

內(nèi)容類型識別，文件名模式；針對xml類型文檔的root xml；magic code

MediaType 封裝最原始的類型定義，type/subtype；name=value

MimeType 包裝MediaType，支持不同方式識別類型，如，RootXML，Magic，擴(kuò)展名

MediaTypeRegistry MediaType容器，同時管理MediaType的層次關(guān)系和別名

MimeTypes 自身是Detector實現(xiàn)，MimeType管理和識別

MimeTypesReader 構(gòu)建MimeTypes，該類使用SAX解釋處理mime xml，同時構(gòu)建MediaTypeRegistry；構(gòu)建Magic

MediaType層次關(guān)系作用，當(dāng)該內(nèi)容類型沒有找到具體的分析器，可以使用上級的類型對應(yīng)的分析器，盡可能分析出元數(shù)據(jù)和內(nèi)容

接下來，重點分析一下Magic模型

下圖是典型mime-typemagic配置

Magic 可包括多個magic匹配項match

MimeTypesReader 整個magic體系構(gòu)建者，讀取tika-mimetypes.xml構(gòu)建MimeType/MimeTypes

Magic 屬于MimeType；每個MimeType可有多個Magic；MimeTypesReader也給MimeTypes一份，即MimeTypes擁有所有的Magic

MinShouldMatchClause/OrClause/AndClause自身并不實際eval magic，負(fù)責(zé)邏輯連接Magic的所有match，分別實現(xiàn)最少匹配數(shù)，或，并連接邏輯，3者可復(fù)合嵌套；最終包裝MagicMatch，執(zhí)行MagicDetector

MagicMatch MagicDetector構(gòu)建/選擇器

MagicDetector 真正執(zhí)行magic eval邏輯，每個MimeType對應(yīng)一個

總述整個流程：

MimeTypes-->Magic-->[MinShouldMatchClause/OrClause/AndClause]-->MagicMatcher-->MagicDetector

窮舉Magic找到匹配的

??? 有個優(yōu)先級排除，不知道怎么定優(yōu)先級

下面兩圖展示magic xml配置與對象關(guān)系對照，上下層and關(guān)系，同層or關(guān)系

從MimeType看，magic標(biāo)簽下，第一層每個match對應(yīng)一個Magic，實質(zhì)也是or關(guān)系

MimeTypes自身也是Detector實現(xiàn)，但并沒有在SPI中，而是作為最后防線特定添加進(jìn)默認(rèn)Detector

Detector

Tika有3類探測器，內(nèi)容類型探測(Detector)，編碼探測(EncodingDetector)，語言探測(LangDetector)

與探測器類似，TaskConfig構(gòu)建復(fù)合類型對象，默認(rèn)實現(xiàn)使用ServiceLoader構(gòu)建，自身也是復(fù)合類型

Metadata

Metadata文檔內(nèi)容屬性，可以是文檔自身屬性，如word文檔擁有者，創(chuàng)建日期等，也可以是taka分析獲取的

Metadata 實質(zhì)是key/多值map

Property 相當(dāng)于DTO，傳遞metadata定義

Parser/SAX handler

分析器是內(nèi)容抓取的核心，Detector檢測到內(nèi)容的具體類型，找到對應(yīng)的parser，解釋和抓取內(nèi)容

統(tǒng)一的Parser接口，整體架構(gòu)看，屬于適配器架構(gòu)模式，分析器使用對應(yīng)的解釋組件*，解釋文檔，解釋結(jié)果裝配為XHTML格式，client使用的SAX規(guī)范處理，使用ContentHandler處理XHTML內(nèi)容

*pdf, PdfBox;office, POI;html, tagsoup

內(nèi)容處理器使用裝飾者模式(Decorator)，被裝飾者指派裝飾者處理特定的xml事件，提高處理器的重用

重點分析一下主體內(nèi)容處理器，BodyContentHandler

內(nèi)容抓取主要關(guān)系主題內(nèi)容，重點分析一下BodyContentHandler

BodyContentHandler 指派裝飾者M(jìn)atchingContentHandler處理sax事件，指派的sax事件類型由xpath匹配器，即Matcher確定

MatchingContentHandler 指派WriteOutContentHandler處理匹配matcher xpath的xml text，后者使用writer寫入

！上面分析可知，如果文件文本量大的情況下，Writer是很關(guān)鍵的角色，如果使用內(nèi)存緩存的實現(xiàn)，會出現(xiàn)內(nèi)存溢出

Tika

Tika門面類(facade), 整合前面的組件，為用戶提供開箱即用的tika

Paser庫

tika提供覆蓋廣泛的分析器實現(xiàn)，從常見的html，text，到pdf，word，壓縮類的，音視頻類的，工業(yè)類的cad等

內(nèi)容抓取組件

封裝tika，分析返回metadata/content構(gòu)建Document

索引組件

文檔模型設(shè)計

文檔模型使用metadata+內(nèi)容設(shè)計，metadata遵循最大化和最細(xì)化原則

最大化：支持通用的搜索，如文件名稱，創(chuàng)建時間，創(chuàng)建者，內(nèi)容

最細(xì)化：支持特點類型文檔專有屬性搜索

對應(yīng)的索引schema定義，extras文檔類型特有屬性，定義為nested類型索引，content定義為Text類型索引

索引器設(shè)計

搜索引擎實現(xiàn)索引服務(wù)，索引模式(Index Schema)+屬性getter

索引器整合抓取器和索引服務(wù)即可

集成分布式dataX

文檔分片遍歷

接入分布式dataX，需要分片的策略，無重復(fù)無遺漏的遍歷所有的文檔

1. 數(shù)據(jù)庫分片

數(shù)據(jù)表的分片

2. b) 目錄分支分片

節(jié)點分配一個分支(路徑)，該策略簡單，但容易出現(xiàn)分配傾斜

3. c) 文件名哈希

所有節(jié)點遍歷整個文檔目錄，只處理分派給自身的hash分片，該策略分配比較均衡，需要完整統(tǒng)一的文件名hash實現(xiàn)，能處理不同語言，特殊字符的hash計算

Reader

Reader 抓取器-》Record

Writer

Writer elasticsearch寫入組件，索引服務(wù)

增量模式

支持?jǐn)?shù)據(jù)表(CDC)和文件目錄變更監(jiān)控，另外，文件變更無關(guān)聯(lián)，可多線程并行處理

技術(shù)架構(gòu)

下圖分布式索引技術(shù)架構(gòu)

client 負(fù)責(zé)寫入任務(wù)組分片；觸發(fā) worker 執(zhí)行；client 可集成到管理臺；作業(yè)監(jiān)管，檢測作業(yè)完成，清理作業(yè)環(huán)境

watcher 作業(yè)統(tǒng)計，輸出統(tǒng)計；按作業(yè)分片觀測和聚合計算; watcher 可集成到管理臺

worker 分配分片；任務(wù)(組)執(zhí)行，任務(wù)組執(zhí)行統(tǒng)計

架構(gòu)質(zhì)量

高并發(fā) 高可用 高吞吐 伸縮性 健壯性

高并發(fā)/高可用/高吞吐/伸縮性 分布式dataX提供保障

健壯性 運行實例宕機(jī)，切換節(jié)點運行(failover)，數(shù)據(jù)不丟失，少重復(fù)

分兩個場景

1. 數(shù)據(jù)庫，文檔在數(shù)據(jù)庫記錄

數(shù)據(jù)庫分片即分頁，分頁合理大小，failover后整個分片重新處理；也可以使用可靠channel，failover后斷點繼續(xù)處理，但對存在大量大文件的情況，channel需緩存大量數(shù)據(jù)

2. 2) 目錄，文檔沒有數(shù)據(jù)庫記錄，直接讀取目錄

目前版本不考慮該場景

部署架構(gòu)

參考技術(shù)架構(gòu)，部署組件包括：

• 分布式調(diào)度平臺，其包括zookeeper集群

• redis集群

• 管理臺，內(nèi)含分布式調(diào)度平臺管理api和client，其中client是dataX的Engine

除單點，管理臺部署集群即可文章來源地址http://www.zghlxwxcb.cn/news/detail-463904.html