許抗震++吳云

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

關(guān)鍵詞： 網(wǎng)絡(luò)日志； 數(shù)據(jù)挖掘； 數(shù)據(jù)清洗； Hadoop； MySQL

中圖分類號(hào)： TN711?34； TP391.9 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 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 引 言

隨著信息爆炸時(shí)代的到來，在日常生活中每天都會(huì)產(chǎn)生指數(shù)級(jí)的數(shù)據(jù)，特別是網(wǎng)絡(luò)日志，這就必然帶來一系列的問題。一方面數(shù)據(jù)存儲(chǔ)量過于龐大而且存儲(chǔ)資源有限，另一方面?zhèn)鹘y(tǒng)的計(jì)算方式使得計(jì)算過程周期過長，計(jì)算資源得不到合理分配。隨著Apache公司Hadoop的誕生，利用低價(jià)的集群實(shí)現(xiàn)了強(qiáng)大的計(jì)算和海量存儲(chǔ)，并且在網(wǎng)絡(luò)日志挖掘這一領(lǐng)域出現(xiàn)了一些應(yīng)用研究[1?2]。本文的一個(gè)目的就是研究Hadoop框架及其生態(tài)系統(tǒng)成員，搭建出一種基于Hadoop生態(tài)系統(tǒng)成員Zookeeper的高可靠（High Available，HA）集群并進(jìn)行優(yōu)化。

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

結(jié)合Hadoop和編程思想進(jìn)行自底向上分架構(gòu)的設(shè)計(jì)[6]：數(shù)據(jù)存儲(chǔ)層、業(yè)務(wù)邏輯層、應(yīng)用層。最后用實(shí)驗(yàn)測(cè)試平臺(tái)的性能，并且用某網(wǎng)站的日志數(shù)據(jù)做實(shí)驗(yàn)挖掘出有價(jià)值的信息，供企業(yè)進(jìn)行決策和改善用戶體驗(yàn)。

1 Hadoop生態(tài)系統(tǒng)主要成員

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

HDFS：一個(gè)主從結(jié)構(gòu)的分布式文件系統(tǒng)類似于GFS用于存儲(chǔ)大量數(shù)據(jù)[8]。

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

YARN：一種新的資源協(xié)調(diào)管理系統(tǒng)，可以部署上層應(yīng)用，大大提高了集群的利用率[9]。

Flume：一個(gè)高可靠的分布式海量日志收集系統(tǒng)。

ZooKeeper：一個(gè)能夠提供協(xié)調(diào)服務(wù)的分布式協(xié)調(diào)服務(wù)框架。

Sqoop：Hadoop與外界的一個(gè)數(shù)據(jù)遷移工具。

Hive：可以進(jìn)行多維分析的數(shù)據(jù)倉庫系統(tǒng)。

2 基于Hadoop的網(wǎng)絡(luò)日志挖掘方案的設(shè)計(jì)

當(dāng)前，很多網(wǎng)站每天都會(huì)產(chǎn)生指數(shù)級(jí)別的日志數(shù)據(jù)，由于這些數(shù)據(jù)是一種暗數(shù)據(jù)，很多企業(yè)并不重視，這就造成了許多具有價(jià)值的信息被埋沒。而且目前的數(shù)據(jù)挖掘很多都是基于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，挖掘時(shí)間很長、效率底下，影響了業(yè)務(wù)決策。本文利用廉價(jià)的計(jì)算機(jī)集群設(shè)計(jì)搭建一種基于網(wǎng)絡(luò)日志數(shù)據(jù)的挖掘方案來解決這些問題。

2.1 設(shè)計(jì)架構(gòu)

網(wǎng)絡(luò)日志數(shù)據(jù)具有異構(gòu)性、多樣性、復(fù)雜性等特點(diǎn)，結(jié)合網(wǎng)絡(luò)日志數(shù)據(jù)的這些特點(diǎn)和編程思想把平臺(tái)的設(shè)計(jì)分為三層架構(gòu)，如圖1所示。

數(shù)據(jù)存儲(chǔ)層：包括日志收集系統(tǒng)和底層數(shù)據(jù)的存儲(chǔ)計(jì)算，日志收集系統(tǒng)主要負(fù)責(zé)網(wǎng)站日志的收集，然后調(diào)用過濾算法進(jìn)行過濾，以文件形式傳入到Data Node底層數(shù)據(jù)節(jié)點(diǎn)上進(jìn)行存儲(chǔ)，所有的計(jì)算結(jié)果也是在數(shù)據(jù)存儲(chǔ)層，包括清洗過的中間數(shù)據(jù)、數(shù)據(jù)挖掘的結(jié)果、日志的元數(shù)據(jù)等。

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

應(yīng)用層：利用業(yè)務(wù)邏輯層中的分析結(jié)果，例如VIP用戶、板塊熱度、瀏覽量PV等用戶特征和流量統(tǒng)計(jì)結(jié)果可以定位目標(biāo)用戶群，進(jìn)行精準(zhǔn)的營銷方案設(shè)計(jì)，還可以針對(duì)冷清網(wǎng)頁板塊進(jìn)行改善，提高網(wǎng)站的用戶體驗(yàn)等決策服務(wù)支持。

2.2 節(jié)點(diǎn)的規(guī)劃

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

2.3 搭建主要步驟

（1） 首先安裝配置Zookeeper，然后將配置好的zookeeper拷貝到itcast05和itcast06節(jié)點(diǎn)下。

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

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

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

3 網(wǎng)絡(luò)日志數(shù)據(jù)的分析與挖掘

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

3.1 數(shù)據(jù)清洗算法和KPI的設(shè)計(jì)

3.1.1 清洗算法設(shè)計(jì)

實(shí)驗(yàn)所用的日志數(shù)據(jù)是某網(wǎng)站的公開數(shù)據(jù)集合，原始數(shù)據(jù)的格式如表1所示。一共54萬行數(shù)據(jù)，日志數(shù)據(jù)每行由6部分組成：用戶IP、請(qǐng)求日期、請(qǐng)求方式、訪問資源、訪問狀態(tài)、訪問流量。首先把數(shù)據(jù)上傳到HDFS，然后根據(jù)數(shù)據(jù)格式設(shè)計(jì)過濾算法。

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

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

Mapper函數(shù){開始循環(huán)Map方法

Map（LongWritable key， Text value） {

value轉(zhuǎn)化為字符串賦值給line； //讀入一行記錄

LogFilter類實(shí)例化調(diào)用parse返回一個(gè)數(shù)組logs；

//logs[0]裝用戶IP，logs[1]請(qǐng)求日期等5部分?jǐn)?shù)據(jù)

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

返回；}

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

跳出函數(shù)進(jìn)行下一次循環(huán)；}

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

跳出函數(shù)進(jìn)行下一次循環(huán)；}

序列化（logs數(shù)組）放入vl對(duì)象； //經(jīng)過過濾后的數(shù)據(jù)

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

}

}

因?yàn)椴恍枰判蚝徒M合，所以Reduce函數(shù)按輸入輸出。

3.1.2 KPI的設(shè)計(jì)

數(shù)據(jù)挖掘和數(shù)據(jù)分析的最大不同就是，數(shù)據(jù)挖掘的目標(biāo)信息并不明確，應(yīng)用到的技術(shù)和算法也不確定，又因?yàn)榫W(wǎng)絡(luò)日志數(shù)據(jù)中往往含有大量衡量一個(gè)網(wǎng)站關(guān)鍵的指標(biāo)，所以本文根據(jù)這些關(guān)鍵指標(biāo)來指定KPI的設(shè)計(jì)。

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

定義：頁面被訪客瀏覽的次數(shù)，每個(gè)獨(dú)立用戶只要瀏覽一個(gè)頁面次數(shù)就加一次[11]。

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

公式：記錄次數(shù)。

（2） IP個(gè)數(shù)

定義：一段時(shí)間內(nèi)訪問網(wǎng)站的不同IP 數(shù)量和[11]。

分析：一般來講，IP的數(shù)量與網(wǎng)站的訪問用戶成正比。

公式：對(duì)不同IP進(jìn)行計(jì)數(shù)。

（3） 跳出率

定義：訪問網(wǎng)站的某個(gè)頁面后便離開的訪客數(shù)占總的訪客數(shù)的百分比[11]。

分析：跳出率可以衡量網(wǎng)站對(duì)于用戶的吸引程度并且呈反比。

公式：統(tǒng)計(jì)一天內(nèi)只出現(xiàn)一條記錄的IP，稱為跳出數(shù)

跳出率=100%

（4） 版塊熱度排行榜

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

分析：熱度反映了用戶是否喜歡網(wǎng)頁中的某板塊，可以幫助企業(yè)鞏固熱點(diǎn)版塊，加強(qiáng)冷清版塊建設(shè)。

公式：按訪問次數(shù)、停留時(shí)間統(tǒng)計(jì)排序。

3.2 使用Hive進(jìn)行數(shù)據(jù)挖掘

（1） 初始化

在Hive下創(chuàng)建一個(gè)外部表，用來連接HDFS上的數(shù)據(jù)，并把這張外表源數(shù)據(jù)存儲(chǔ)在MySQL中。

（2） 寫shell腳本

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

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

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

圖4便是某一天流量排前三的用戶，說明這幾個(gè)用戶不僅僅是經(jīng)常瀏覽網(wǎng)站的老客戶，而且也是流量貢獻(xiàn)較多的客戶，可以針對(duì)這些老客戶進(jìn)行個(gè)性化營銷推薦。

（4） 查詢點(diǎn)擊量前十的用戶

在Hive中輸入查詢點(diǎn)擊量命令，結(jié)果如表2所示。

可以把表2中這些用戶當(dāng)作VIP用戶群，對(duì)這些用戶群進(jìn)行重點(diǎn)關(guān)注。

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

用Sqoop導(dǎo)入到MySQL中，如圖5所示。

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

4 平臺(tái)優(yōu)化與實(shí)驗(yàn)測(cè)試

4.1 平臺(tái)優(yōu)化

Hadoop平臺(tái)的優(yōu)化主要有以下幾個(gè)方面：

（1） 合適的硬件選擇

Namenode應(yīng)選擇大內(nèi)存、多路多核、高主頻的CPU，Datanode內(nèi)存根據(jù)CPU的虛擬核數(shù)（vcore）進(jìn)行公式配比。

vcore數(shù)=CPU個(gè)數(shù)×CPU核數(shù)×HT（超線程數(shù)）

內(nèi)存大小=vcore×2 GB

（2） 操作系統(tǒng)和JVM優(yōu)化

首先不使用可能導(dǎo)致操作超時(shí)的swap分區(qū)，其次根據(jù)vm.overcommit_memory的值決定分配策略，設(shè)為2。vm.overcommit_ratio的值設(shè)定為超過物理內(nèi)存的比例10%，最后關(guān)閉THP（Transparent Pages）并開啟JVM重用。

（3） Hadoop參數(shù)優(yōu)化

Hadoop有80多個(gè)參數(shù)和性能有關(guān)，主要是HDFS，YARN和Mapreduce優(yōu)化。塊大?。╠fs.block.size）就是默認(rèn)的64M，中間結(jié)果設(shè)置分布在多機(jī)器（mapred.local.dir），分片大小和塊大小一致。優(yōu)化后的操作性能耗時(shí)減少了3.26%，如圖6所示。

4.2 試驗(yàn)測(cè)試

為了減少偶然性的干擾且相對(duì)準(zhǔn)確地測(cè)出結(jié)果，測(cè)試的數(shù)據(jù)都是四次以上取平均值。

測(cè)試一：驗(yàn)證平臺(tái)的高可靠性

首先向hdfs上傳一個(gè)文件，然后再kill掉Active的NameNode。用瀏覽器訪問：http：//192.168.1.202：50070，Standby狀態(tài)的主節(jié)點(diǎn)就變成了Active狀態(tài)，再執(zhí)行命令Hadoop fs ?ls/，剛才上傳的文件依然存在，手動(dòng)啟動(dòng)那個(gè)宕機(jī)的NameNode，顯示NameNode ′itcast02：9000′（standby），這就保證了平臺(tái)的高可靠性。

測(cè)試二：日志文件個(gè)數(shù)對(duì)平臺(tái)I/O速度的影響

首先進(jìn)行總大小都為100 MB，日志文件個(gè)數(shù)分別為10，30，50的讀操作，然后再進(jìn)行總大小都為100 MB，日志文件個(gè)數(shù)分別為10，30，50的寫操作，結(jié)果如圖7所示。

隨著文件個(gè)數(shù)的增多，讀寫時(shí)間明顯變長，所以本平臺(tái)比較適合大規(guī)模的日志文件，對(duì)于小文件處理將會(huì)花費(fèi)較多時(shí)間。在文件總大小一樣的情況下，隨著文件個(gè)數(shù)的增加，讀操作耗時(shí)平均增加52.58%，寫操作耗時(shí)平均增加79.69%。

測(cè)試三：平臺(tái)和單機(jī)在查詢性能上的對(duì)比

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

從圖8可以看出，當(dāng)數(shù)據(jù)量很少時(shí)，用單機(jī)進(jìn)行數(shù)據(jù)挖掘效率很高，但是隨著數(shù)據(jù)量的增大，單機(jī)效率明顯下降，而且很可能會(huì)存在內(nèi)存溢出的問題，數(shù)據(jù)需要預(yù)先拆分才能完成挖掘任務(wù)，與單機(jī)相比，本文搭建的數(shù)據(jù)平臺(tái)具有極高的性能查詢能力，能夠很好的勝任海量的網(wǎng)絡(luò)日志挖掘。

測(cè)試四：平臺(tái)的擴(kuò)展性

本文搭建的平臺(tái)部署了6個(gè)節(jié)點(diǎn)，測(cè)試時(shí)每次增加一個(gè)計(jì)算節(jié)點(diǎn)，組成節(jié)點(diǎn)個(gè)數(shù)分別為6，7，8，9的集群，查詢16萬條日志數(shù)據(jù)排名前十的頁面瀏覽量所耗時(shí)間如表3所示。

由表3可以看出隨著節(jié)點(diǎn)的增加，計(jì)算耗時(shí)以平均8.87%的速度減少，平臺(tái)的高擴(kuò)展性隨之展現(xiàn)，當(dāng)遇到海量數(shù)據(jù)處理時(shí)，只需要增加計(jì)算節(jié)點(diǎn)個(gè)數(shù)，這樣就可以不用把數(shù)據(jù)切分，也避免了內(nèi)存溢出等問題。同理，當(dāng)數(shù)據(jù)量龐大時(shí)，也可以通過增加存儲(chǔ)節(jié)點(diǎn)來解決存儲(chǔ)問題。所以本文搭建的平臺(tái)不僅擁有良好的計(jì)算擴(kuò)展性，也有良好的存儲(chǔ)擴(kuò)展性，不需要進(jìn)行很多復(fù)雜的配置就能解決海量日志數(shù)據(jù)處理的問題。

5 結(jié) 語

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

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

參考文獻(xiàn)

[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分布式數(shù)據(jù)清洗方案[D].廣州：華南理工大學(xué)，2012.

[5] 楊富華.網(wǎng)絡(luò)日志預(yù)處理中優(yōu)化的會(huì)話識(shí)別算法[J].計(jì)算機(jī)仿真，2011（4）：123?125.

[6] 任凱，鄧武，俞琰.基于大數(shù)據(jù)技術(shù)的網(wǎng)絡(luò)日志分析系統(tǒng)研究[J].現(xiàn)代電子技術(shù)，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生態(tài)系統(tǒng)的大數(shù)據(jù)解決方案綜述[J].計(jì)算機(jī)工程與科學(xué)，2013，35（10）：25?35.

[9] 顧榮，王芳芳，袁春風(fēng)，等.YARM：基于MapReduce的高效可擴(kuò)展的語義推理引擎[J].計(jì)算機(jī)學(xué)報(bào)，2015（1）：74?85.

[10] 楊東華，李寧寧，王宏志，等.基于任務(wù)合并的并行大數(shù)據(jù)清洗過程優(yōu)化[J].計(jì)算機(jī)學(xué)報(bào)，2016（1）：97?108.

[11] 鄒培忠.網(wǎng)站評(píng)價(jià)指標(biāo)與建設(shè)現(xiàn)狀分析[J].計(jì)算機(jī)光盤軟件與應(yīng)用，2012（20）：151?155.