網站日誌統計案例分析與實現

1.概要

    到這一步,如果按照前面到文章一步走來,不出意外,我想hadoop平臺環境應該搭建OK了。下面我以本身工做中實際的案例來梳理一下整個流程。同時參考一些其餘的文章來分析,因爲不少網站的日誌KPI都大同小異,故有些指標直接在文中贅述了。javascript

2.流程

  1. 背景
  2. 前言
  3. 目錄
  4. 日誌分析概述
  5. 需求分析
  6. 源碼

2.1 背景

  從2011年開始,中國進入大數據時代如火如荼,以Hadoop爲表明的套件,佔據了大數據處理的廣闊地盤。開源界及廠商,全部數據軟件,紛紛向Hadoop靠攏。Hadoop也從小規模的試點和使用,變成了大數據開發的標準。在Hadoop原有技術基礎之上,出現了Hadoop家族產品,經過大數據概念的不斷創新,推動了Hadoop的發展速度。java

  現在,Hadoop2.x的出現,使不少企業紛紛主動去接受Hadoop這個平臺,所以,做爲IT界的開發人員,瞭解並掌握Hadoop的技能,成爲開發人員必備的一項技能。也是從此主流的一種趨勢。python

  注:Hadoop2.x的出現爲什麼引發這麼大大反響,這裏不作贅述。mysql

2.2 前言

  Web日誌包含着網站最重要的信息,經過日誌分析,咱們能夠知道網站的訪問量,哪一個網頁訪問人數最多,哪一個網頁最有價值等。通常中型的網站(10w的PV以上),天天會產生1G以上的Web日誌文件。大型或超大型的網站,可能每小時就產生10G的數據量。angularjs

       對於日誌的這種規模的數據,用Hadoop進行日誌分析,是最合適不過了。正則表達式

2.3 目錄

  • Web日誌分析概述
  • 需求分析:KPI指標設計
  • 算法模型:Hadoop並行算法
  • 架構設計:日誌KPI系統架構
  • 項目構建:Maven構建Hadoop項目

2.4 Web日誌分析概述

  Web日誌由Web服務器產生,多是Nginx,Apache,Tomcat等。從Web日誌中,咱們能夠獲取網站每類頁面的PV值、獨立IP數;稍微複雜一些的,能夠計算得出用戶所檢索的關鍵詞排行榜、用戶停留時間最高的頁面等;更復雜的,構建廣告點擊模型、分析用戶行爲特徵等等。算法

  Web日誌中,每條日誌一般表明着用戶的一次訪問行爲,例以下面就是一條Nginx日誌:sql

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個指標:瀏覽器

  1. Remote_Addr:記錄客戶端的IP地址,222.68.172.190服務器

  2. Remote_User:記錄客戶端用戶名稱,-

  3. Time_Local:記錄訪問時間與時區:[18/Sep/2013:06:49:57 +0000]

  4. Request:記錄請求的URL和HTTP協議,"GET /images/my.jpg HTTP/1.1"

  5. Status:記錄請求狀態,成功是200,200

  6. Body_Bytes_Sent:記錄發送給客戶端文件主體內容大小,19939

  7. Http_Referer:用來記錄從哪一個頁面連接訪問過來的,http://www.angularjs.cn/A00n

  8. Http_User_Agent:記錄客戶端瀏覽器的相關信息,"Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36"

  注:要更多的信息,則須要其它手段去獲取,經過javascript代碼單獨發送請求,使用cookies記錄用戶訪問信息。利用這些日誌信息,咱們能夠深刻挖掘網站的祕密了。

  少許數據的狀況:

  少許數據的狀況(10M,100M,1G),在單機處理尚能接受的時候,咱們能夠直接利用各類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.5  KPI指標設計

  下面咱們將從一個公司案例出發來全面的詮釋,如何進行海量Web日誌分析,提早KPI數據。

2.5.1  案例介紹 

  某電商網站,在線團購業務。每日PV數100w,獨立IP數5w;用戶一般在工做日上午10:00-12:00和下午15:00-18:00訪問量最大;日間主要是經過PC端瀏覽器訪問,休息日及夜間經過移動設備訪問最多。網站搜索流量佔整個網站的80%,PC用戶不足1%的用戶會消費,移動用戶有5%會消費。

  經過簡短的描述,咱們能夠粗略的看出這家電商網站的經營情況,並認識到願意消費的用戶是從哪裏來,有哪些潛在的用戶能夠挖掘,網站是否存在倒閉風險等。

2.5.2  KPI指標設計

  • PV:頁面訪問量統計
  • IP:頁面獨立IP訪問量統計
  • Time:用戶每小時PV統計
  • Source:用戶來源域名的統計
  • Browser:用戶的訪問設備統計

    注:很遺憾,因爲商業緣由,沒法提供電商網站的日誌。這裏我取的是某論壇的日誌分析,原理都是同樣的,指標也相似。

2.6  項目構建

  這裏Hadoop的項目,咱們採用Maven結構來構建項目,這樣可以保證整個項目的清爽,對依賴包可以統一的進行管理,在項目的打包和發佈上也是大有裨益。

  注:如何建立Maven項目這裏不作贅述,能夠自行查找相應的資料。

3.實現

  指標咱們已經分析的很明確了,下面咱們來考慮如何實現這些指標,以及實現這些指標須要用到那些技術,下面我畫了一個實現的流程圖:

因爲是在Retina屏下截取的,因此分辨率會有點高,若網絡有故障,估計圖會展現不了,於是,下面我也用文字描述一下整個流程。

  首先咱們須要獲取這些日誌文件,獲取的方式有多種,這裏咱們只列出了比較工做中使用的2種方式,少許的日誌能夠直接使用腳本上傳到HDFS,海量日誌可使用Flume進行上傳到HDFS,而後咱們將上傳在HDFS到日誌進行清洗(按指標清洗,去掉一些異常數據),將清洗後到數據重定向到新的HDFS目錄中,接下來咱們能夠按指標來進行統計結果,統計的方式,這裏我也列出了工做中使用的2種方式,一種是編寫MR任務進行統計,另外一種是使用hive來統計,最後將統計的結果使用sqoop導出到mysql或是oracle中保存(明晰存儲在HBase中)。到這裏整理工做就算是結束,至於如何使用統計出來的數據,這裏不是咱們所考慮的範圍。

4.源碼

  關於源代碼,目前有些部分代碼要從源代碼中分離出來,到時候我會把這個日誌分析系統項目的代碼放在Github上,整理完後連接到時候會放在這片博文的下面。另外有什麼問題能夠加羣諮詢,或發郵件給我,我會盡我所能給予幫助。與君共勉!

相關文章
相關標籤/搜索