馬憲敏

(黑龍江外國語學院,黑龍江哈爾濱,150025)

基于hadoop的大規(guī)模查詢?nèi)罩痉治瞿Ｐ驮O(shè)計

馬憲敏

(黑龍江外國語學院,黑龍江哈爾濱,150025)

日志分析對于在用戶搜索領(lǐng)域有著很重要的意義,目前的日志分析系統(tǒng)有著不少弊端，比如：海量數(shù)據(jù)無法處理、離線處理模式、處理時延長等。對日志數(shù)據(jù)采用分級歸檔，可以實現(xiàn)大數(shù)據(jù)的分級優(yōu)化處理。本文通過提出在一種基于Hadoop的大數(shù)據(jù)日志分析模型，并對其業(yè)務(wù)處理流程以及功能架構(gòu)進行深入分析，實驗結(jié)果反映出該系統(tǒng)擴展性強、海量數(shù)據(jù)處理能力卓越、滿足在線處理等，具有良好的可行性和有效性。

Hadoop；海量日志處理；查詢；模型設(shè)計

0 引言

查詢?nèi)罩臼怯涗浰阉饕嬗脩舨樵冊~和返回的網(wǎng)頁等相關(guān)信息的文件。通過分析用戶查詢?nèi)罩?，提取用戶搜索行為特征，對搜索引擎檢索結(jié)果進行處理，可以使搜索引擎返回更加準確的檢索。

用戶查詢?nèi)罩痉治鍪切畔z索領(lǐng)域的一個熱點，也是研究搜索引擎效率和用戶行搜索行為的重要手段。近年來，國內(nèi)外的學者對搜索引擎查詢?nèi)罩痉治鲆呀?jīng)做了很多研究。隨著網(wǎng)頁信息量的增加，要進行大規(guī)模日志分析，將面臨系統(tǒng)擴展性，并發(fā)性，數(shù)據(jù)穩(wěn)定性等諸多問題，因此本文提出了一種基于hadoop的大規(guī)模用戶查詢?nèi)罩痉治瞿Ｐ?。其中hadoop是一個分布式處理框架，該模型借助Hadoop框架下的HDFS實現(xiàn)了查詢?nèi)罩镜姆植际酱鎯Γ梅植际綌?shù)據(jù)倉庫Hive實現(xiàn)了海量數(shù)據(jù)的并行查詢與分析。

1 hadoop相關(guān)技術(shù)

1.1 hadoop框架

Hadoop是一個分布式系統(tǒng)基礎(chǔ)架構(gòu)。hadoop框架的核心包括：分布式文件系統(tǒng)HDFS，大規(guī)模并行計算編程模型Mapreduce。

HDFS是hadoop下實現(xiàn)的分布式文件系統(tǒng)，由一個命名節(jié)點Namenode和若干個數(shù)據(jù)節(jié)點Datanode組成。采用主/從(Master/Slave)工作模式，由Namenode作為主節(jié)點(Master)，負責數(shù)據(jù)的管理，由Datanode作為從節(jié)點(Slave)，負責數(shù)據(jù)的分布式存放與備份。HDFS有著高容錯性的特點，非常適合超大規(guī)模數(shù)據(jù)集的應用。

Mapreduce是hadoop框架下的分布式編程模型，由map和reduce兩個階段組成，使得開發(fā)分布式并行計算程序的難度降低。輸入文件通過map階段將原始數(shù)據(jù)映射到用戶自定義的key/value鍵值對集合中，reduece階段將鍵值對集合進行處理后輸出最終結(jié)果。

1.2 Hive

Hive是一個分布式的數(shù)據(jù)倉庫工具。有以下4層結(jié)構(gòu)：①用戶接口形式；②元數(shù)據(jù)的存儲方式與格式；③解釋器、編譯器、優(yōu)化器、執(zhí)行器；④HDFS。

用戶接口分為3個部分：CLI, Client和WUI。其中CLI是比較常用的，啟動CLI會同時有一個Hive副本產(chǎn)生。Hive的客戶端是Client，Hive Server作為服務(wù)器供用戶連接?？蛻舳四Ｊ絾拥臅r候，Hive Server應該指定所在節(jié)點并同時在此節(jié)點來啟動服務(wù)器。Hive是通過WUI用瀏覽器訪問的。

數(shù)據(jù)庫被Hive用來存放元數(shù)據(jù)，如mysql、derby。Hive中的元數(shù)據(jù)有如下結(jié)構(gòu)：表的名字；表的列和分區(qū)及其屬性；表的屬性；表的數(shù)據(jù)所在目錄等。

在HQL查詢語句中，解釋器用于詞法分析，編譯器用于語法分析，優(yōu)化器用于編譯、優(yōu)化同時生成行查詢計劃并存儲在HDFS中，然后通過Mapreduce調(diào)用并執(zhí)行。

Hive的數(shù)據(jù)存儲在HDFS中，大部分的查詢由Mapreduce完成。

2 查詢?nèi)罩痉治瞿Ｐ?/h2>

2.1 數(shù)據(jù)集與數(shù)據(jù)格式

搜索引擎日志分為用戶點擊日志和用戶查詢?nèi)罩?，本文采用的是實驗室提供的搜索引擎用戶查詢?nèi)罩?，為期一個月，共計21426940條。與用戶點擊日志不同的是用戶查詢?nèi)罩靖雍啙崱?/p>

2.2 模型整體設(shè)計與工作流程

利用hadoop框架下HDFS安全可靠的存儲性能，根據(jù)大規(guī)模數(shù)據(jù)分布式存儲的需求，并結(jié)合分布式數(shù)據(jù)倉庫Hive下HQL編程簡潔易懂，日志分析模型如圖1所示，該模型包括三個模塊：并行ETL模塊，并行分析模塊，結(jié)果處理模塊。

首先，并行ETL模塊從日志服務(wù)器得到用戶查詢?nèi)罩竞?，對日志進行預處理操作，并加載到分布式的HDFS上，由hadoop框架自動實現(xiàn)備份。然后，并行分析模塊根據(jù)具體的分析方法，并行加載HDFS上的文件到Hive所建立的表中，通過HQL語言進行統(tǒng)計分析，Hive會將HQL語言轉(zhuǎn)化為Mapreduce，Mapreduce由各個節(jié)點并行執(zhí)行。最后返回分析結(jié)果并存儲。

圖1 模型整體框架設(shè)計

2.2.1 并行ETL模塊

ETL（Extraction-Transformation-Loading）是數(shù)據(jù)提取、轉(zhuǎn)換和加載的簡稱，是數(shù)據(jù)倉庫技術(shù)中數(shù)據(jù)預處理必不可少的一步。將日志進行了如圖2所示的ETL處理。

圖2 并行ETL模塊

（1）數(shù)據(jù)提取

實驗室提供了一個月的用戶查詢?nèi)罩?，以一天為單位，共計一個月的日志信息量。

（2）數(shù)據(jù)轉(zhuǎn)換

首先，用戶查詢?nèi)罩镜木幋a格式是GBK，我們需要將GBK轉(zhuǎn)化為Hive中采用UTF-8格式，防止查詢詞出現(xiàn)亂碼的情況。其次，各個字段之間的分隔符不一樣。采用自定義Hive的輸入格式inputformat來控制輸入。

（3）數(shù)據(jù)加載

用HQL語言在Hive中為每天的查詢?nèi)罩窘⒈恚篊REATE EXTERNAL TABLE Sogou_query_log (字段1，字段2……) ROW FORMAT DELIMITED FIELDS TERMINATED BY ' ' LINES TERMINATED BY ' ', 表的字段和日志的字段相同。Hive并行地加載本地日志文件到表中，表被保存到hadoop下的HDFS上，并實現(xiàn)自動備份。

2.2.2 并行分析模塊

經(jīng)過ETL操作，得到了可用于直接查詢的日志信息。日志分析模塊提供了統(tǒng)計查詢詞長，查詞頻分析，URL排名與點擊量關(guān)系的分析，高級搜索比例等分析功能，并允許用戶添加自定義的分析方法。分析模塊使用編程難度低的HQL語言實現(xiàn)。根據(jù)分析請求，Hive將HQL語句解釋成為相應的Mapreduce程序，讀取分布式文件系統(tǒng)HDFS保存的日志表文件，各個數(shù)據(jù)節(jié)點并行執(zhí)行，計算出相應分析結(jié)果。

2.2.3 結(jié)果處理模塊

該模塊包括了存儲和顯示兩個操作，將分析模塊輸出結(jié)果自動保存到HDFS中，數(shù)據(jù)節(jié)點相互備份，安全穩(wěn)定地存儲日志文件和分析結(jié)果文件，并提供到終端予以顯示。

3 結(jié)果分析和模型優(yōu)化

3.1 實驗結(jié)果分析

使用4臺PC機搭建hadoop分布式計算模型, 分別為pc1~ pc4, 其中pc1作NameNode，并在pc1上配置Hive，pc2~ pc4作DataNode和TaskTracker。每臺PC機具體配置如下:硬件環(huán)境: Intel( R) Core(TM)2 Duo CPU 2.20GHz; 2GB內(nèi)存; 100G硬盤; 100Mbps網(wǎng)口。軟件環(huán)境: Ubuntu 10; JDK1.6.0_27; hadoop 0.20.3; Hive 0.10.0。

3.1.1 查詢詞長分析

查詢詞長是對查詢詞包含中文字個數(shù)的度量。查詢詞的長度能在一定程度上影響返回的查詢結(jié)果，并反映用戶查詢習慣。經(jīng)實驗數(shù)據(jù)分析，在用戶查詢?nèi)罩局械钠骄樵冊~長為9.5個字節(jié)，約為4個漢字。查詢詞長為2個字節(jié)到32個字節(jié)的用戶占了所有查詢的96.5%。文獻在Excite和AltaVista搜索引擎上所測得英文查詢詞平均長度為2.25個英文單詞。說明中文和英文查詢用戶的查詢詞都比較短，搜索引擎要準確地檢索結(jié)果存在一定困難。所以這要求中文搜索引擎需要對查詢用戶的需求有更好的理解和分析，才能更好地提供查詢結(jié)果。

3.1.2 查詢詞頻分析

查詢詞頻分析也稱為熱榜排名分析，查詢詞頻是指同一查詢詞重復查詢次數(shù)。經(jīng)統(tǒng)計，排名前100的查詢詞查詢次數(shù)占總查詢次數(shù)的69.13%。

結(jié)果分析表明搜索引擎查詢詞出現(xiàn)頻率和頻率的排名存反比關(guān)系。所以搜素引擎每天處理的工作有大部分是相同的，少部分的查詢能夠滿足大部分查詢用戶的需求。為此，引入緩存機制和建立多級索引機制能夠很好的適應用戶的重復查詢特性。

3.1.3 用戶首次點擊與URL排名關(guān)系

用戶提交一次查詢，搜索引擎根據(jù)提交的查詢詞，檢索算法和排序算法返回相關(guān)聯(lián)的網(wǎng)頁，用戶根據(jù)個人喜好和檢索特點，選取合適的網(wǎng)頁點擊。為了研究用戶對返回網(wǎng)頁的點擊行為，我們對URL排名和用戶的點擊量的關(guān)系進行了分析。根據(jù)實驗結(jié)果，我們將實驗結(jié)果分為兩組：排名前20的網(wǎng)頁和排名100到1100的網(wǎng)頁，兩組結(jié)果分別如圖3和圖4所示。

圖3 點擊量與URL排名（排名前20）

在第一組實驗結(jié)果中，點擊量前10的網(wǎng)頁點擊次數(shù)總共約為1763萬條，占總查詢數(shù)的82.29%，這說明約80%的用戶只關(guān)注查詢結(jié)果排名前10的網(wǎng)頁，即返回結(jié)果首頁的網(wǎng)頁。分析結(jié)果要求搜索引擎采用的排序算法能將與查詢詞相關(guān)度高的網(wǎng)頁盡可能地顯示在前面。

圖4 點擊量與URL排名（排名100-1100）

在第二組分析結(jié)果中，可以看出排名1000的網(wǎng)頁點擊量約達到22000次，如圖4所示。排名靠后卻點擊量巨大，這似乎不合常理，但是進一步分析，我們發(fā)現(xiàn)該類網(wǎng)頁屬于搜索引擎推廣網(wǎng)頁。該類網(wǎng)頁的查詢詞均屬于醫(yī)療，就業(yè)，培訓等。在進行頁面顯示時，檢索算法將這些排名較低的網(wǎng)頁人為的顯示到靠前頁，從而獲取商業(yè)價值。這說明在考慮搜索結(jié)果精確度的同時，商業(yè)搜索引擎會在一定程度上有目的地將一些排名低的網(wǎng)頁顯示在首頁。平衡好推廣網(wǎng)頁和用戶查詢網(wǎng)頁關(guān)系，才能更好地滿足用戶查詢需求。

3.1.4 高級搜索比例

搜索引擎的高級搜索是通過限定查詢范圍，將關(guān)鍵詞用邏輯連接詞連接起來進行查詢的一種方法。本文中，我們對搜索引擎用戶高級搜索行為進行了分析，在約為2200萬條查詢中，使用site：、link：等關(guān)鍵詞和+、-等邏輯連接詞進行查詢的記錄數(shù)為約18萬條，占總查詢條數(shù)的0.84%。結(jié)果表明在使用搜索引擎時，國內(nèi)查詢用戶更加喜歡簡單的查詢方式。所以，在高級搜索設(shè)計上，中文搜索引擎應該從國內(nèi)用戶的查詢習慣和簡便性出發(fā)，在提供準確查詢的前提下，降低高級搜索的復雜度。

3.2 效率分析以及模型優(yōu)化

結(jié)合hadoop分布式框架的特點和實驗過程中發(fā)現(xiàn)的問題，可以從四個方面進行了模型優(yōu)化:

（1）數(shù)據(jù)傾斜:使用Hive提供的通用負載均衡算法，優(yōu)化模型整體性能。

（2）數(shù)據(jù)拷貝:Hive提供了combiner機制，可以使數(shù)據(jù)在map端部分聚合，相當于Mapreduce編程模型下的combiner層。

（3）Jion操作:單個日志文件小于1G，用map join語句代替join。map join操作在map階段完成，不再需要reduce，節(jié)約了系統(tǒng)的開銷。

（4）連接順序：位于Join操作符左邊的表會被加載進內(nèi)存，將條目少的表放在左邊，可以有效減少發(fā)生內(nèi)存溢出錯誤的幾率。

通過以上方法優(yōu)化后，在不同數(shù)據(jù)集大小的條件下，分別測試偽分布式環(huán)境，以及分布式優(yōu)環(huán)境化前后的運行時間，結(jié)果如圖5所示。由實驗結(jié)果可以看出在數(shù)據(jù)集較小的時候，分布式日志分析模型沒有體現(xiàn)出優(yōu)勢。因為在分布式環(huán)境下，各數(shù)據(jù)節(jié)點之間的相互拷貝，I/O通信，消耗了大量時間，所以該模型不適合小文件處理。隨著數(shù)據(jù)集的增大，分布式日志分析模型表現(xiàn)出了良好的性能，在經(jīng)過上述優(yōu)化操作后，系統(tǒng)運行時間減少，在數(shù)據(jù)集較大的情況下，系統(tǒng)優(yōu)化效率最高能夠達到6%。

4 結(jié)束語

用戶查詢?nèi)罩痉治鍪茄芯坑脩舨樵冃袨榈那疤岷图夹g(shù)，本文設(shè)計和實現(xiàn)了基于hadoop的大規(guī)模用戶查詢?nèi)罩痉治瞿Ｐ?，將分布式技術(shù)運用于大規(guī)模數(shù)據(jù)處理，解決了大規(guī)模數(shù)據(jù)分析的擴展性和并發(fā)性瓶頸。對檢索算法、排序算法、緩存機制等方面的研究給出了建議,對于搜索引擎的優(yōu)化有一定的指導意義。

[1] White T.Hadoop:The Definitive Guide[M].O'Reilly Media,Inc,2012:755-795.

[2] Ghemawat S,Gobioff H.The Google File System[C]. ACM Symposium on Operating Systems Principles, 2003.

[3] Thusoo,Sarma.Hive - a petabyte scale data warehouse usinghadoop[C].Long Beach,CA:International Conference on Data Engineering,2010:996-1005

馬憲敏，女，1979.12-，山東省日照市，碩士，副教授，研究方向：軟件工程。

Design of massive query log analysis model based hadoop

Ma Xianmin
(Heilongjiang international university,HeilongjiangHarbin,150025)

Log analysis has a very important significance for the field in the user search,the current log analysis system has a lot of disadvantages,such as:massive data cannot be processed,off-line processing mode,processing delay and other. the classification of log data archiving, in order to achieve big data classification optimization of growing demand.It puts on a large Hadoop log data based on the analysis model,and the business processing process and functional structure of the in-depth analysis,experimental results show the system expansion and strong, massive data processing ability of excellence,online processing,with good feasibility and effectiveness.

Hadoop;log processing;query;model design