Ｗｅｂ日志挖掘的數據預處理研究

趙　娜　葛蒲陽

摘要：數據預處理在Web日志挖掘過程中起著至關重要的作用。本文詳細分析了數據預處理的過程，并對用戶識別提出了改進策略，最后實現了一個Web日志挖掘預處理模型(WLMPM)。

關鍵詞：Web日志挖掘；數據預處理；用戶識別；會話識別

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)18-2pppp-0c

Research on Data Preprocessing of Web Log Mining

ZHAO Na1,2, GE Pu-yang2

(1.Xidian University,Xi'an 710071,China;2.Information Center of QingHai Architectural Vocational and Technical College,Xining 810012,China)

Abstract:Data preprocessing plays an essential role in the process of Web log mining. This paper analyses data preprocessing process for Web log mining in detail ,and proposes the modified strategy of user identification，finally realizes a model of data preprocessing.

Key words:Web log mining;data preprocessing;user identification;session identification

1 引言

隨著Internet信息量的劇增，如何幫助用戶快速有效地獲取自己感興趣的信息，已成為網站設計者亟待解決的問題。解決這個問題的途徑之一就是將數據挖掘技術和Web結合起來，進行Web挖掘[1]。作為Web挖掘的一個重要組成部分，Web日志挖掘是從Web的存取模式中獲取有價值的信息或模式的過程[2]，就是對用戶訪問 Web 時在服務器留下的訪問記錄進行挖掘。通過分析和研究日志記錄的規律，可以實現用戶聚類、頁面聚類和發現頻繁訪問路徑改進Web站點的性能和結構，為用戶提供個性化服務等。

Web日志挖掘過程一般分為三個階段[3]，即：預處理階段、挖掘算法實施階段、模式分析階段。數據預處理的目的就是將原始日志記錄經過處理形成用戶的會話文件，為挖掘算法實施階段作好數據準備。目前，Web日志挖掘技

術發展迅速，作為整個挖掘過程的基礎和實施有效挖掘算法的前提，數據預處理環節非常關鍵。

2 Web日志文件格式

典型的Web服務器日志包括以下信息：IP地址、請求時間、方法（如 GET/POST）、被請求文件的URL、超文本傳輸協議 HTTP及版本號、返回碼（請求的狀態，成功或錯誤返回碼）、傳輸字節數、引用頁的URL（指向被請求的頁面）和代理（用戶使用的瀏覽器和操作系統的類型）。

222.212.224.26 - - [02/Jul/2006:06:30:13 +0800] "GET /cs/first_page.actionHTTP/1.1" 200 11226 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"就是一條常見的Web服務器日志，其中：222.212.224.26表示請求訪問的用戶IP地址；02/Jul/2006:06:30:13表示訪問時間；GET表示請求的方法；/cs/first_page.action表示被請求的URL；HTTP/1.1表示超文本傳輸協議及版本號；200表示請求成功的返回碼；11226表示傳輸字節數；“-”表示沒有引用頁； Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;SV1)表示用戶代理信息。

3 Web日志數據預處理過程

數據預處理是在將Web 日志文件轉換成數據庫文件以后進行的，其目的是把Web日志轉化為適合進行數據挖掘的可靠的精確的數據。這個過程主要包括四個階段：數據清洗、用戶識別、會話識別和路徑補充。

3.1 數據清洗

數據清洗是指根據需求，對日志文件進行處理，包括刪除無關緊要的數據，合并某些記錄，對用戶請求頁面時發生錯誤的記錄進行適當的處理等等。

當用戶請求一個網頁時，與這個網頁有關的圖片、音頻等信息會自動下載，并記錄在日志文件中，因此可以把日志中文件的后綴為gif、jpg、jpeg、wav、GIF、JPG、JPEG 、WAV等的記錄刪除（除非圖片、音頻等是用戶顯式請求的，即用戶所需要的內容正是這些圖片和音頻等文件）。但是，當挖掘的目的是為了進行網絡流量分析或為頁面緩沖與預取提供依據時，這些信息又顯得格外重要，所以在刪除這些記錄的時候一定要記錄下相關信息。后綴名為cgi、js和JS等腳本文件對后面的分析處理不造成任何影響，也應該刪除。常見做法是定義一個缺省的規則庫來幫助刪除記錄，而且這個規則庫可以根據正在分析的網站類型進行修改。我們可以預先將網站分為一般網站、圖片網站、音視頻網站等，分別建立對應的規則庫；確定要分析的網站屬于哪一類，然后按照該類網站的規則庫進行數據清理。當然，還可根據自己的特定需要對規則庫進行刪改。為了避免到郵件系統和請求教師資源的操作對挖掘產生的影響，我們還刪除了郵件系統的記錄以及部分教師資源的請求記錄，只針對網站的本身進行數據挖掘。

3.2 用戶識別

結束開始引言引言用戶識別的主要任務就是消除代理或防火墻的影響，從日志中還原出每一個請求的用戶。在對用戶進行訪問模式挖掘或用戶聚類分析時，用戶識別顯得至關重要，因為群體是由個體組成的，只有對個體有了清楚的了解，才能識別群體的特征。然而由于本地緩存、代理服務器（網吧、局域網等環境）和防火墻的使用，使得用戶識別這一步變得很復雜。

前人在識別用戶時采用的策略中當 IP 地址相同，用戶使用的操作系統和瀏覽器也相同的條件下，則根據網站的拓撲結構進行識別：如果用戶請求的某個頁面不能從已訪問的任何頁面到達，則判斷這是一個新用戶。如果網站的拓撲結構比較復雜，在根據拓撲結構識別頁與頁之間的關系時，效率會降低。

為此本文對該策略進行了改進：在用戶識別時，不考慮網站的拓撲結構，而是根據引用頁來識別，具體策略如下：

(1)判斷用戶IP地址，不同的 IP 地址代表不同的用戶；

(2)若IP地址相同，但是用戶的瀏覽器或操作系統不同，則認為是不同的用戶；

(3)若IP地址相同，用戶的瀏覽器和操作系統也相同，則根據引用頁判別：如果用戶請求的某個頁面未被請求過且該記錄中引用頁為空，則認為是新用戶。具體算法框圖見圖1。

圖1 改進的用戶識別算法流程圖

需要說明的是：并非使用了這些規則就能準確地識別出用戶。如具有相同 IP地址的用戶若在同樣類型的機器上使用同種瀏覽器，并且請求的頁面集合相同，那么很難識別。一個用戶使用兩種類型的瀏覽器，或是沒有使用站點的鏈接結構直接輸入URL，則容易被認為是多個用戶。

3.3 會話識別

一個會話（Session）就是用戶從進入到離開站點的一系列瀏覽請求。在跨越時間段較大的Web服務器日志中，用戶可能多次訪問了該站點，會話識別的任務就是把屬于同一用戶的同一次訪問請求識別出來。

目前，會話識別的常用方法有3種。最常用的是超時（Timeout）方法。在該方法中，會話的邊界是在兩個頁面請求記錄（以下簡稱記錄）的時間間隔超過一定的閾值時確定的。J.Pitkow的實驗證明，選擇 25.5分鐘作為Timeout的時間閾值比較接近真實會話[4]。目前產業界一般選擇30分鐘為默認的時間閾值。

Cooley 等人提出了一種事務識別會話的方法，稱為序列長度法[5]。經過研究發現，用戶瀏覽頁面的模式一般是通過輔助頁面到達內容頁面，而且用戶在內容頁面停留的時間往往要比輔助頁面的長。這樣，如果已知內容和輔助頁面的集合，在順序讀取日志記錄時，一旦遇到內容頁面就找到了會話的邊界。但是由于在多數情況下，用戶光顧一個站點不可能只對一個內容頁面感興趣，因此該方法形成的會話必然與真實會話有一定的差距。

最大向前序列的方法是根據用戶訪問行為劃分會話，一旦用戶后退瀏覽已經瀏覽過的頁面時，就找到了會話的邊界。這種方法簡便，也易于實現，但是由于所發現的會話只表達了用戶的部分行為，在準確性方面存在局限性。

以上3種會話識別方法可能產生如下情況：(1)使原本在同一個會話里的記錄被劃分在不同的會話中；(2)使原本不在同一個會話的記錄被劃分在同一個會話中。當這樣的不合理劃分所占的比例很大時，進一步挖掘和分析所得到的結果就會受到影響，甚至是錯誤的。

基于此，文獻[6]提出了會話識別的優化算法，并通過合并和斷開兩種操作對最常用的Timeout方法所得到的會話進行優化，使會話質量得到了提高。文獻[7]提出了一種改進的基于時間間隔的識別方法。該方法通過使用訪問時間間隔超出某個閾值來識別會話.通過為頁面設置訪問時間閾值，并根據頁面內容及站點結構確定的頁面重要程度對該閾值進行調整。該方法相對于傳統的使用單一先驗閾值進行會話識別的方法，能更準確地確定頁面訪問時間閾值，而且可以有效的識別出長會話。

由于超時方法比較簡單，我們開發的Web日志挖掘預處理模型在進行用戶會話識別時，依然采用這種方法，選擇30分鐘作為超時間隔。

3.4 路徑補充

由于瀏覽器本地緩存和代理服務緩存的存在，當用戶調用已訪問過的頁面時，將直接從本地或代理的緩存中提取，服務器日志將遺漏對這些頁面的請求。路徑補充的任務就是將這些遺漏的請求補充到用戶會話中。

路徑補充的方法是：依次掃描每一個用戶會話，若當前訪問的頁面與以前訪問的某個頁面存在超鏈接，則說明該用戶是通Back按鈕，從本地Cache中調出該頁面的歷史記錄鏈接到當前頁面。如果會話中相鄰兩頁之間沒有超鏈，說明用戶很可能使用了緩存中的頁面，則檢查引用日志確定當前請求來自哪一頁，如果在用戶的歷史記錄上多次出現引用頁，則將請求時間最接近當前請求頁的頁面作為當前請求的來源，并將該來源頁補充進用戶會話中。若引用日志不完整，可以使用站點的拓撲結構。

根據數據挖掘處理任務的不同，有時還需要進行格式化操作，主要是根據即將進行的挖掘任務，將前期預處理后的數據轉換成所需的數據格式。如進行用戶訪問模式挖掘，還需要進行事務識別，將會話進一步細分為具有一定語義的事務。

4 實驗結果

根據以上內容，筆者實現了一個Web日志挖掘數據預處理模型(WLMPM)，如圖2所示。使用編程平臺為VB.net，Access 數據庫，實驗數據取自某大學計算機學院2006年7月9日～2006年7月16日的服務器訪問日志，日志中原始記錄為19 5154條，經過數據清洗：掉cs-method 中非200 的記錄，去掉后綴名為.jpg，.jpeg，.gif，.bmp，.wav的請求，去掉查詢操作和郵件系統操作的請求，去掉部分教師資源的請求，剩余記錄18 263條（是原始日志記錄個數的10%）。用傳統的用戶識別策略得到2 528個用戶，使用本文提出的用戶識別改進策略，共得到3 163個用戶，說明改進后的方法具有更好的識別效果，且在網站拓撲結構比較復雜的情況下，時間復雜度較低。

圖2 WLMPM的體系結構圖

4 結束語

面向Web日志挖掘中的一個重要的前提和基礎就是Web日志數據準確性。只有準確的數據才能正確地反映使用者的意圖，才能保證分析沿著正確的方向進行。高質量的Web日志挖掘必須依賴高質量的數據[8]，因此，數據預處理工作既要保證信息無失真的轉換，又要保證過濾刪除掉某些對以后挖掘無影響的數據。本文所做的工作就是對傳統的Web日志挖掘預處理過程進行詳細分析，并提出了用戶識別的改進策略。同時實現了一個Web日志挖掘預處理模型(WLMPM)。目前，如何提高與改進Web日志挖掘預處理技術，確保輸入Web日志挖掘的數據正確高效已成為一項重要課題和研究方向。

參考文獻：

[1]韓家煒,孟小峰,王靜,等.Web挖掘研究[J].計算機研究與發展,2001,38(4):405-414.

[2]CHAKRABARTIS.Data mining for hypertext:A tutorial survey[J].SIGKDD Exploration,2000,1(2):1-11.

[3]楊怡玲,管旭東,陸麗娜,等.一個簡單的日志挖掘系統[J].上海交通大學學報.2000(7):35-37.

[4]Catledge L,Pitkow J.Caraeterxizing Browsing Strategies in the World_Wide_Web[J].Computer Networks and ISDN System,1995,27(6):1065-1073.

[5]Cooley R,Srivastava J.Grouping Web page references into transactions for mining world wide Web browsing patterns [A].Proceedings of KDEX'97[C].Newport Beach,CAUSA 1997:2-7.

[6]陳子軍,王鑫昱,李偉.一種Web日志會話識別的優化方法[J].計算機工程,2007,33(1):95-97.

[7]殷賢亮,張為.Web使用挖掘中的一種改進的會話識別方法[J].華中科技大學學報,2006,34(7):33-35.

[8]趙瑩瑩,韓元杰.Web日志數據挖掘中數據預處理模型的研究與建立[J].現代電子技術,2007(4):103-105.

收稿日期：2007-12-08

作者簡介：趙娜（1976-），女，西安電子科技大學在讀碩士，研究方向：數據挖掘；葛蒲陽（1957-），男，高講，研究方向：計算機網絡。