程知群，章 超，韓高帥

(杭州電子科技大學(xué)電子信息學(xué)院，浙江 杭州 310018)

基于Solr的數(shù)據(jù)檢索技術(shù)研究

程知群，章 超，韓高帥

(杭州電子科技大學(xué)電子信息學(xué)院，浙江 杭州 310018)

針對海量過車數(shù)據(jù)檢索困難的問題，設(shè)計了一款基于Solr的大規(guī)模分布式數(shù)據(jù)檢索系統(tǒng).前端IPC采集的數(shù)據(jù)經(jīng)過結(jié)構(gòu)化處理之后發(fā)送到后端，數(shù)據(jù)先緩存在消息隊列中，再通過Spark Streaming實時計算框架對緩存的數(shù)據(jù)進行消費，將數(shù)據(jù)搬運到數(shù)據(jù)庫HBase中，最后由Solr爬取HBase中的數(shù)據(jù)，根據(jù)用戶的配置建立索引文件.查詢時，用戶通過點擊Web界面下發(fā)查詢條件，系統(tǒng)將查詢條件解析為Solr能夠識別的查詢語句，從索引文件中取出相應(yīng)的信息，最后從HBase中取出完整的數(shù)據(jù)，返回到界面顯示.測試結(jié)果表明，系統(tǒng)工作穩(wěn)定，可存儲海量多種類型數(shù)據(jù)，索引建立速度為1 000條/s，當數(shù)據(jù)庫中存儲一千億條過車記錄時，對此類TB級別數(shù)據(jù)進行各種條件查詢的響應(yīng)時間均在10 s之內(nèi).

大數(shù)據(jù)；智能交通；Solr；索引

0 引 言

智能交通旨在將物聯(lián)網(wǎng)技術(shù)應(yīng)用于交通領(lǐng)域，建立一個高效且覆蓋范圍廣的交通系統(tǒng)，以緩解日益惡化的交通問題所需的交通基礎(chǔ)設(shè)施建設(shè)和建設(shè)交通基礎(chǔ)設(shè)施高額開銷之間的矛盾[1].目前，國內(nèi)外都很重視智能交通系統(tǒng)的開發(fā).美國已鋪開了由七大系統(tǒng)組成的智能交通系統(tǒng).歐盟也將智能交通系統(tǒng)納入到發(fā)展計劃之中，給相關(guān)部門提供了充足的經(jīng)費用于研究和實施[2].我國道路的發(fā)展已步入世界前列，然而我們的技術(shù)尚不如西方國家那么完善，我國的智能交通系統(tǒng)才迸發(fā)出萌芽[3].

數(shù)據(jù)檢索技術(shù)是智能交通系統(tǒng)中的一樣核心技術(shù).道路監(jiān)控每天產(chǎn)生海量的數(shù)據(jù)，僅浙江省一天產(chǎn)生的過車數(shù)據(jù)便有幾億，如何高效檢索數(shù)據(jù)是現(xiàn)如今的一大難題.目前采用的仍然是傳統(tǒng)的檢索方式，使用數(shù)據(jù)庫自帶的數(shù)據(jù)檢索和數(shù)據(jù)分區(qū)功能.然而在實際的數(shù)據(jù)檢索中，由于數(shù)據(jù)庫中所存儲的信息量過于巨大.當一張數(shù)據(jù)表的數(shù)據(jù)量達到百億甚至千億級別，索引本身就過于巨大，索引過多還會影響到系統(tǒng)的性能.面對大規(guī)模數(shù)據(jù)檢索時，數(shù)據(jù)庫本身自帶的檢索功能根本無法滿足實時數(shù)據(jù)檢索的需求，極易照成系統(tǒng)的癱瘓[4].使用搜索引擎Solr能避免以上限制.搜索引擎采用了倒排索引技術(shù)，比一般的數(shù)據(jù)庫索引更高效，并且Solr提供了分布式搜索的功能，能夠處理各種類型的數(shù)據(jù)[5].同時Solr內(nèi)部實現(xiàn)了分布式一致性機制，可以對Solr集群和索引文件進行一致性管理，并在數(shù)據(jù)容錯和負載均衡方面都很成熟[6].但是當數(shù)據(jù)量達到一定規(guī)模時，使用Solr查詢延時也比較高[7]，針對該問題，本文設(shè)計了相關(guān)查詢優(yōu)化算法對其進行進一步的優(yōu)化，使用Solr為數(shù)據(jù)庫HBase提供搜索引擎服務(wù)，建立索引和查詢.智能交通系統(tǒng)采用搜索引擎技術(shù)能夠大幅度提高查詢效率和系統(tǒng)穩(wěn)定性，并且系統(tǒng)易于擴展，方便未來交通系統(tǒng)的發(fā)展.

1 系統(tǒng)總體設(shè)計

1.1 總體框架

本文設(shè)計的系統(tǒng)主要由3部分構(gòu)成：索引建立模塊、數(shù)據(jù)檢索模塊和用戶搜索界面，系統(tǒng)總體框架如圖1所示.索引建立模塊負責過濾輸入的臟數(shù)據(jù)并進行格式轉(zhuǎn)換，根據(jù)索引配置文件建立索引；數(shù)據(jù)檢索模塊負責解析查詢條件，返回查詢結(jié)果；用戶搜索界面用于用戶下發(fā)檢索條件信息的可視化.

圖1 系統(tǒng)總體框架

1.2 索引建立

Solr是建立索引過程中的核心組件，是一個高并發(fā)、高效率的企業(yè)級搜索引擎.

通過配置Schema.xml和SolrConfig.xml對索引進行配置.前者定義索引字段及字段類型，并指定unique_id唯一標識一條數(shù)據(jù).后者設(shè)置突出顯示、分類、搜索以及其他請求等功能.在索引操作時，需要調(diào)用分詞器提取詞匯以加快檢索.基于數(shù)據(jù)內(nèi)容，系統(tǒng)選擇使用空白分詞器，索引設(shè)置為按月分段，定義緩存5 000條數(shù)據(jù)或者每隔5 s對輸入的數(shù)據(jù)進行索引.

考慮到服務(wù)器的性能、前端發(fā)送數(shù)據(jù)速度和Solr建索引速度不匹配的問題，為了保證系統(tǒng)能穩(wěn)定工作，將建立索引的速度控制在合理的范圍之內(nèi)，否則將造成系統(tǒng)的不穩(wěn)定甚至崩潰.為此，本文設(shè)計的系統(tǒng)引入了消息隊列來緩存輸入的數(shù)據(jù)，再通過實時流式計算框架Spark Streaming從消息隊列中消費數(shù)據(jù)，保障數(shù)據(jù)零丟失及系統(tǒng)的穩(wěn)定運行.

1.3 數(shù)據(jù)檢索

用戶通Web界面下發(fā)查詢條件，條件包含了檢索字段、排序條件、時間跨度等信息.首先判斷條件的正確性，避免出現(xiàn)未建立索引的字段，接著將其轉(zhuǎn)換成Solr能夠識別的查詢條件.根據(jù)條件中的時間范圍，定位到所需要查詢的索引段，然后順序遍歷所有段，找出段內(nèi)符合條件的結(jié)果集，最后對結(jié)果集進行排序.根據(jù)結(jié)果集取出數(shù)據(jù)庫中相應(yīng)的數(shù)據(jù)返回給用戶界面.

但當結(jié)果集過大時，對結(jié)果集進行排序會相當耗時，并且對服務(wù)器性能要求也很高，無法滿足系統(tǒng)快速響應(yīng)的要求.為此本系統(tǒng)引入了一種壓縮查詢時間的方法，通過對時間條件的緊縮，從而減小了結(jié)果集的數(shù)據(jù)規(guī)模，提升了查詢和排序的效率.對時間條件的緊縮是通過實時流式計算工具統(tǒng)計過車數(shù)據(jù)，構(gòu)建查詢的總數(shù)預(yù)測模型，通過對時間條件的多次緊縮，減少了查詢排序的數(shù)據(jù)輸入規(guī)模，提升了查詢排序的速度.例如，已知一個時間段內(nèi)的總的過車量為100條，而浙A車牌的出現(xiàn)的概率為80%，車身顏色為黑的出現(xiàn)概率為80%，那么在該時間段內(nèi)查詢浙A車牌且為黑色的過車總數(shù)為100×80%×80%=64,故將查詢時間修改為查滿64條的截止時間.以10億條過車數(shù)據(jù)為例，通過優(yōu)化后，平均查詢時間為原來的15%～20%，精確查詢耗時在1 s以內(nèi)，模糊多條件查詢耗時在2 s以內(nèi).

以上查詢方法的優(yōu)化仍不能滿足超大規(guī)模數(shù)據(jù)量快速響應(yīng)的需求，因此本文又設(shè)計了一種分Core的查詢方式.Solr中一個Core表示某種類型數(shù)據(jù)的索引文件，并且單個Core容量有限，所以無法處理超大規(guī)模的數(shù)據(jù).結(jié)合服務(wù)器多核低主頻的特點，本文設(shè)計了一種自稱分Core技術(shù)的方法，通過編碼的方式，對特定的索引建立一套命名規(guī)則，動態(tài)地建立一系列的Core，因為多核服務(wù)器的核數(shù)量決定了查詢線程的數(shù)量，所以可以同時起多個線程分別去對應(yīng)的Core中進行查詢.同時，當一個Core中的數(shù)據(jù)打滿時，還會動態(tài)地建立一個新的Core，然后將數(shù)據(jù)打入到新Core中，加快了查詢速度.通過以上兩種方法的結(jié)合使用，極大提高了查詢的速度和準確度，提升了用戶的體驗感.索引建立和檢索流程如圖2所示.

圖2 索引建立和檢索流程

2 系統(tǒng)性能測試

2.1 索引建立速度

儲存一億條數(shù)據(jù)在數(shù)據(jù)庫中，數(shù)據(jù)所占的空間大小為4.32 GB，啟用24條線程爬取表中數(shù)據(jù)，查看索引建立的速度.根據(jù)建立的Core的數(shù)目不同及爬取數(shù)據(jù)的快慢，確定建索引的最佳Core數(shù)，測試結(jié)果如表1所示.

表1 索引建立速度測試數(shù)據(jù)

由表1測試數(shù)據(jù)可以看出，Core的數(shù)目選擇在8時，爬取數(shù)據(jù)表建立索引的速度比較快.雖然選擇在建立10個Core時速度更快，但是過多的Core會導(dǎo)致Solr的穩(wěn)定性下降，而且系統(tǒng)中不止一種應(yīng)用，所以本文選擇建立8個Core，即一張表的索引數(shù)據(jù)存在8個Core中.

2.2 數(shù)據(jù)查詢速度

數(shù)據(jù)庫中存儲了一千億條過車記錄，驗證在不同查詢條件下系統(tǒng)的響應(yīng)時間.假如時間范圍夠大，涉及到查詢多個Core中數(shù)據(jù)，對性能有所影響.這里設(shè)置了兩種查詢條件，一種是只帶了時間范圍的單條件查詢；還有一種是除了時間范圍之外，還設(shè)置了其他的過濾條件的多條件查詢.測試結(jié)果如表2所示.

表2 數(shù)據(jù)查詢速度測試數(shù)據(jù)

由表2中的數(shù)據(jù)可以看出，不管是單條件查詢和多條件查詢，跨越Core的數(shù)目越多，查詢的性能越差，所以在單個Core中存放的數(shù)據(jù)不宜過小.而且在跨越Core數(shù)目相同的情況下，單條件查詢的響應(yīng)時間要優(yōu)于多條件查詢的響應(yīng)時間，但是都不會超過10 s，滿足了系統(tǒng)要求的性能.而如果只是單純地使用數(shù)據(jù)庫自帶的檢索功能查詢，在如此大規(guī)模數(shù)據(jù)量的情況下，將直接報查詢超時錯誤，不會返回任何結(jié)果.

2.3 數(shù)據(jù)查詢準確率

在不同數(shù)據(jù)量的情況下，使用多條件查詢，查看返回結(jié)果的準確率.測試結(jié)果如表3所示.

表3 數(shù)據(jù)查詢準確率測試數(shù)據(jù)

由表3中的數(shù)據(jù)可以看出，多條件查詢在任何數(shù)據(jù)量的情況下，對于結(jié)構(gòu)化數(shù)據(jù)檢索搜索引擎都能百分之百地返回滿足條件的數(shù)據(jù)，不會出現(xiàn)不符合查詢條件的返回結(jié)果，故本系統(tǒng)能夠?qū)崿F(xiàn)精確查詢.

3 結(jié)束語

本文基于交通領(lǐng)域應(yīng)用場景的實際需求，在對Solr分布式索引技術(shù)進行深入研究分析的基礎(chǔ)上，設(shè)計了Solr分Core算法和時間緊縮算法，實現(xiàn)了大規(guī)模海量過車數(shù)據(jù)存儲與檢索系統(tǒng).通過實驗驗證了系統(tǒng)檢索的高效性，滿足智能交通快速響應(yīng)的需求.然而，系統(tǒng)仍然存在一些不完善之處，對海量數(shù)據(jù)進行相關(guān)挖掘以獲取數(shù)據(jù)背后的信息將是后續(xù)研究的重點.

[1]HERRERA-QUINTERO L F, JALIL-NASER W D, BANSE K, et al. Smart cities approach for Colombian Context. Learning from ITS experiences and linking with government organization[C]//Smart Cities Symposium Prague (SCSP), 2015. IEEE, 2015: 1-6.

[2]劉小明,何忠賀.城市智能交通系統(tǒng)技術(shù)發(fā)展現(xiàn)狀及趨勢[J].自動化博覽,2015(1):58-60.

[3]SHI Z, ZOU Z, ZHANG C. Real-Time Traffic Light Detection With Adaptive Background Suppression Filter[J]. IEEE Transactions on Intelligent Transportation Systems, 2016, 17(3): 690-700.

[4]WANG D, HOI S C H, HE Y, et al. Retrieval-based face annotation by weak label regularized local coordinate coding[J]. IEEE transactions on pattern analysis and machine intelligence, 2014, 36(3): 550-563.

[5]蔡宇晶，孫玫肖，朱建軍.Solr在樂齡易購網(wǎng)站中的應(yīng)用[J].鐵路計算機應(yīng)用，2016，25(10):53-56.

[6]牛濤.建立基于Solr平臺的質(zhì)量信息檢索系統(tǒng)[J].電子科學(xué)技術(shù)，2016(5):590-593.

[7]VOORHEES E M, OVER P, SOBOROFF I. Building Better Search Engines by Measuring Search Quality[J]. IT Professional, 2014, 16(2): 22-30.

Data Retrieval Technique Research Based on Solr

CHENG Zhiqun, ZHANG Chao, HAN GaoShuai

(SchoolofElectronicInformation,HangzhouDianziUniversity,HangzhouZhejiang310018,China)

A distributed data retrieval system is designed based on Solr. The front-end IPC collects monitor data, which sends them to the back-end after its structure processed. The data is cached in the message queue. Then it is carried to HBase by Spark Streaming the real-time calculation framework. Finally, Solr crawls data in HBase and create index file according to the user’s requirement of configuration. Users issue the query through clicking the Web interface in querying. Then the system analyzes inquiry condition into inquiry sentences that can be identified by Solr. Next, Solr extract the corresponding information from the index file. Finally, the system extracts the complete data from HBase and return to display in the interface. Measurement results show that the system is stable and can store many types of data. Over 1 000/s of indexing speed is achieved. The response times of a variety of conditions are less than 10 seconds, when the database is stored over 100 billion car records.

big data; intelligent transportation; Solr; index

10.13954/j.cnki.hdu.2017.01.003

2016-07-19

程知群(1964-)，男，安徽巢湖人，教授，射頻電路與系統(tǒng).

TP319

A

1001-9146(2017)01-0011-05