百度搜索研发部：日志分析方法概述【转载】

日志在计算机系统中是一个非常广泛的概念，任何程序都有可能输出日志：操作系统内核、各种应用服务器等等。日志的内容、规模和用途也各不相同，很难一概而论。本文讨论的日志处理方法中的日志，仅指Web日志。其实并没有精确的定义，可能包括但不限于各种前端Web服务器——apache、lighttpd、tomcat等产生的用户访问日志，以及各种Web应用程序自己输出的日志。

在Web日志中，每条日志通常代表着用户的一次访问行为，例如下面就是一条典型的apache 日志：

211.87.152.44 –-[18/Mar/2005:12:21:42+0800“GET /HTTP/1.1″200899“/” “Mozilla/4.0(compatible; MSIE 6.0; Windows NT 5.1; Maxthon)”

从上面这条日志中，我们可以得到很多有用的信息，例如访问者的IP、访问的时间、访问的目标网页、来源的地址以及访问者所使用的客户端的UserAgent信息等。如果需要更多的信息，则要用其它手段去获取：例如想得到用户屏幕的分辨率，一般需要使用js代码单独发送请求；而如果想得到诸如用户访问的具体新闻标题等信息，则可能需要Web应用程序在自己的代码里输出。

为什么要分析日志

毫无疑问，Web日志中包含了大量人们——主要是产品分析人员会感兴趣的信息，最简单的，我们可以从中获取网站每类页面的PV值（PageView，页面访问量）、独立IP数（即去重之后的IP数量）等；稍微复杂一些的，可以计算得出用户所检索的关键词排行榜、用户停留时间最高的页面等；更复杂的，构建广告点击模型、分析用户行为特征等等。

既然这些数据是如此的有用，那么当然已经有无数现成的工具可以帮助我们来分析它们，例如awstats、Webalizer，都是专门用于统计分析Web 服务器日志的免费程序。另外还有一类产品，它们不分析直接日志，而是通过让用户在页面中嵌入js代码的方式来直接进行数据统计，或者说我们可以认为它是直接让日志输出到了它们的服务器。典型的代表产品——大名鼎鼎的Google Analytics。

很多人可能会说，既然如此，我们为什么还需要自己来分析日志，有必要吗？当然有。我们的用户（产品分析人员）需求是无穷尽的，上面说的这几类工具虽然很好很强大，但显然没办法满足全部的需求。无论是本地分析的工具，还是在线的分析服务，它们虽然提很丰富的的统计分析功能，可以做一定程度的配置，但是依然很有限的。要进行稍复杂点的分析，或者要做基于日志的数据挖掘，依然需要自己来完成。

另外绝大多数日志分析工具都是只能用于单机的，数据量稍大就没辙了。同时那些提供在线分析的服务对于单个站点通常也都有最大流量的限制——这是很容易理解的，他们也需要考虑服务器的负载。所以，很多时候还是得靠自己。

怎么进行日志分析

这并不是一个简单的问题。即使我们把“日志”限定为Web日志，依然包含了成千上万种可能的格式和数据，而是“分析”更是难以定义，也许是简单的统计值的计算，也许是复杂的数据挖掘算法。下面并不打算讨论这些复杂的问题，而只是笼统的讨论如何构建进行日志分析工作的基础。有了这些基础会让基于日志的简单统计分析变得很简单，并让复杂的分析挖掘等变得可行。

少量数据的情况

先考虑最简单的情况，在数据规模比较小的时候，也许是几十MB、几百MB或者几十GB，总之就是在单机处理尚能忍受的时候。一切都很好办，现成的各种Unix/Linux工具——awk、grep、sort、join等都是日志分析的利器，如果仅仅是想知道某个页面的PV，一个wc+grep

就能搞定。如果有稍复杂的逻辑，那就使用各种脚本语言，尤其是perl，配合伟大的正则表达式，基本就可以解决所有的问题。

例如，我们想从上面提到的apache日志中得到访问量最高前100个IP，实现很简单：

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

不过当我们需要频繁去分析日志的时候，上面的做法在一段时间之后可能就会让我们头疼如何进行各种日志文件、用于分析的脚本文件、crontab文件等等的维护，并且可能会存在大量重复的代码来做数据格式的解析和清洗，这个时候也许就需要更合适的东西，比如——数据库。

当然，要使用数据库来进行日志分析还是需要一些代价的，最主要的就是如何将各种异构的日志文件导入的数据库中——这个过程通常称为ETL（Extraction-Transformation- Loading）。幸好依然有各种现成的开源、免费的工具来帮助我们做这件事情，并且在日志种类不太多的时候，自己写几个简单的脚本来完成这项工作也并不困难。例如可以将上面的日志去掉不必要的字段，然后导入如下的数据库中。

现在需要考虑一下用什么数据库来存储这些数据。MySQL是一个很经典的开源数据库，它的传统引擎（MyISAM或者InnoDB，行存储）也许并不非常的适合日志数据的存储，但是在小数据量的时候还是很够用的。而且，在这方面现在已经有了更好的选择，例如开源且免费的Infobright、Infinidb，都是专门为数据仓库应用而进行了优化的数据引擎，采用列存储，有良好的数据压缩，处理几百GB的数据基本上不是问题。

使用数据库的好处之一就是，伟大的SQL可以帮我们很简单的完成绝大部分的统计分析工作——PV只需要SELECT+COUNT，计算搜索词排行只需要SELECT+COUNT+GROUP+ORDER+LIMIT。此外，数据库本身的结构化存储模式也让日志数据的管理变的更简单，减少运维代价。

同样还是上面的那个例子，简单的一个SQL就可以搞定：

SELECT*FROM(SELECT ip,COUNT(*)AS ip_count FROM apache_log GROUPBY ip)a ORDERBY ip_count DESCLIMIT100

至于性能问题，数据库的索引和各种优化机制通常会让我们的统计分析工作变得更快，并且上面提到的Infobright和Infinidb都专门为类似SUM、COUNt之类的聚集应用做了优化。当然也不是绝对的会快，例如在数据库中进行LIKE操作，通常会比grep一个文件还要慢很多。更进一步的，使用基于数据库的存储，可以很容易的进行OLAP（联机分析处理）应用，从日志中挖掘价值会变的更加简单。

更多的数据怎么办

一个好的数据库似乎会让事情变的很简单，但是别忘了前面提到的都是单机数据库。一台单机在存储容量、并发性上毫无疑问都是有很大限制的。而日志数据的特点之一就是随时间持续增长，并且由于很多分析过程往往需要历史数据。短时间内的增长也许可以通过分库、分表或者数据压缩等来解决，不过很显然并不是长久之计。

想要彻底解决数据规模增长带来的问题，很自然的会想到使用分布式技术，结合上面的结论，也许使用某个分布式数据库是一个好选择，那么对最终用户就可以完全透明了。这个的确是很理想的情况，不过现实往往是残酷的。

首先，实现比较完美的分布式数据库（受限于CAP原则）是一个非常复杂的问题，因此在这里并不像单机数据库那样，有那么多开源的好东西可以用，甚至于商用的也并不是太多。当然，也并非绝对，如果有钱，还是可以考虑一下Oracle RAC、Greenplum之类东西。