「网站数据分析篇」“web网站日志分析方法论”
13
07-2019
专注于互联网领域的文艺青年江大白的知识日记分享
可能日志分析对一些做seo的朋友来说又熟悉及陌生,一直在听人行内朋友说,又不知道如何做分析,今天分享的主题就是”web日志分析方法论”。在web日志中,每条日志通常代表着用户的一次访问行为。
【 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)”】
这是一条典型的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日志中得到访问量最高前100个IP,实现很简单:
cat logfile | awk ‘{a[$1]++} END{for(b in a) print b”t”a[b]}’|sort -k2 -r|head -n 100
不过当我们需要频繁去分析日志的时候,上面的做法在一段时间之后可能就会让我们头疼如何进行各种日志文件、用于分析的脚本文件、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 GROUP BY ip) a ORDER BYip_count DESC LIMIT 100
至于性能问题,数据库的索引和各种优化机制通常会让我们的统计分析工作变得更快,并且上面提到的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中,然后再使用它提供的MapReduce API编写日志分析程序。
MapReduce是一种分布式编程模型,并不难学习,但是很显然使用它来处理日志的代价依然远大于单机脚本或者SQL。一个简单的词频统计计算可能都需要上百代码——SQL只需要一行,另外还有复杂的环境准备和启动脚本。
例如同样还是上面的例子,实现就要复杂的多,通常需要两轮MapReduce来完成。首先要在第一轮的mapper中计算部分ip的访问次数之和,并以ip为key输出:
//遍历输入,并聚合结果
foreach(recordin input) {
ip = record.ip;
dict[ip]++;
}
//用emit输出,第一个参数为key,用于reduce的分发
foreach(
emit(ip, count);
}
然后在第一轮的reduce中就可以得到每个ip完整的计数,可以顺便排个序,并且只保留前100个。
count = 0;
//对于每个key(ip),遍历所有的values(count),并累加
while(input.values.hasNext()){
count +=input.values.next();
}
//插入到大小为100的堆中
heap_insert(input.key,count);
在reduce结束的时候输出:
//输出当前reduce中count最高的100个ip
foreach(
emit(ip, count);
}
由于reduce一般会有很多个,所以最后还需要将所有reduce的输出进行合并、再排序,并得到最终的前100个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日志挖掘分析的方法
日志文件的格式及其包含的信息
①2006-10-17 00:00:00②202.200.44.43③218.77.130.24 80 ④GET ⑤/favicon.ico ⑥Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+zh-CN;+rv:1.8.0.3)+Gecko/20060426+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的统计,可以得到网站页面关注情况。4.对错误请求的统计,可以更正有问题的页面。
二、Web挖掘
根据所挖掘的Web 数据的类型,可以将Web 数据挖掘分为以下三类:Web 内容挖掘(Web Content Mining)、Web 结构挖掘(Web Structure Mining)、Web 使用挖掘(Web Usage Mining)(也称为Web日志挖掘)。
①Web内容挖掘。Web内容挖掘是指从文档的内容中提取知识。Web内容挖掘又分为文本挖掘和多媒体挖掘。目前多媒体数据的挖掘研究还处于探索阶段,Web文本挖掘已经有了比较实用的功能。Web文本挖掘可以对Web上大量文档集合的内容进行总结、分类、聚类、关联分析,以及利用Web文档进行趋势预测等。Web文档中的标记,例如
②Web结构挖掘。Web结构挖掘是从Web的组织结构和链接关系中推导知识。它不仅仅局限于文档之间的超链接结构,还包括文档内部的结构。文档中的URL目录路径的结构等。Web结构挖掘能够利用网页间的超链接信息对搜索引擎的检索结果进行相关度排序,寻找个人主页和相似网页,提高Web搜索蜘蛛在网上的爬行效率,沿着超链接优先爬行。Web结构挖掘还可以用于对Web页进行分类、预测用户的Web链接使用及Web链接属性的可视化。对各个商业搜索引擎索引用的页数量进行统计分析等。
③Web使用记录挖掘。Web使用记录挖掘是指从Web的使用记录中提取感兴趣的模式,目前Web使用记录挖掘方面的研究较多,WWW中的每个服务器都保留了访问日志,记录了关于用户访问和交互的信息,可以通过分析和研究Web日志记录中的规律,来识别网站的潜在用户;可以用基于扩展有向树模型来识别用户浏览序列模式,从而进行Web日志挖掘;可以根据用户访问的Web记录挖掘用户的兴趣关联规则,存放在兴趣关联知识库中,作为对用户行为进行预测的依据,从而为用户预取一些Web页面,加快用户获取页面的速度,分析这些数据还可以帮助理解用户的行为,从而改进站点的结构,或为用户提供个性化的服务。
通过对Web服务器日志中大量的用户访问记录深入分析,发现用户的访问模式和兴趣爱好等有趣、新颖、潜在有用的以及可理解的未知信息和知识,用于分析站点的使用情况,从而辅助管理和支持决策。当前,web日志挖掘主要被用于个性化服务与定制、改进系统性能和结构、站点修改、商业智能以及web特征描述等诸多领域。
三、Web日志挖掘的方法
(一)首先,进行数据的预处理。
从学习者的访问日志中得到的原始日志记录并不适于挖掘,必须进行适当的处理才能进行挖掘。因此,需要通过日志清理,去除无用的记录;对于某些记录,我们还需要通过站点结构信息,把URL路径补充成完整的访问序列;然后划分学习者,并把学习者的会话划分成多个事务。
(二)其次,进行模式发现
一旦学习者会话和事务识别完成,就可以采用下面的技术进行模式发现。模式发现, 是对预处理后的数据用数据挖掘算法来分析数据。分有统计、分类、聚类、关等多种方法。
① 路径分析。它可以被用于判定在一个站点中最频繁访问的路径,还有一些其它的有关路径的信息通过路径分析可以得出。路径分析可以用来确定网站上的频繁访问路径, 从而调整和优化网站结构, 使得用户访问所需网页更加简单快捷, 还可以根据用户典型的浏览模式用于智能推荐和有针对性的电子商务活动。例如:70% 的学习者在访问/ E-Business /M2时,是从/EB开始,经过/ E-Business /SimpleDescription,/ E-Business/M1;65%的学习者在浏览4个或更少的页面内容后就离开了。利用这些信息就可以改进站点的设计结构。
② 关联规则。使用关联规则发现方法,可以从Web的访问事务中找到的相关性。关联规则是寻找在同一个事件中出现的不同项的相关性,用数学模型来描述关联规则发现的问题:x=>y的蕴含式,其中x,y为属性——值对集(或称为项目集),且X∩Y空集。在数据库中若S%的包含属性——值对集X的事务也包含属性——值集Y,则关联规则X=>Y的置信度为C%。
③ 序列模式。在时间戳有序的事务集中,序列模式的发现就是指那些如“一些项跟随另一个项”这样的内部事务模式。它能发现数据库中如“在某一段时间内,客户购买商品A,接着会购买商品B,尔后又购买商品C,即序列A→B→C出现的频率高”之类的信息。序列模式描述的问题是:在给定的交易序列数据库中,每个序列按照交易的时间排列的一组交易集,挖掘序列函数作用是返回该数据库中高频率出现有序列。
④ 分类分析。发现分类规则可以给出识别一个特殊群体的公共属性的描述,这种描述可以用于分类学习者。分类包括的挖掘技术将找出定义了一个项或事件是否属于数据中某特定子集或类的规则。该类技术是最广泛应用于各类业务问题的一类挖掘技术。分类算法最知名的是决策树方法,此外还有神经元网络、Bayesian分类等。例如:在/ E-Business /M4学习过的学习者中有40%是20左右的女大学生。
⑤聚类分析。可以从Web访问信息数据中聚类出具有相似特性的学习者。在Web事务日志中,聚类学习者信息或数据项能够便于开发和设计未来的教学模式和学习群体。聚类是将数据集划分为多个类,使得在同一类中的数据之间有较高的相似度,而在不同类中的数据差别尽可能大。在聚类技术中,没有预先定义好的类别和训练样本存在,所有记录都根据彼此相似程度来加以归类。主要算法有k—means、DBSCAN等。聚类分析是把具有相似特征的用户或数据项归类,在网站管理中通过聚类具有相似浏览行为的用户。基于模糊理论的Web页面聚类算法与客户群体聚类算法的模糊聚类定义相同,客户访问情况可用URL(Uj)表示。有Suj={(Ci,fSuj(Ci))|Ci∈C},其中fSuj(Ci)→[0,1]是客户Ci和URL(Uj)间的关联度:式中m为客户的数量,hits(Ci)表示客户Ci访问URL(Uj)的次数。利用Suj和模糊理论中的相似度度量Sfij定义建立模糊相似矩阵,再根据相似类[Xi]R的定义构造相似类,合并相似类中的公共元素得到的等价类即为相关Web页面。
⑥统计。统计方法是从Web 站点中抽取知识的最常用方法, 它通过分析会话文件, 对浏览时间、浏览路径等进行频度、平均值等统计分析。虽然缺乏深度, 但仍可用于改进网站结构, 增强系统安全性, 提高网站访问的效率等。
⑦协同过滤。协同过滤技术采用最近邻技术,利用客户的历史、喜好信息计算用户之间的距离,目标客户对特点商品的喜好程度由最近邻居对商品的评价的加权平均值来计算。
(三)最后,进行模式分析。
模式分析。基于以上的所有过程,对原始数据进行进一步分析,找出用户的浏览模式规律,即用户的兴趣爱好及习惯,并使其可视化,为网页的规划及网站建设的决策提供具体理论依据。其主要方法有:采用SQL查询语句进行分析;将数据导入多维数据立方体中,用OLAP工具进行分析并给出可视化的结果输出。(分类模式挖掘、聚类模式挖掘、时间序列模式挖掘、序列模式挖掘、关联规则等)
四、关联规则
(一)关联规则
顾名思义,关联规则(association rule)挖掘技术用于于发现数据库中属性之间的有趣联系。一般使用支持度(support)和置信度(confidence)两个参数来描述关联规则的属性。
(二)Apriori方法简介
Apriori算法最先是由Agrawal等人于1993年提出的,它的基本思想是:首先找出所有具有超出最小支持度的支持度项集,用频繁的(k—1)-项集生成候选的频繁k-项集;其次利用大项集产生所需的规则;任何频繁项集的所有子集一定是频繁项集是其核心。Apriori算法需要两个步骤:第一个是生成条目集;第二个是使用生成的条目集创建一组关联规则。当我们把最小置信度设为85%,通过关联规则的形成以及对应置信度的计算,我们可以从中得到以下有用的信息:1.置信度大于最小置信度时:我们可以这样认为,用户群体在浏览相关网页时,所呈列的链接之间是有很大关联的,他们是用户群的共同爱好,通过网页布局的调整,从某种意义上,可以带来更高的点击率及潜在客户;2.置信度小于最小置信度时:我们可以这样认为,用户群体对所呈列链接之间没太多的关联,亦或关联规则中的链接在争夺用户。