13
07-
专注于互联网领域的文艺青年江大白的知识日记分享
可能日志分析对一些做seo的朋友来说又熟悉及陌生，一直在听人行内朋友说，又不知道如何做分析，今天分享的主题就是”web日志分析方法论”。在web日志中，每条日志通常代表着用户的一次访问行为。
这是一条典型的apache日志，从日志中，我们可以得到很多有用的信息，列如：访问者的ip，访问的时间，访问的目标网页，来源的地址以及访问者所使用的客户端的userAgent信息等。如果想获取更多的信息，则需要其他的手段去获取，例如：想得到用户屏幕的分辨率，一般都是需要js代码单独发送请求；如果想获取用户访问的具体新闻标题等信息，则需要web应用程序在自己的代码中输出。
1，那为什么需要做分析日志，分析那些维度？
在web日志中包括了大量需要数据维度，通过这些数据维度更好的调整网站的运营思路，那到底有那些数据维度？主要有：每类页的PV值(PageView，页面访问量)，独立IP数(即去重之后的IP数量)等；稍微复杂一些可以计算得出用户所检索的关键词排行榜，用户停留时间最高的页面等。复杂一些就是分析构建广告点击模型，分析用户行为特征等等
2，网站日志数据分析日志工具（专门用于统计分析web服务器日志的免费程序）
（1）awstats，（2），webalizer,
3，怎么进行日志分析
一把web日志分析，包含了成千上万中可能的格式和数据，”分析”更是难以定义，也许是简单的统计值的计算，也许是复杂的数据挖掘算法。
（1）少量数据的情况
先考虑最简单的情况，在数据规模比较小的时候，也许是几十MB，几百MB或者几十GB，总之就是在单机处理尚能承受的时候，一切都好办。现成的各种Unix/linux工具——awk，grep，sort，join等都是日志分析的利器，如果想知道某个页面的PV，一个wc+grep就能搞定。如果有稍复杂的逻辑，那就使用各种脚本语言，尤其是perl，配合伟大的正则表达式，基本就可以解决所有的问题，
例如，我们想从上面提到的apache日志中得到访问量最高前个IP，实现很简单：
catlogfile
awk‘{a[$1]++}END{for(bina)printb”\t”a}’
sort-k2-r
head-n
不过当我们需要频繁去分析日志的时候，上面的做法在一段时间之后可能就会让我们头疼如何进行各种日志文件、用于分析的脚本文件、crontab文件等等的维护，并且可能会存在大量重复的代码来做数据格式的解析和清洗，这个时候也许就需要更合适的东西，比如——数据库。
当然，要使用数据库来进行日志分析还是需要一些代价的，最主要的就是如何将各种异构的日志文件导入的数据库中——这个过程通常称为ETL（Extraction-Transformation-Loading）。幸好依然有各种现成的开源、免费的工具来帮助我们做这件事情，并且在日志种类不太多的时候，自己写几个简单的脚本来完成这项工作也并不困难。例如可以将上面的日志去掉不必要的字段，然后导入如下的数据库中：
现在需要考虑一下用什么数据库来存储这些数据。MySQL是一个很经典的开源数据库，它的传统引擎（MyISAM或者InnoDB，行存储）也许并不非常的适合日志数据的存储，但是在小数据量的时候还是很够用的。而且，在这方面现在已经有了更好的选择，例如开源且免费的Infobright、Infinidb，都是专门为数据仓库应用而进行了优化的数据引擎，采用列存储，有良好的数据压缩，处理几百GB的数据基本上不是问题。
使用数据库的好处之一就是，伟大的SQL可以帮我们很简单的完成绝大部分的统计分析工作——PV只需要SELECT+COUNT，计算搜索词排行只需要SELECT+COUNT+GROUP+ORDER+LIMIT。此外，数据库本身的结构化存储模式也让日志数据的管理变的更简单，减少运维代价。
同样还是上面的那个例子，简单的一个SQL就可以搞定：
SELECT*FROM(SELECTip,COUNT(*)ASip_countFROMapache_logGROUPBYip)aORDERBYip_countDESCLIMIT
至于性能问题，数据库的索引和各种优化机制通常会让我们的统计分析工作变得更快，并且上面提到的Infobright和Infinidb都专门为类似SUM、COUNt之类的聚集应用做了优化。当然也不是绝对的会快，例如在数据库中进行LIKE操作，通常会比grep一个文件还要慢很多。
更进一步的，使用基于数据库的存储，可以很容易的进行OLAP（联机分析处理）应用，从日志中挖掘价值会变的更加简单。
更多的数据怎么办
一个好的数据库似乎会让事情变的很简单，但是别忘了前面提到的都是单机数据库。一台单机在存储容量、并发性上毫无疑问都是有很大限制的。而日志数据的特点之一就是随时间持续增长，并且由于很多分析过程往往需要历史数据。短时间内的增长也许可以通过分库、分表或者数据压缩等来解决，不过很显然并不是长久之计。
想要彻底解决数据规模增长带来的问题，很自然的会想到使用分布式技术，结合上面的结论，也许使用某个分布式数据库是一个好选择，那么对最终用户就可以完全透明了。这个的确是很理想的情况，不过现实往往是残酷的。
首先，实现比较完美的分布式数据库（受限于CAP原则）是一个非常复杂的问题，因此在这里并不像单机数据库那样，有那么多开源的好东西可以用，甚至于商用的也并不是太多。当然，也并非绝对，如果有钱，还是可以考虑一下OracleRAC、Greenplum之类东西。
其次，绝大多数分布式数据库都是NoSQL的，所以想继续用上SQL的那些优点基本上是没指望，取而代之的都是一些简单、难以使用的接口。单从这点看来，使用这些数据库的价值已经降低很多了。
所以，还是先现实一点，先退一步考虑如何解决的超大规模的日志的分析问题，而不是想如何让它变的像在小数据规模时那样简单。单单想做到这点，目前看来并不是太难，并且依然有免费的午餐可以吃。
Hadoop是伟大的Apache基金会下面的一套分布式系统，包括分布式文件系统（HDFS）、MapReduce计算框架、Hbase等很多组件——这些基本都是Google的GFS/MapReduce/BigTable的克隆产品。
Hadoop经过数年的发展，目前已经很成熟了，尤其是其中的HDFS和MapReduce计算框架组件。数百台机器的集群已经被证明可以使用，可以承担PB级别的数据。
Hadoop项目中的HBase是一个按列存储的NoSQL分布式数据库，它提供的功能和接口都非常简单，只能进行简单的K-V查询，因此并不直接适用于大多数日志分析应用。所以一般使用Hadoop来做日志分析，首先还是需要将日志存储在HDFS中，然后再使用它提供的MapReduceAPI编写日志分析程序。
MapReduce是一种分布式编程模型，并不难学习，但是很显然使用它来处理日志的代价依然远大于单机脚本或者SQL。一个简单的词频统计计算可能都需要上百代码——SQL只需要一行，另外还有复杂的环境准备和启动脚本。
例如同样还是上面的例子，实现就要复杂的多，通常需要两轮MapReduce来完成。首先要在第一轮的mapper中计算部分ip的访问次数之和，并以ip为key输出：
//遍历输入，并聚合结果
foreach(recordininput){
ip=record.ip;
dict[ip]++;
}
//用emit输出，第一个参数为key，用于reduce的分发
foreach(ip,countindict){
emit(ip,count);
}
然后在第一轮的reduce中就可以得到每个ip完整的计数，可以顺便排个序，并且只保留前个。
count=0;
//对于每个key（ip）,遍历所有的values（count），并累加
while(input.values.hasNext()){
count+=input.values.next();
}
//插入到大小为的堆中
heap_insert(input.key,count);
在reduce结束的时候输出：
//输出当前reduce中count最高的个ip
foreach(ip,countindict){
emit(ip,count);
}
由于reduce一般会有很多个，所以最后还需要将所有reduce的输出进行合并、再排序，并得到最终的前个IP以及对应的访问量。
所以，使用Hadoop来做日志分析很显然不是一件简单事情，它带来了很多的额外的学习和运维成本，但是至少，它让超大规模的日志分析变成了可能。
怎样变得更简单
在超大规模的数据上做任何事情都不是一件容易的事情，包括日志分析，但也并不是说分布式的日志分析就一定要去写MapReduce代码，总是可以去做进一步的抽象，在特定的应用下让事情变得更简单。
也许有人会很自然的想到如果能用SQL来操作Hadoop上的数据该有多好。事实上，不仅仅只有你一个人会这么想，很多人都这么想，并且他们实现了这个想法，于是就有了Hive。
Hive现在也是Hadoop项目下面的一个子项目，它可以让我们用SQL的接口来执行MapReduce，甚至提供了JDBC和ODBC的接口。有了这个之后，Hadoop基本上被包装成一个数据库。当然实际上Hive的SQL最终还是被翻译成了MapReduce代码来执行，因此即使最简单的SQL可能也要执行好几十秒。幸好在通常的离线日志分析中，这个时间还是可以接受的。更重要的是，对于上面提到的例子，我们又可以用一样的SQL来完成分析任务了。
当然Hive并不是完全的兼容SQL语法，而且也不能做到完全的对用户屏蔽细节。很多时候为了执行性能的优化，依然需要用户去了解一些MapReduce的基本知识，根据自己的应用模式来设置一些参数，否则我们可能会发现一个查询执行很慢，或者压根执行不出来。
另外，很显然Hive也并不能覆盖所有的需求，所以它依然保留插入原始MapReduce代码的接口，以便扩展。
即使有了Hive这样一个类似于数据库的东西，我们依然还有很多事情需要做。例如时间久了，可能会有越来越多的需要例行执行的SQL，而这些SQL中，也许有一些是做了重复的事情；也许有一些的执行效率非常低下，一个复杂的SQL就占满了所有的计算资源。这样的系统会变得越来越难以维护的，直到有一天例行的SQL终于跑不完了。而最终用户往往不会去关心这些事情，他们只关心自己提交的查询是不是能即时得到响应，怎么样才能尽快的拿到结果。
举个简单的例子，如果发现在使用apache_log的所有查询中，几乎没有人用其中的user_agent字段，那么我们完全可以把这个字段去除掉，或者拆分成两张表，以减少多数查询的IO时间，提高执行的效率。
为了系统化的解决这些问题，我们可能需要引入例行任务的调度机制，可能需要去分析所有的SQL来发现哪些是可以合并的、哪些的性能需要优化，使用的数据表是不是需要做水平或者垂直分表等等。根据实际情况的不同，这时事情可能是人工来完成，也可能是写程序来自动分析并调整。
再者随着日志类型、分析需求的不断增长。用户会越来越多的抱怨很难找到想要的数据在哪份日志里，或者跑的好好的查询因为日志格式的变化而突然不能用了。另外上面提到的ETL过程也会变得复杂，简单的转换导入脚本很可能已经解决不了问题。这时候可能需要构建一个数据管理系统，或者干脆考虑建立一个所谓的数据仓库。
总之，随着日志数据量、日志类型、用户数量、分析需求等等的不断增长，越来越多的问题会逐渐浮现出来，日志分析这件事情可能就不再像我们最初想的那么简单，会变得越来越有价值，也越来越有挑战。
4，Web日志挖掘分析的方法
日志文件的格式及其包含的信息
①-10-:00:00②..44.43③.77..④GET⑤/favicon.ico⑥Mozilla/5.0+(Windows；+U；+Windows+NT+5.1；+zh-CN；+rv：1.8.0.3)+Gecko/0426+Firefox/1.5.0.3。①访问时间；②用户IP地址；③访问的URL，端口；④请求方法(“GET”、“POST”等)；⑤访问模式；⑥agent，即用户使用的操作系统类型和浏览器软件。
一、日志的简单分析
1、注意那些被频繁访问的资源2、注意那些你网站上不存在资源的请求。常见的扫描式攻击还包括传递恶意参数等：3、观察搜索引擎蜘蛛的来访情况4、观察访客行为
应敌之策：
1、封杀某个IP2、封杀某个浏览器类型（Agent）3、封杀某个来源（Referer）4、防盗链5、文件重命名
作用：
1.对访问时间进行统计，可以得到服务器在某些时间段的访问情况。2.对IP进行统计，可以得到用户的分布情况。3.对请求URL的统计，可以得到网站页面