日志在計(jì)算機(jī)系統(tǒng)中是一個(gè)非常廣泛的概念，任何程序都有可能輸出日志：操作系統(tǒng)內(nèi)核、各種應(yīng)用服務(wù)器等等。日志的內(nèi)容、規(guī)模和用途也各不相同，很難一概而論。

　　本文討論的日志處理方法中的日志，僅指Web日志。其實(shí)并沒(méi)有精確的定義，可能包括但不限于各種前端Web服務(wù)器——apache、lighttpd、tomcat等產(chǎn)生的用戶訪問(wèn)日志，以及各種Web應(yīng)用程序自己輸出的日志。

　　在Web日志中，每條日志通常代表著用戶的一次訪問(wèn)行為，例如下面就是一條典型的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)”

　　從上面這條日志中，我們可以得到很多有用的信息，例如訪問(wèn)者的IP、訪問(wèn)的時(shí)間、訪問(wèn)的目標(biāo)網(wǎng)頁(yè)、來(lái)源的地址以及訪問(wèn)者所使用的客戶端的UserAgent信息等。如果需要更多的信息，則要用其它手段去獲取：例如想得到用戶屏幕的分辨率，一般需要使用js代碼單獨(dú)發(fā)送請(qǐng)求;而如果想得到諸如用戶訪問(wèn)的具體新聞標(biāo)題等信息，則可能需要Web應(yīng)用程序在自己的代碼里輸出。

　　為什么要分析日志

　　毫無(wú)疑問(wèn)，Web日志中包含了大量人們——主要是產(chǎn)品分析人員會(huì)感興趣的信息，最簡(jiǎn)單的，我們可以從中獲取網(wǎng)站每類頁(yè)面的PV值(PageView，頁(yè)面訪問(wèn)量)、獨(dú)立IP數(shù)(即去重之后的IP數(shù)量)等;稍微復(fù)雜一些的，可以計(jì)算得出用戶所檢索的關(guān)鍵詞排行榜、用戶停留時(shí)間最高的頁(yè)面等;更復(fù)雜的，構(gòu)建廣告點(diǎn)擊模型、分析用戶行為特征等等。

　　既然這些數(shù)據(jù)是如此的有用，那么當(dāng)然已經(jīng)有無(wú)數(shù)現(xiàn)成的工具可以幫助我們來(lái)分析它們，例如awstats、Webalizer，都是專門用于統(tǒng)計(jì)分析Web服務(wù)器日志的免費(fèi)程序。

　　另外還有一類產(chǎn)品，它們不分析直接日志，而是通過(guò)讓用戶在頁(yè)面中嵌入js代碼的方式來(lái)直接進(jìn)行數(shù)據(jù)統(tǒng)計(jì)，或者說(shuō)我們可以認(rèn)為它是直接讓日志輸出到了它們的服務(wù)器。典型的代表產(chǎn)品——大名鼎鼎的Google Analytics，另外還有國(guó)內(nèi)的cnzz、百度統(tǒng)計(jì)等。

　　很多人可能會(huì)說(shuō)，既然如此，我們?yōu)槭裁催€需要自己來(lái)分析日志，有必要嗎?當(dāng)然有。我們的用戶(產(chǎn)品分析人員)需求是無(wú)窮盡的，上面說(shuō)的這幾類工具雖然很好很強(qiáng)大，但顯然沒(méi)辦法滿足全部的需求。

　　無(wú)論是本地分析的工具，還是在線的分析服務(wù)，它們雖然提很豐富的的統(tǒng)計(jì)分析功能，可以做一定程度的配置，但是依然很有限的。要進(jìn)行稍復(fù)雜點(diǎn)的分析，或者要做基于日志的數(shù)據(jù)挖掘，依然需要自己來(lái)完成。

　　另外絕大多數(shù)日志分析工具都是只能用于單機(jī)的，數(shù)據(jù)量稍大就沒(méi)轍了。同時(shí)那些提供在線分析的服務(wù)對(duì)于單個(gè)站點(diǎn)通常也都有最大流量的限制——這是很容易理解的，他們也需要考慮服務(wù)器的負(fù)載。

　　所以，很多時(shí)候還是得靠自己。

　　怎么進(jìn)行日志分析

　　這并不是一個(gè)簡(jiǎn)單的問(wèn)題。即使我們把“日志”限定為Web日志，依然包含了成千上萬(wàn)種可能的格式和數(shù)據(jù)，而是“分析”更是難以定義，也許是簡(jiǎn)單的統(tǒng)計(jì)值的計(jì)算，也許是復(fù)雜的數(shù)據(jù)挖掘算法。

　　下面并不打算討論這些復(fù)雜的問(wèn)題，而只是籠統(tǒng)的討論如何構(gòu)建進(jìn)行日志分析工作的基礎(chǔ)。有了這些基礎(chǔ)會(huì)讓基于日志的簡(jiǎn)單統(tǒng)計(jì)分析變得很簡(jiǎn)單，并讓復(fù)雜的分析挖掘等變得可行。

　　少量數(shù)據(jù)的情況

　　先考慮最簡(jiǎn)單的情況，在數(shù)據(jù)規(guī)模比較小的時(shí)候，也許是幾十MB、幾百M(fèi)B或者幾十GB，總之就是在單機(jī)處理尚能忍受的時(shí)候。一切都很好辦，現(xiàn)成的各種Unix/Linux工具——awk、grep、sort、join等都是日志分析的利器，如果僅僅是想知道某個(gè)頁(yè)面的PV，一個(gè)wc+grep就能搞定。如果有稍復(fù)雜的邏輯，那就使用各種腳本語(yǔ)言，尤其是perl，配合偉大的正則表達(dá)式，基本就可以解決所有的問(wèn)題。

　　例如，我們想從上面提到的apache日志中得到訪問(wèn)量最高前100個(gè)IP，實(shí)現(xiàn)很簡(jiǎn)單：

　　cat logfile | awk ‘{a[$1]++} END {for(b in a) print b”\t”a[b]}’|sort -k2 -r|head -n 100

　　不過(guò)當(dāng)我們需要頻繁去分析日志的時(shí)候，上面的做法在一段時(shí)間之后可能就會(huì)讓我們頭疼如何進(jìn)行各種日志文件、用于分析的腳本文件、crontab文件等等的維護(hù)，并且可能會(huì)存在大量重復(fù)的代碼來(lái)做數(shù)據(jù)格式的解析和清洗，這個(gè)時(shí)候也許就需要更合適的東西，比如——數(shù)據(jù)庫(kù)。

　　當(dāng)然，要使用數(shù)據(jù)庫(kù)來(lái)進(jìn)行日志分析還是需要一些代價(jià)的，最主要的就是如何將各種異構(gòu)的日志文件導(dǎo)入的數(shù)據(jù)庫(kù)中——這個(gè)過(guò)程通常稱為ETL(Extraction-Transformation-Loading)。幸好依然有各種現(xiàn)成的開源、免費(fèi)的工具來(lái)幫助我們做這件事情，并且在日志種類不太多的時(shí)候，自己寫幾個(gè)簡(jiǎn)單的腳本來(lái)完成這項(xiàng)工作也并不困難。例如可以將上面的日志去掉不必要的字段，然后導(dǎo)入如下的數(shù)據(jù)庫(kù)中：

　　現(xiàn)在需要考慮一下用什么數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)這些數(shù)據(jù)。MySQL是一個(gè)很經(jīng)典的開源數(shù)據(jù)庫(kù)，它的傳統(tǒng)引擎(MyISAM或者InnoDB，行存儲(chǔ))也許并不非常的適合日志數(shù)據(jù)的存儲(chǔ)，但是在小數(shù)據(jù)量的時(shí)候還是很夠用的。而且，在這方面現(xiàn)在已經(jīng)有了更好的選擇，例如開源且免費(fèi)的Infobright、Infinidb，都是專門為數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用而進(jìn)行了優(yōu)化的數(shù)據(jù)引擎，采用列存儲(chǔ)，有良好的數(shù)據(jù)壓縮，處理幾百GB的數(shù)據(jù)基本上不是問(wèn)題。

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

　　同樣還是上面的那個(gè)例子，簡(jiǎn)單的一個(gè)SQL就可以搞定：

　　SELECT * FROM (SELECT ip, COUNT(*) AS ip_count FROM apache_log GROUP BY ip) a ORDER BY ip_count DESC LIMIT 100

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

　　更進(jìn)一步的，使用基于數(shù)據(jù)庫(kù)的存儲(chǔ)，可以很容易的進(jìn)行OLAP(聯(lián)機(jī)分析處理)應(yīng)用，從日志中挖掘價(jià)值會(huì)變的更加簡(jiǎn)單。

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

　　一個(gè)好的數(shù)據(jù)庫(kù)似乎會(huì)讓事情變的很簡(jiǎn)單，但是別忘了前面提到的都是單機(jī)數(shù)據(jù)庫(kù)。一臺(tái)單機(jī)在存儲(chǔ)容量、并發(fā)性上毫無(wú)疑問(wèn)都是有很大限制的。而日志數(shù)據(jù)的特點(diǎn)之一就是隨時(shí)間持續(xù)增長(zhǎng)，并且由于很多分析過(guò)程往往需要?dú)v史數(shù)據(jù)。短時(shí)間內(nèi)的增長(zhǎng)也許可以通過(guò)分庫(kù)、分表或者數(shù)據(jù)壓縮等來(lái)解決，不過(guò)很顯然并不是長(zhǎng)久之計(jì)。

　　想要徹底解決數(shù)據(jù)規(guī)模增長(zhǎng)帶來(lái)的問(wèn)題，很自然的會(huì)想到使用分布式技術(shù)，結(jié)合上面的結(jié)論，也許使用某個(gè)分布式數(shù)據(jù)庫(kù)是一個(gè)好選擇，那么對(duì)最終用戶就可以完全透明了。這個(gè)的確是很理想的情況，不過(guò)現(xiàn)實(shí)往往是殘酷的。

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

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

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

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

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

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

　　MapReduce是一種分布式編程模型，并不難學(xué)習(xí)，但是很顯然使用它來(lái)處理日志的代價(jià)依然遠(yuǎn)大于單機(jī)腳本或者SQL。一個(gè)簡(jiǎn)單的詞頻統(tǒng)計(jì)計(jì)算可能都需要上百代碼——SQL只需要一行，另外還有復(fù)雜的環(huán)境準(zhǔn)備和啟動(dòng)腳本。

　　例如同樣還是上面的例子，實(shí)現(xiàn)就要復(fù)雜的多，通常需要兩輪MapReduce來(lái)完成。首先要在第一輪的mapper中計(jì)算部分ip的訪問(wèn)次數(shù)之和，并以ip為key輸出：

　　//遍歷輸入，并聚合結(jié)果

　　foreach(record in input) {

　　ip = record.ip;

　　dict[ip]++;

　　}

　　//用emit輸出，第一個(gè)參數(shù)為key，用于reduce的分發(fā)

　　foreach( in dict) {

　　emit(ip, count);

　　}

　　然后在第一輪的reduce中就可以得到每個(gè)ip完整的計(jì)數(shù)，可以順便排個(gè)序，并且只保留前100個(gè)。

　　count = 0;

　　//對(duì)于每個(gè)key(ip),遍歷所有的values(count)，并累加

　　while(input.values.hasNext()) {

　　count += input.values.next();

　　}

　　//插入到大小為100的堆中

　　heap_insert(input.key, count);

　　在reduce結(jié)束的時(shí)候輸出：

　　//輸出當(dāng)前reduce中count最高的100個(gè)ip

　　foreach( in dict) {

　　emit(ip, count);

　　}

　　由于reduce一般會(huì)有很多個(gè)，所以最后還需要將所有reduce的輸出進(jìn)行合并、再排序，并得到最終的前100個(gè)IP以及對(duì)應(yīng)的訪問(wèn)量。

　　所以，使用Hadoop來(lái)做日志分析很顯然不是一件簡(jiǎn)單事情，它帶來(lái)了很多的額外的學(xué)習(xí)和運(yùn)維成本，但是至少，它讓超大規(guī)模的日志分析變成了可能。

　　怎樣變得更簡(jiǎn)單

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

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

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

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

　　另外，很顯然Hive也并不能覆蓋所有的需求，所以它依然保留插入原始MapReduce代碼的接口，以便擴(kuò)展。

　　更多的問(wèn)題

　　即使有了Hive這樣一個(gè)類似于數(shù)據(jù)庫(kù)的東西，我們依然還有很多事情需要做。例如時(shí)間久了，可能會(huì)有越來(lái)越多的需要例行執(zhí)行的SQL，而這些SQL中，也許有一些是做了重復(fù)的事情;也許有一些的執(zhí)行效率非常低下，一個(gè)復(fù)雜的SQL就占滿了所有的計(jì)算資源。這樣的系統(tǒng)會(huì)變得越來(lái)越難以維護(hù)的，直到有一天例行的SQL終于跑不完了。而最終用戶往往不會(huì)去關(guān)心這些事情，他們只關(guān)心自己提交的查詢是不是能即時(shí)得到響應(yīng)，怎么樣才能盡快的拿到結(jié)果。舉個(gè)簡(jiǎn)單的例子，如果發(fā)現(xiàn)在使用apache_log的所有查詢中，幾乎沒(méi)有人用其中的user_agent字段，那么我們完全可以把這個(gè)字段去除掉，或者拆分成兩張表，以減少多數(shù)查詢的IO時(shí)間，提高執(zhí)行的效率。

　　為了系統(tǒng)化的解決這些問(wèn)題，我們可能需要引入例行任務(wù)的調(diào)度機(jī)制，可能需要去分析所有的SQL來(lái)發(fā)現(xiàn)哪些是可以合并的、哪些的性能需要優(yōu)化，使用的數(shù)據(jù)表是不是需要做水平或者垂直分表等等。根據(jù)實(shí)際情況的不同，這時(shí)事情可能是人工來(lái)完成，也可能是寫程序來(lái)自動(dòng)分析并調(diào)整。

　　再者隨著日志類型、分析需求的不斷增長(zhǎng)。用戶會(huì)越來(lái)越多的抱怨很難找到想要的數(shù)據(jù)在哪份日志里，或者跑的好好的查詢因?yàn)槿罩靖袷降淖兓蝗徊荒苡昧恕Ａ硗馍厦嫣岬降腅TL過(guò)程也會(huì)變得復(fù)雜，簡(jiǎn)單的轉(zhuǎn)換導(dǎo)入腳本很可能已經(jīng)解決不了問(wèn)題。這時(shí)候可能需要構(gòu)建一個(gè)數(shù)據(jù)管理系統(tǒng)，或者干脆考慮建立一個(gè)所謂的數(shù)據(jù)倉(cāng)庫(kù)。