1. 程式人生 > 其它 >海量Web日誌分析 用Hadoop提取KPI統計指標

海量Web日誌分析 用Hadoop提取KPI統計指標

Web日誌包含著網站最重要的資訊,通過日誌分析,我們可以知道網站的訪問量,哪個網頁訪問人數最多,哪個網頁最有價值等。一般中型的網站(10W的PV以上),每天會產生1G以上Web日誌檔案。大型或超大型的網站,可能每小時就會產生10G的資料量。

對於日誌的這種規模的資料,用Hadoop進行日誌分析,是最適合不過的了。

目錄

  1. Web日誌分析概述
  2. 需求分析:KPI指標設計
  3. 演算法模型:Hadoop並行演算法
  4. 架構設計:日誌KPI系統架構
  5. 程式開發1:用Maven構建Hadoop專案

1. Web日誌分析概述

Web日誌由Web伺服器產生,可能是Nginx, Apache, Tomcat等。從Web日誌中,我們可以獲取網站每類頁面的PV值(PageView,頁面訪問量)、獨立IP數;稍微複雜一些的,可以計算得出使用者所檢索的關鍵詞排行榜、使用者停留時間最高的頁面等;更復雜的,構建廣告點選模型、分析使用者行為特徵等等。

在Web日誌中,每條日誌通常代表著使用者的一次訪問行為,例如下面就是一條nginx日誌:

222.68.172.190 - - [18/Sep/2013:06:49:57 +0000] "GET /images/my.jpg HTTP/1.1" 200 19939
 "http://www.angularjs.cn/A00n" "Mozilla/5.0 (Windows NT 6.1)
 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36"

拆解為以下8個變數

  • remote_addr: 記錄客戶端的ip地址, 222.68.172.190
  • remote_user: 記錄客戶端使用者名稱稱, –
  • time_local: 記錄訪問時間與時區, [18/Sep/2013:06:49:57 +0000]
  • request: 記錄請求的url與http協議, “GET /images/my.jpg HTTP/1.1”
  • status: 記錄請求狀態,成功是200, 200
  • body_bytes_sent: 記錄傳送給客戶端檔案主體內容大小, 19939
  • http_referer: 用來記錄從那個頁面連結訪問過來的, “http://www.angularjs.cn/A00n”
  • http_user_agent: 記錄客戶瀏覽器的相關資訊, “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36”

注:要更多的資訊,則要用其它手段去獲取,通過js程式碼單獨傳送請求,使用cookies記錄使用者的訪問資訊。

利用這些日誌資訊,我們可以深入挖掘網站的祕密了。

少量資料的情況

少量資料的情況(10Mb,100Mb,10G),在單機處理尚能忍受的時候,我可以直接利用各種Unix/Linux工具,awk、grep、sort、join等都是日誌分析的利器,再配合perl, python,正則表達工,基本就可以解決所有的問題。

例如,我們想從上面提到的nginx日誌中得到訪問量最高前10個IP,實現很簡單:

~ cat access.log.10 | awk '{a[$1]++} END {for(b in a) print b"t"a[b]}' | sort -k2 -r | head -n 10
163.177.71.12   972
101.226.68.137  972
183.195.232.138 971
50.116.27.194   97
14.17.29.86     96
61.135.216.104  94
61.135.216.105  91
61.186.190.41   9
59.39.192.108   9
220.181.51.212  9

海量資料的情況

當資料量每天以10G、100G增長的時候,單機處理能力已經不能滿足需求。我們就需要增加系統的複雜性,用計算機叢集,儲存陣列來解決。在Hadoop出現之前,海量資料儲存,和海量日誌分析都是非常困難的。只有少數一些公司,掌握著高效的平行計算,分步式計算,分步式儲存的核心技術。

Hadoop的出現,大幅度的降低了海量資料處理的門檻,讓小公司甚至是個人都能力,搞定海量資料。並且,Hadoop非常適用於日誌分析系統。

2.需求分析:KPI指標設計

下面我們將從一個公司案例出發來全面的解釋,如何用進行海量Web日誌分析,提取KPI資料

案例介紹 某電子商務網站,在線團購業務。每日PV數100w,獨立IP數5w。使用者通常在工作日上午10:00-12:00和下午15:00-18:00訪問量最大。日間主要是通過PC端瀏覽器訪問,休息日及夜間通過移動裝置訪問較多。網站搜尋瀏量佔整個網站的80%,PC使用者不足1%的使用者會消費,移動使用者有5%會消費。

通過簡短的描述,我們可以粗略地看出,這家電商網站的經營狀況,並認識到願意消費的使用者從哪裡來,有哪些潛在的使用者可以挖掘,網站是否存在倒閉風險等。

KPI指標設計

  • PV(PageView): 頁面訪問量統計
  • IP: 頁面獨立IP的訪問量統計
  • Time: 使用者每小時PV的統計
  • Source: 使用者來源域名的統計
  • Browser: 使用者的訪問裝置統計

注:商業保密限制,無法提供電商網站的日誌。 下面的內容,將以我的個人網站為例提取資料進行分析。

百度統計,對我個人網站做的統計!http://www.fens.me

基本統計指標:

使用者的訪問裝置統計指標:

從商業的角度,個人網站的特徵與電商網站不太一樣,沒有轉化率,同時跳出率也比較高。從技術的角度,同樣都關注KPI指標設計。

3.演算法模型:Hadoop並行演算法

並行演算法的設計: 注:找到第一節有定義的8個變數

PV(PageView): 頁面訪問量統計

  • Map過程{key:$request,value:1}
  • Reduce過程{key:$request,value:求和(sum)}

IP: 頁面獨立IP的訪問量統計

  • Map: {key:$request,value:$remote_addr}
  • Reduce: {key:$request,value:去重再求和(sum(unique))}

Time: 使用者每小時PV的統計

  • Map: {key:$time_local,value:1}
  • Reduce: {key:$time_local,value:求和(sum)}

Source: 使用者來源域名的統計

  • Map: {key:$http_referer,value:1}
  • Reduce: {key:$http_referer,value:求和(sum)}

Browser: 使用者的訪問裝置統計

  • Map: {key:$http_user_agent,value:1}
  • Reduce: {key:$http_user_agent,value:求和(sum)}

4.架構設計:日誌KPI系統架構

上圖中,左邊是Application業務系統,右邊是Hadoop的HDFS, MapReduce。

  1. 日誌是由業務系統產生的,我們可以設定web伺服器每天產生一個新的目錄,目錄下面會產生多個日誌檔案,每個日誌檔案64M。
  2. 設定系統定時器CRON,夜間在0點後,向HDFS匯入昨天的日誌檔案。
  3. 完成匯入後,設定系統定時器,啟動MapReduce程式,提取並計算統計指標。
  4. 完成計算後,設定系統定時器,從HDFS匯出統計指標資料到資料庫,方便以後的即使查詢。

上面這幅圖,我們可以看得更清楚,資料是如何流動的。藍色背景的部分是在Hadoop中的,接下來我們的任務就是完成MapReduce的程式實現。

5.程式開發1:用Maven構建Hadoop專案

請參考文章:用Maven構建Hadoop專案

win7的開發環境 和 Hadoop的執行環境 ,在上面文章中已經介紹過了。

我們需要放日誌檔案,上傳的HDFS裡/user/hdfs/log_kpi/目錄,參考下面的命令操作

~ hadoop fs -mkdir /user/hdfs/log_kpi
~ hadoop fs -copyFromLocal /home/conan/datafiles/access.log.10 /user/hdfs/log_kpi/

我已經把整個MapReduce的實現都放到了github上面:

https://github.com/bsspirit/maven_hadoop_template/releases/tag/kpi_v1