教你如何分析網站日志
      日志在計算機中的概念非常廣泛，日志內容、規(guī)模和用途也各不相同，新圖聞在此討論的日志僅指Web日志。

       在Web日志中，每條日志一般代表著用戶的一次訪問行為，下面就是一條典型的apache日志：

211.87.152.44 – - [18/Mar/2005:12:21:42 +0800] “GET / HTTP/1.1″ 200 899 “http://www.baidu.com/” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon)”

      從這條日志中可以得到的信息，如訪問者IP、訪問時間、訪問的目標網頁、IP來源以及訪問者所使用的客戶端的UserAgent信息等。

    分析日志的目的是什么：

     Web日志中包含了大量的信息：頁面的PV值（PageView，頁面訪問量）；IP數(shù)（即去重之后的IP數(shù)量）；檢索的關鍵詞排行榜、用戶停留時間高的頁面；構建廣告點擊模型、用戶行為特征等等。

    現(xiàn)在已經有無數(shù)的工具可以分析Web日志，例如awstats、Webalizer，都是專門用于統(tǒng)計分析Web服務器日志的免費程序。

      還有一類產品不分析直接日志，而是通過讓用戶在頁面中嵌入js代碼的方式來直接進行數(shù)據統(tǒng)計，或者說我們可以認為它是直接讓日志輸出到了它們的服務器。代表產品：Google Analytics，cnzz、百度統(tǒng)計等。

      既然如此，我們?yōu)槭裁催€需要自己來分析日志？我們的用戶（產品分析人員）需求是無窮盡的，上面的工具雖然很強大，但沒辦法滿足全部的需求。

   它們雖然提很豐富的的統(tǒng)計分析功能，可以做一定程度的配置，但是依然很有限的。絕大多數(shù)日志分析工具都是只能用于單機，也都有大流量的限制。

   怎么分析日志

  對于少量數(shù)據

   現(xiàn)成的各種Unix/Linux工具——awk、grep、sort、join等都是日志分析的利器；如果有稍復雜的邏輯，那就使用各種腳本語言，尤其是perl，配合偉大的正則表達式，基本就可以解決所有的問題。

    要使用數(shù)據庫來進行日志分析還是需要一些代價的，主要的就是如何將各種異構的日志文件導入的數(shù)據庫中——這個過程通常稱為ETL（Extraction-Transformation-Loading）。幸好依然有各種現(xiàn)成的開源、免費的工具來幫助我們做這件事情，并且在日志種類不太多的時候，自己寫幾個簡單的腳本來完成這項工作也并不困難。

     使用數(shù)據庫的好處之一就是，偉大的SQL可以幫我們很簡單的完成絕大部分的統(tǒng)計分析工作——PV只需要SELECT+COUNT，計算搜索詞排行只需要SELECT+COUNT+GROUP+ORDER+LIMIT。此外，數(shù)據庫本身的結構化存儲模式也讓日志數(shù)據的管理變的更簡單，減少運維代價。

   至于性能問題，數(shù)據庫的索引和各種優(yōu)化機制通常會讓我們的統(tǒng)計分析工作變得更快，并且上面提到的Infobright和Infinidb都專門為類似SUM、COUNt之類的聚集應用做了優(yōu)化。當然也不是絕對的會快，例如在數(shù)據庫中進行LIKE操作，通常會比grep一個文件還要慢很多。

    更進一步的，使用基于數(shù)據庫的存儲，可以很容易的進行OLAP（聯(lián)機分析處理）應用，從日志中挖掘價值會變的更加簡單。

更多的數(shù)據怎么辦

   一個好的數(shù)據庫似乎會讓事情變的很簡單，但是別忘了前面提到的都是單機數(shù)據庫。

   要徹底解決數(shù)據規(guī)模增長帶來的問題，很自然的會想到使用分布式技術，結合上面的結論，也許使用某個分布式數(shù)據庫是一個好選擇，那么對終用戶就可以完全透明了。

   首先，實現(xiàn)比較完美的分布式數(shù)據庫（受限于CAP原則）是一個非常復雜的問題，因此在這里并不像單機數(shù)據庫那樣，有那么多開源的好東西可以用，甚至于商用的也并不是太多。當然，也并非絕對，如果有錢，還是可以考慮一下Oracle RAC、Greenplum之類東西。

  其次，絕大多數(shù)分布式數(shù)據庫都是NoSQL的，所以想繼續(xù)用上SQL的那些優(yōu)點基本上是沒指望，取而代之的都是一些簡單、難以使用的接口。單從這點看來，使用這些數(shù)據庫的價值已經降低很多了。

    所以，還是先現(xiàn)實一點，先退一步考慮如何解決的超大規(guī)模的日志的分析問題，而不是想如何讓它變的像在小數(shù)據規(guī)模時那樣簡單。單單想做到這點，目前看來并不是太難，并且依然有免費的午餐可以吃。

Hadoop是偉大的Apache基金會下面的一套分布式系統(tǒng)，包括分布式文件系統(tǒng)（HDFS）、MapReduce計算框架、HBase等很多組件——這些基本都是Google的GFS/MapReduce/BigTable的克隆產品。

Hadoop經過數(shù)年的發(fā)展，目前已經很成熟了，尤其是其中的HDFS和MapReduce計算框架組件。數(shù)百臺機器的集群已經被證明可以使用，可以承擔PB級別的數(shù)據。

Hadoop項目中的HBase是一個按列存儲的NoSQL分布式數(shù)據庫，它提供的功能和接口都非常簡單，只能進行簡單的K-V查詢，因此并不直接適用于大多數(shù)日志分析應用。所以一般使用Hadoop來做日志分析，首先還是需要將日志存儲在HDFS中，然后再使用它提供的MapReduce API編寫日志分析程序。

MapReduce是一種分布式編程模型，并不難學習，但是很顯然使用它來處理日志的代價依然遠大于單機腳本或者SQL。一個簡單的詞頻統(tǒng)計計算可能都需要上百代碼——SQL只需要一行，另外還有復雜的環(huán)境準備和啟動腳本。

    怎樣變得更簡單

    在超大規(guī)模的數(shù)據上做任何事情都不是一件容易的事情，包括日志分析，但也并不是說分布式的日志分析就一定要去寫MapReduce代碼，總是可以去做進一步的抽象，在特定的應用下讓事情變得更簡單。

   也許有人會很自然的想到如果能用SQL來操作Hadoop上的數(shù)據該有多好。事實上，不僅僅只有你一個人會這么想，很多人都這么想，并且他們實現(xiàn)了這個想法，于是就有了Hive。

     Hive現(xiàn)在也是Hadoop項目下面的一個子項目，它可以讓我們用SQL的接口來執(zhí)行MapReduce，甚至提供了JDBC和ODBC的接口。有了這個之后，Hadoop基本上被包裝成一個數(shù)據庫。當然實際上Hive的SQL終還是被翻譯成了MapReduce代碼來執(zhí)行，因此即使簡單的SQL可能也要執(zhí)行好幾十秒。幸好在通常的離線日志分析中，這個時間還是可以接受的。更重要的是，對于上面提到的例子，我們又可以用一樣的SQL來完成分析任務了。

    當然Hive并不是完全的兼容SQL語法，而且也不能做到完全的對用戶屏蔽細節(jié)。很多時候為了執(zhí)行性能的優(yōu)化，依然需要用戶去了解一些MapReduce的基本知識，根據自己的應用模式來設置一些參數(shù)，否則我們可能會發(fā)現(xiàn)一個查詢執(zhí)行很慢，或者壓根執(zhí)行不出來。

    隨著日志數(shù)據量、日志類型、用戶數(shù)量、分析需求等等的不斷增長，越來越多的問題會逐漸浮現(xiàn)出來，日志分析這件事情可能就不再像我們初想的那么簡單，會變得越來越有價值，也越來越有挑戰(zhàn)。
   新圖聞（ ） 服務全國 ！   大連網站建設  首選品牌！轉載請注明來路。