[發(fā)明專利]一種基于分布式內(nèi)存計(jì)算的文本檢索方法

在審

• 申請(qǐng)?zhí)枺?/td>: 201711361106.4
• 申請(qǐng)日: 2017-12-18
• 公開（公告）號(hào): CN108009270A
• 公開（公告）日: 2018-05-08
• 發(fā)明（設(shè)計(jì)）人: 周紅衛(wèi);李亞瓊;劉延新;劉永波
• 申請(qǐng)（專利權(quán)）人: 江蘇潤和軟件股份有限公司
• 主分類號(hào): G06F17/30
• 分類號(hào): G06F17/30
• 代理公司: 暫無信息
• 代理人: 暫無信息

發(fā)明涉及一種基于分布式內(nèi)存計(jì)算的文本檢索方法。全文檢索文法和全文檢索查詢語言到檢索模型的翻譯轉(zhuǎn)換；檢索模型的并行化，包括數(shù)據(jù)的并行化、索引建立和查詢計(jì)算的并行化、索引多作業(yè)間的共享、全局結(jié)果聚合；存儲(chǔ)模型與檢索優(yōu)化，在建立索引階段，兩類存儲(chǔ)模型即擁有高查詢性能的全量存儲(chǔ)模型和極低索引存儲(chǔ)量的索引指定列存儲(chǔ)模型；在查詢階段，基于索引指定列存儲(chǔ)模型，能夠?qū)⒉樵兘Y(jié)果與原表數(shù)據(jù)進(jìn)行連接、具有O(n)復(fù)雜度的分區(qū)對(duì)齊連接算法；基于兩類存儲(chǔ)模型提出了謂詞下推以及列裁剪優(yōu)化策略。

技術(shù)領(lǐng)域

本發(fā)明涉及一種基于分布式內(nèi)存計(jì)算的文本檢索方法，屬于軟件技術(shù)領(lǐng)域。

背景技術(shù)

全文檢索有效彌補(bǔ)了數(shù)據(jù)庫查詢效率低以及檢索方式單一的不足，在關(guān)系型數(shù)據(jù)庫中，全文檢索是衡量數(shù)據(jù)庫易用性和功能完備性的重要指標(biāo)。當(dāng)前，全文檢索功能作為組件集成在很多傳統(tǒng)關(guān)系型數(shù)據(jù)庫中。在數(shù)據(jù)量較少的情況下，數(shù)據(jù)庫能夠在較短時(shí)間內(nèi)完成全文檢索操作，然而，在大數(shù)據(jù)情況下，全文檢索與關(guān)系型數(shù)據(jù)庫管理系統(tǒng)集成的性能以及可擴(kuò)展性難以滿足對(duì)快速增長的數(shù)據(jù)進(jìn)行檢索的業(yè)務(wù)需求。除了對(duì)于傳統(tǒng)全文檢索的需求，為了更好地發(fā)掘海量文本數(shù)據(jù)中的潛在價(jià)值，面向文本的應(yīng)用需要功能豐富、滿足交互式分析需求的海量數(shù)據(jù)處理系統(tǒng)，但是目前并沒有能將兩者有效結(jié)合的解決方案。

Spark SQL提供了以SQL形式對(duì)海量數(shù)據(jù)進(jìn)行處理和分析的能力，提供了與RDBMS相似的SQL文法以及關(guān)系型查詢操作，方便業(yè)務(wù)人員快速進(jìn)行大數(shù)據(jù)分析，是傳統(tǒng)RDBMS在海量數(shù)據(jù)下進(jìn)行分析的替代系統(tǒng)，能夠有效滿足用戶對(duì)于海量數(shù)據(jù)關(guān)系型查詢和交互式分析的需求。但是目前Spark SQL并不支持全文檢索，主要存在以下三個(gè)問題：

(1) 不支持全文檢索SQL語句，并且翻譯器缺乏將全文檢索文法轉(zhuǎn)換為物理計(jì)劃的機(jī)制。SQL語句是數(shù)據(jù)分析的接口，在Spark SQL中，SQL語句經(jīng)過翻譯器轉(zhuǎn)換為計(jì)劃樹，計(jì)劃樹經(jīng)過優(yōu)化器以及物理計(jì)劃生成器轉(zhuǎn)換為物理計(jì)劃樹，物理計(jì)劃樹包含了一系列RDD以及相互之間的關(guān)聯(lián)操作，進(jìn)而提交給Spark Core進(jìn)行作業(yè)規(guī)劃、調(diào)度、執(zhí)行。Spark SQL目前僅支持簡單的查找如LIKE、BETWEEN等關(guān)鍵字，檢索形式單一，檢索結(jié)果對(duì)于關(guān)鍵詞匹配程度的評(píng)價(jià)簡單，缺乏每行數(shù)據(jù)在全局范圍內(nèi)與關(guān)鍵詞匹配程度計(jì)算方法以及進(jìn)行更復(fù)雜查找的功能，無法滿足用戶的數(shù)據(jù)檢索需求。

(2) 缺乏全文檢索的并行化方法。全文檢索包括建立索引和基于索引進(jìn)行查詢兩個(gè)過程。Spark SQL缺乏將這兩個(gè)過程應(yīng)用于分布式計(jì)算引擎上的方法，用戶只能依賴外部系統(tǒng)如Solr或ElasticSearch才能提供的分布式全文檢索功能?，F(xiàn)有分布式全文檢索引擎如Solr和ElasticSearch雖然提供了Hive和Spark的連接器，但不支持全文檢索SQL文法，這樣的外部系統(tǒng)無法很好地利用Spark引擎和數(shù)據(jù)特性，而且，實(shí)現(xiàn)全文檢索功能需要復(fù)雜的數(shù)據(jù)轉(zhuǎn)換，無法滿足邊查詢邊分析計(jì)算的需求，部署的復(fù)雜性和學(xué)習(xí)成本使其難以使用。

(3) 缺乏底層索引文件的支持以及檢索的優(yōu)化方案。Spark目前并不支持索引，索引的缺乏使得查詢時(shí)需要掃描全表數(shù)據(jù)，導(dǎo)致查詢速度緩慢。檢索優(yōu)化方案通常包括索引存儲(chǔ)模型、檢索并行度與緩存等優(yōu)化技術(shù)。Spark目前并未有此類方案。雖然Solr和ElasticSearch提供了索引支持和檢索優(yōu)化方案，但是由于底層數(shù)據(jù)存儲(chǔ)和執(zhí)行引擎的不同，二者無法根據(jù)Spark本身特性對(duì)存儲(chǔ)模型和查詢方案進(jìn)一步優(yōu)化。

上述問題導(dǎo)致用戶無法利用SQL語句進(jìn)行全文檢索的操作，在如數(shù)據(jù)查找和分析等相關(guān)應(yīng)用上，全文檢索功能的缺失使得Spark SQL難以滿足某些特定業(yè)務(wù)的需求。

發(fā)明內(nèi)容

本發(fā)明的目的：在解釋器、分析器以及物理計(jì)劃生成器中增加了對(duì)于全文檢索文法的識(shí)別和轉(zhuǎn)換規(guī)則，并與索引數(shù)據(jù)源進(jìn)行了對(duì)接，提供了完整的翻譯轉(zhuǎn)換以及完整的檢索模型并行化方案。