十载风雨路 · 匠心铸精品

量身定制 追求完美

教你如何分析网站日志

 发布日期:2011-05-26 12:00:00 浏览:4530次

      教你如何分析网站日志
      日志在计算机中的概念非常广泛,日志内容、规模和用途也各不相同,佳速网络在此讨论的日志仅指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数(即去重之后的IP数量);检索的关键词排行榜、用户停留时间最高的页面;构建广告点击模型、用户行为特征等等。

    现在已经有无数的工具可以分析Web日志,例如awstats、Webalizer,都是专门用于统计分析Web服务器日志的免费程序。

      还有一类产品不分析直接日志,而是通过让用户在页面中嵌入js代码的方式来直接进行数据统计,或者说我们可以认为它是直接让日志输出到了它们的服务器。代表产品:Google Analytics,cnzz、百度统计等。

      既然如此,我们为什么还需要自己来分析日志?我们的用户(产品分析人员)需求是无穷尽的,上面的工具虽然很强大,但没办法满足全部的需求。

   它们虽然提很丰富的的统计分析功能,可以做一定程度的配置,但是依然很有限的。绝大多数日志分析工具都是只能用于单机,也都有最大流量的限制。

   怎么分析日志

  对于少量数据

   现成的各种Unix/Linux工具——awk、grep、sort、join等都是日志分析的利器;如果有稍复杂的逻辑,那就使用各种脚本语言,尤其是perl,配合伟大的正则表达式,基本就可以解决所有的问题。

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

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


   至于性能问题,数据库的索引和各种优化机制通常会让我们的统计分析工作变得更快,并且上面提到的Infobright和Infinidb都专门为类似SUM、COUNt之类的聚集应用做了优化。当然也不是绝对的会快,例如在数据库中进行LIKE操作,通常会比grep一个文件还要慢很多。

    更进一步的,使用基于数据库的存储,可以很容易的进行OLAP(联机分析处理)应用,从日志中挖掘价值会变的更加简单。

更多的数据怎么办

   一个好的数据库似乎会让事情变的很简单,但是别忘了前面提到的都是单机数据库。

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

   首先,实现比较完美的分布式数据库(受限于CAP原则)是一个非常复杂的问题,因此在这里并不像单机数据库那样,有那么多开源的好东西可以用,甚至于商用的也并不是太多。当然,也并非绝对,如果有钱,还是可以考虑一下Oracle RAC、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代码,总是可以去做进一步的抽象,在特定的应用下让事情变得更简单。

   也许有人会很自然的想到如果能用SQL来操作Hadoop上的数据该有多好。事实上,不仅仅只有你一个人会这么想,很多人都这么想,并且他们实现了这个想法,于是就有了Hive。

     Hive现在也是Hadoop项目下面的一个子项目,它可以让我们用SQL的接口来执行MapReduce,甚至提供了JDBC和ODBC的接口。有了这个之后,Hadoop基本上被包装成一个数据库。当然实际上Hive的SQL最终还是被翻译成了MapReduce代码来执行,因此即使最简单的SQL可能也要执行好几十秒。幸好在通常的离线日志分析中,这个时间还是可以接受的。更重要的是,对于上面提到的例子,我们又可以用一样的SQL来完成分析任务了。

    当然Hive并不是完全的兼容SQL语法,而且也不能做到完全的对用户屏蔽细节。很多时候为了执行性能的优化,依然需要用户去了解一些MapReduce的基本知识,根据自己的应用模式来设置一些参数,否则我们可能会发现一个查询执行很慢,或者压根执行不出来。

    随着日志数据量、日志类型、用户数量、分析需求等等的不断增长,越来越多的问题会逐渐浮现出来,日志分析这件事情可能就不再像我们最初想的那么简单,会变得越来越有价值,也越来越有挑战。
   佳速网络 ) 服务全国 !   上海网站建设  首选品牌!转载请注明来路。

相关新闻

CopyRight 2004-2018 JSOON NETWORK , Inc. All Rights Reserved 专业互联网开发服务提供商-佳速网络   服务热线:021-58361813   沪ICP备09051443号-4   网站地图
上海佳速公司提供上海网站建设制作、app开发、微信小程序开发服务

021-58361813