基于Hadoop的網絡日志挖掘方案的設計

許抗震++吳云

摘 要： 提出一種挖掘指數級別網絡日志數據的解決思路，設計了一個高可靠的網絡日志數據挖掘方案。針對現有的公開網絡日志數據集，在數據預處理階段實現了基于MapReduce的過濾算法，并且挖掘出支持企業決策的服務信息。對該方案搭建的平臺進行優化操作，性能提升了3.26%，最后對方案的高可靠性、日志文件個數對平臺I/O速度的影響、平臺和單機在查詢性能上的對比等方面做了實驗。結果表明：該設計方案不僅可靠，而且隨著日志文件個數的翻倍增加，讀操作耗時平均增加52.58%，寫操作耗時平均增加79.69%。隨著日志量的增加，單機的查詢耗時急劇增長，而平臺的查詢耗時趨于穩定。隨著機器節點的增加，運算耗時以平均8.87%的速度減少。

關鍵詞： 網絡日志； 數據挖掘； 數據清洗； Hadoop； MySQL

中圖分類號： TN711?34； TP391.9 文獻標識碼： A 文章編號： 1004?373X（2017）09?0115?06

Abstract： A thought of mining the Web log data with exponent level is put forward. A high reliability Web log data mining scheme was designed. Aiming at the available public Web log dataset， the filtering algorithm based on MapReduce was implemented in the data preprocessing stage to mine the service information supporting the enterprise decision. The platform established with this scheme is optimized， and its performance is increased by 3.26%. The effect of the scheme′s high reliability and log file quantity on the I/O speed of the platform， and the comparison of the platform with the single machine in the aspect of query performance were tested. The results show that the designed scheme is reliable， double increased with the increase of the log file quantity， the time cost of the read operation is increased by 52.58% averagely， and the time cost of the write operation is increased by 79.69%. With the increase of the log quantity， the query time cost of the single machine is increased rapidly， and the query time cost of the platform is stable. With the increase of the machine nodes， the computational time cost is decreased by 8.87% averagely.

Keywords： Web log； data mining； data filtering； Hadoop； MySQL

0 引 言

隨著信息爆炸時代的到來，在日常生活中每天都會產生指數級的數據，特別是網絡日志，這就必然帶來一系列的問題。一方面數據存儲量過于龐大而且存儲資源有限，另一方面傳統的計算方式使得計算過程周期過長，計算資源得不到合理分配。隨著Apache公司Hadoop的誕生，利用低價的集群實現了強大的計算和海量存儲，并且在網絡日志挖掘這一領域出現了一些應用研究[1?2]。本文的一個目的就是研究Hadoop框架及其生態系統成員，搭建出一種基于Hadoop生態系統成員Zookeeper的高可靠（High Available，HA）集群并進行優化。

網絡日志數據是一種暗數據，所謂暗數據就是大數據的一個子集，是指被用來收集、處理和存儲但不做其他用途的數據，因其數據量龐大，受到技術和工具的限制，一般并不用來做分析[3]。但是網絡日志數據對于企業有巨大的潛藏價值，它更能反映出用戶的瀏覽興趣與意圖。利用數據挖掘技術挖掘出有價值的信息可以提高企業的產品質量和服務。另外，面對這種指數級別的日志數據，不但要關注數據的量的龐大，還要要求數據的質的可靠無誤。網絡日志數據往往很駁雜，數據中存在著錯誤和不一致性，需要剔除或者加以改正[4?5]。所以，本文利用Hadoop平臺設計并實現了基于MapReduce的分布式清洗算法，能夠提取出高質量的數據集，方便進行數據挖掘。

結合Hadoop和編程思想進行自底向上分架構的設計[6]：數據存儲層、業務邏輯層、應用層。最后用實驗測試平臺的性能，并且用某網站的日志數據做實驗挖掘出有價值的信息，供企業進行決策和改善用戶體驗。

1 Hadoop生態系統主要成員

自從GFS[7]和MapReduce問世之后，開源項目Hadoop就逐漸形成了自己的生態系統，特別是在Hadoop 2.0出現之后，為解決企業數據快速分析和挖掘提供了強大的分布式數據平臺。具體介紹如下：

HDFS：一個主從結構的分布式文件系統類似于GFS用于存儲大量數據[8]。

MapReduce：Hadoop的分布式批處理框架[9]。

YARN：一種新的資源協調管理系統，可以部署上層應用，大大提高了集群的利用率[9]。

Flume：一個高可靠的分布式海量日志收集系統。

ZooKeeper：一個能夠提供協調服務的分布式協調服務框架。

Sqoop：Hadoop與外界的一個數據遷移工具。

Hive：可以進行多維分析的數據倉庫系統。

2 基于Hadoop的網絡日志挖掘方案的設計

當前，很多網站每天都會產生指數級別的日志數據，由于這些數據是一種暗數據，很多企業并不重視，這就造成了許多具有價值的信息被埋沒。而且目前的數據挖掘很多都是基于傳統的關系型數據庫，挖掘時間很長、效率底下，影響了業務決策。本文利用廉價的計算機集群設計搭建一種基于網絡日志數據的挖掘方案來解決這些問題。

2.1 設計架構

網絡日志數據具有異構性、多樣性、復雜性等特點，結合網絡日志數據的這些特點和編程思想把平臺的設計分為三層架構，如圖1所示。

數據存儲層：包括日志收集系統和底層數據的存儲計算，日志收集系統主要負責網站日志的收集，然后調用過濾算法進行過濾，以文件形式傳入到Data Node底層數據節點上進行存儲，所有的計算結果也是在數據存儲層，包括清洗過的中間數據、數據挖掘的結果、日志的元數據等。

業務邏輯層：是平臺的核心，工具HBase，Hive，Zookeeper不僅實現了業務邏輯的封裝還簡化了用戶的使用，所以使用這些工具進行數據處理和數據挖掘。根據用戶上網行為模型、網站流量模型、網站VIP用戶模型挖掘出瀏覽量PV，IP數等有價值的信息。分析結果以文件形式存儲在HDFS上，Hive的元數據通過用戶接口CLI（command line interface）以MySQL作為存儲引擎。最后使用Sqoop工具把分析結果導出到集群外的關系型數據庫MySQL中。

應用層：利用業務邏輯層中的分析結果，例如VIP用戶、板塊熱度、瀏覽量PV等用戶特征和流量統計結果可以定位目標用戶群，進行精準的營銷方案設計，還可以針對冷清網頁板塊進行改善，提高網站的用戶體驗等決策服務支持。

2.2 節點的規劃

平臺在異構環境下搭建，整個集群由6臺華碩的廉價機器組成，配置均為：四核3.2 GHz的i5 CPU，4 GB內存，2 TB硬盤，機器搭載的是CentOS 2.0系統。搭建的軟件是Hadoop 2.0，集群中準備配置兩個主節點，分別處于Active狀態和Standby狀態。Active狀態的主節點可以對外提供服務，Standby狀態的主節點并不提供服務，只是通過JournalNode進程同步Active狀態節點的元數據。當其中的Active狀態節點宕機，會快速自動的進行ZKFC（DFSZKFailoverController）故障轉移。這樣配置就保證了集群的高可靠性。平臺的主機名，IP，安裝的軟件和進程規劃如圖2所示。

2.3 搭建主要步驟

（1） 首先安裝配置Zookeeper，然后將配置好的zookeeper拷貝到itcast05和itcast06節點下。

（2） 配置HDFS時先將Hadoop添加到環境變量中，再分別修改HDFS的配置文件。

（3） 修改slaves并配置免密碼登錄，slaves是指定子節點的位置，所以首先要配置itcast01到itcast02，itcast03，itcast04，itcast05，itcast06的免密碼登錄，而后配置itcast03到itcast04，itcast05，itcast06的免密碼登錄。

（4） 安裝配置HBase，Sqoop和Hive，這三個工具按照功能作用分別組成平臺的數據庫，數據轉移模塊和多維分析模塊。首先需要把Sqoop安裝在itcast01節點上，添加到環境變量，將數據庫連接驅動拷貝到$SQOOP_ HOME/lib里，配置MySQL的遠程連接。然后解壓下載好的hbase?0.94.2?security.tar.gz，修改相關文件保存并退出。最后解壓hive?0.9.0.tar.gz，修改保存相關文件并退出。

3 網絡日志數據的分析與挖掘

首先利用Flume模擬日志的生成和抓取，這樣和真實的生產環境一樣，保證了數據搜集的真實性。然后應用設計好的基于MapReduce的清洗算法對數據進行清洗過濾[10]，設計KPI（Key Performance Indicator），使用Hive進行多維分析。最后使用Sqoop工具把結果導入MySQL中進行可視化顯示。系統管理員進行集群的管理和監控，用戶通過Web UI挖掘需要的信息。

3.1 數據清洗算法和KPI的設計

3.1.1 清洗算法設計

實驗所用的日志數據是某網站的公開數據集合，原始數據的格式如表1所示。一共54萬行數據，日志數據每行由6部分組成：用戶IP、請求日期、請求方式、訪問資源、訪問狀態、訪問流量。首先把數據上傳到HDFS，然后根據數據格式設計過濾算法。

從表1中可以看出，網站的日志數據格式比較雜亂，需要對數據進行清洗過濾，首先HTTP頁面請求方式有很多，其中只有GET這種方式才能代表用戶的行為意圖，所以需要剔除其他方式。其次，返回的狀態碼只有2開頭的才表示用戶訪問成功，其他噪聲狀態碼也需要剔除。具體算法用Java實現，算法流程如圖3所示。

在寫MapReduce清洗算法之前，首先寫一個名為LogFilter的類，它的作用是用來解析網絡日志的行記錄，這個類中包含一個方法parse，接收網絡日志的一行數據，按照數據的格式拆分為用戶IP、請求日期，請求方式和訪問資源放一起，訪問狀態，訪問流量。把這五部分裝入一個數組返回。

Mapper函數{開始循環Map方法

Map（LongWritable key， Text value） {

value轉化為字符串賦值給line； //讀入一行記錄

LogFilter類實例化調用parse返回一個數組logs；

//logs[0]裝用戶IP，logs[1]請求日期等5部分數據

if（logs[3]以"GET/static"或"GET/uc_server"開頭）{

返回；}

if（logs[3]以"POST"開頭）{

跳出函數進行下一次循環；}

if（logs[4]不是在200～299）{

跳出函數進行下一次循環；}

序列化（logs數組）放入vl對象； //經過過濾后的數據

輸出（key，vl）； //作為Reduce函數的輸入

}

}

因為不需要排序和組合，所以Reduce函數按輸入輸出。

3.1.2 KPI的設計

數據挖掘和數據分析的最大不同就是，數據挖掘的目標信息并不明確，應用到的技術和算法也不確定，又因為網絡日志數據中往往含有大量衡量一個網站關鍵的指標，所以本文根據這些關鍵指標來指定KPI的設計。

（1） 頁面瀏覽量PV（Page View）

定義：頁面被訪客瀏覽的次數，每個獨立用戶只要瀏覽一個頁面次數就加一次[11]。

分析：網站是由一個個頁面組成，所有頁面瀏覽量的總和就是網站瀏覽量，反映了客戶對網站的興趣程度[11]。

公式：記錄次數。

（2） IP個數

定義：一段時間內訪問網站的不同IP 數量和[11]。

分析：一般來講，IP的數量與網站的訪問用戶成正比。

公式：對不同IP進行計數。

（3） 跳出率

定義：訪問網站的某個頁面后便離開的訪客數占總的訪客數的百分比[11]。

分析：跳出率可以衡量網站對于用戶的吸引程度并且呈反比。

公式：統計一天內只出現一條記錄的IP，稱為跳出數

跳出率=100%

（4） 版塊熱度排行榜

定義：版塊的訪問情況排行。

分析：熱度反映了用戶是否喜歡網頁中的某板塊，可以幫助企業鞏固熱點版塊，加強冷清版塊建設。

公式：按訪問次數、停留時間統計排序。

3.2 使用Hive進行數據挖掘

（1） 初始化

在Hive下創建一個外部表，用來連接HDFS上的數據，并把這張外表源數據存儲在MySQL中。

（2） 寫shell腳本

每天把HDFS的日志數據處理一次，用MapRuduce過濾數據，寫入到shell中的daily.sh。

（3） 分析流量排名前三的用戶

在Hive中輸入查詢命令，并且導入一張名為PV的表中，如圖4所示。

圖4便是某一天流量排前三的用戶，說明這幾個用戶不僅僅是經常瀏覽網站的老客戶，而且也是流量貢獻較多的客戶，可以針對這些老客戶進行個性化營銷推薦。

（4） 查詢點擊量前十的用戶

在Hive中輸入查詢點擊量命令，結果如表2所示。

可以把表2中這些用戶當作VIP用戶群，對這些用戶群進行重點關注。

（5） 查詢頁面瀏覽量排行

用Sqoop導入到MySQL中，如圖5所示。

從排名可以看出哪些頁面是非常受用戶歡迎的，哪些是比較冷清的板塊，提供給企業進行參考。

4 平臺優化與實驗測試

4.1 平臺優化

Hadoop平臺的優化主要有以下幾個方面：

（1） 合適的硬件選擇

Namenode應選擇大內存、多路多核、高主頻的CPU，Datanode內存根據CPU的虛擬核數（vcore）進行公式配比。

vcore數=CPU個數×CPU核數×HT（超線程數）

內存大小=vcore×2 GB

（2） 操作系統和JVM優化

首先不使用可能導致操作超時的swap分區，其次根據vm.overcommit_memory的值決定分配策略，設為2。vm.overcommit_ratio的值設定為超過物理內存的比例10%，最后關閉THP（Transparent Pages）并開啟JVM重用。

（3） Hadoop參數優化

Hadoop有80多個參數和性能有關，主要是HDFS，YARN和Mapreduce優化。塊大小（dfs.block.size）就是默認的64M，中間結果設置分布在多機器（mapred.local.dir），分片大小和塊大小一致。優化后的操作性能耗時減少了3.26%，如圖6所示。

4.2 試驗測試

為了減少偶然性的干擾且相對準確地測出結果，測試的數據都是四次以上取平均值。

測試一：驗證平臺的高可靠性

首先向hdfs上傳一個文件，然后再kill掉Active的NameNode。用瀏覽器訪問：http：//192.168.1.202：50070，Standby狀態的主節點就變成了Active狀態，再執行命令Hadoop fs ?ls/，剛才上傳的文件依然存在，手動啟動那個宕機的NameNode，顯示NameNode ′itcast02：9000′（standby），這就保證了平臺的高可靠性。

測試二：日志文件個數對平臺I/O速度的影響

首先進行總大小都為100 MB，日志文件個數分別為10，30，50的讀操作，然后再進行總大小都為100 MB，日志文件個數分別為10，30，50的寫操作，結果如圖7所示。

隨著文件個數的增多，讀寫時間明顯變長，所以本平臺比較適合大規模的日志文件，對于小文件處理將會花費較多時間。在文件總大小一樣的情況下，隨著文件個數的增加，讀操作耗時平均增加52.58%，寫操作耗時平均增加79.69%。

測試三：平臺和單機在查詢性能上的對比

測試采用一臺和方案中配置完全相同的單機，分別在4萬、8萬、12萬、16萬條日志數據中查詢排名前十的頁面瀏覽量，結果如圖8所示。

從圖8可以看出，當數據量很少時，用單機進行數據挖掘效率很高，但是隨著數據量的增大，單機效率明顯下降，而且很可能會存在內存溢出的問題，數據需要預先拆分才能完成挖掘任務，與單機相比，本文搭建的數據平臺具有極高的性能查詢能力，能夠很好的勝任海量的網絡日志挖掘。

測試四：平臺的擴展性

本文搭建的平臺部署了6個節點，測試時每次增加一個計算節點，組成節點個數分別為6，7，8，9的集群，查詢16萬條日志數據排名前十的頁面瀏覽量所耗時間如表3所示。

由表3可以看出隨著節點的增加，計算耗時以平均8.87%的速度減少，平臺的高擴展性隨之展現，當遇到海量數據處理時，只需要增加計算節點個數，這樣就可以不用把數據切分，也避免了內存溢出等問題。同理，當數據量龐大時，也可以通過增加存儲節點來解決存儲問題。所以本文搭建的平臺不僅擁有良好的計算擴展性，也有良好的存儲擴展性，不需要進行很多復雜的配置就能解決海量日志數據處理的問題。

5 結 語

本文以Hadoop生態系統作為數據挖掘工具，搭建了一套高可靠、高擴展的數據挖掘集群，結合MySQL數據庫，在現有的公開網絡日志數據集上設計了一種網絡日志挖掘方案。利用MapReduce框架對原始數據集進行過濾算法的設計，清洗出高質量的目標數據，使用工具Sqoop和Hive分析暗數據，挖掘出瀏覽量PV排名、IP數 （訪客數）、流量排名前十的IP等很多有隱含價值的信息，提供給企業進行決策。實驗表明，本文提出的方案有效可行。在接下來的研究中，將重點挖掘分析每日新增的訪客數，瀏覽板塊熱度等信息，并且需要設計如何周期性地把明細日志導入HBase中存儲，如何周期性地使用Hive進行日志的多維分析等問題。

注：本文通訊作者為吳云。

參考文獻

[1] YU H Y， WANG D S H. Mass log data processing and mining based on Hadoop and cloud computing [C]// Proceedings of 2012 the 7th International Conference on Computer Science and Education. Melbourne： IEEE， 2012： 197?202.

[2] MASSONET P， NAQVI S， PONSARD C， et al. A monitoring and audit logging architecture for data location compliance in federated cloud infrastructures [C]// Proceedings of 2011 IEEE International Symposium on Parallel and Distributed Processing Workshops. [S.l.]： IEEE， 2011： 1510?1517.

[3] Gartner IT Glossary. Dark data [EB/OL]. [2015?03?16]. http：//www.gartner.com/it?glossary/dark?data.

[4] 郭逸重.Hadoop分布式數據清洗方案[D].廣州：華南理工大學，2012.

[5] 楊富華.網絡日志預處理中優化的會話識別算法[J].計算機仿真，2011（4）：123?125.

[6] 任凱，鄧武，俞琰.基于大數據技術的網絡日志分析系統研究[J].現代電子技術，2016，39（2）：39?41.

[7] GHEMAWAT S， GOBIOFF H， LEUNG S T. The Google file system [C]// Proceedings of 2003 the 19th ACM Symposium on Operating Systems Principles. New York： ACM， 2003： 29?43.

[8] 陳吉榮，樂嘉錦.基于Hadoop生態系統的大數據解決方案綜述[J].計算機工程與科學，2013，35（10）：25?35.

[9] 顧榮，王芳芳，袁春風，等.YARM：基于MapReduce的高效可擴展的語義推理引擎[J].計算機學報，2015（1）：74?85.

[10] 楊東華，李寧寧，王宏志，等.基于任務合并的并行大數據清洗過程優化[J].計算機學報，2016（1）：97?108.

[11] 鄒培忠.網站評價指標與建設現狀分析[J].計算機光盤軟件與應用，2012（20）：151?155.