- 浏览: 155027 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (113)
- Java工具类 (3)
- Hibernate (1)
- Struts>1&2 (0)
- Spring (0)
- Web前端 (1)
- 数据库 (2)
- 中间件 (3)
- 搜索引擎 (11)
- EJB (1)
- Log日志 (1)
- OS操作系统 (7)
- Java文档 (4)
- Security (1)
- Exception&Error (7)
- 日志&心情 (7)
- 开心一下 (3)
- 云计算 (41)
- Cache缓存 (4)
- MongoDB (1)
- OS操作系统 Linux (7)
- jquery (1)
- 机器学习 (2)
- Plugins (2)
- AJAX (1)
- Java工具 (1)
- WebService (1)
最新评论
-
a420144030:
你好,我想计算n篇文章的相似度,用mahout能处理吗,如何做 ...
mahout使用 -
di1984HIT:
OK,真的很牛啊
hadoop常见错误 -
xwl1991:
还真是这个问题 !
quartz报错java.lang.NoSuchMethodError: org.apache.commons.collections.SetUtils.ord
志在计算机系统中是一个非常广泛的概念,任何程序都有可能输出日志:操作系统内核、各种应用服务器等等。日志的内容、规模和用途也各不相同,很难一概而论。
本文讨论的日志处理方法中的日志,仅指Web日志。其实并没有精确的定义,可能包括但不限于各种前端Web服务器——apache、lighttpd、tomcat等产生的用户访问日志,以及各种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、访问的时间、访问的目标网页、来源的地址以及访问者所使用的客户端的UserAgent信息等。如果需要更多的信息,则要用其它手段去获取:例如想得到用户屏幕的分辨率,一般需要使用js代码单独发送请求;而如果想得到诸如用户访问的具体新闻标题等信息,则可能需要Web应用程序在自己的代码里输出。
为什么要分析日志
毫无疑问,Web日志中包含了大量人们——主要是产品分析人员会感兴趣的信息,最简单的,我们可以从中获取网站每类页面的PV值(PageView,页面访问量)、独立IP数(即去重之后的IP数量)等;稍微复杂一些的,可以计算得出用户所检索的关键词排行榜、用户停留时间最高的页面等;更复杂的,构建广告点击模型、分析用户行为特征等等。
既然这些数据是如此的有用,那么当然已经有无数现成的工具可以帮助我们来分析它们,例如awstats、Webalizer,都是专门用于统计分析Web服务器日志的免费程序。
另外还有一类产品,它们不分析直接日志,而是通过让用户在页面中嵌入js代码的方式来直接进行数据统计,或者说我们可以认为它是直接让日志输出到了它们的服务器。典型的代表产品——大名鼎鼎的Google Analytics,另外还有国内的cnzz、百度统计等。
很多人可能会说,既然如此,我们为什么还需要自己来分析日志,有必要吗?当然有。我们的用户(产品分析人员)需求是无穷尽的,上面说的这几类工具虽然很好很强大,但显然没办法满足全部的需求。
无论是本地分析的工具,还是在线的分析服务,它们虽然提很丰富的的统计分析功能,可以做一定程度的配置,但是依然很有限的。要进行稍复杂点的分析,或者要做基于日志的数据挖掘,依然需要自己来完成。
另外绝大多数日志分析工具都是只能用于单机的,数据量稍大就没辙了。同时那些提供在线分析的服务对于单个站点通常也都有最大流量的限制——这是很容易理解的,他们也需要考虑服务器的负载。
所以,很多时候还是得靠自己。
怎么进行日志分析
这并不是一个简单的问题。即使我们把“日志”限定为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 -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 BY ip_count DESC LIMIT 100
至于性能问题,数据库的索引和各种优化机制通常会让我们的统计分析工作变得更快,并且上面提到的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来完成。首先要在第一轮的mapper中计算部分ip的访问次数之和,并以ip为key输出:
//遍历输入,并聚合结果
foreach(record in input) {
ip = record.ip;
dict[ip]++;
}
//用emit输出,第一个参数为key,用于reduce的分发
foreach(<ip, count> in dict) {
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(<ip, count> in dict) {
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过程也会变得复杂,简单的转换导入脚本很可能已经解决不了问题。这时候可能需要构建一个数据管理系统,或者干脆考虑建立一个所谓的数据仓库。
总之,随着日志数据量、日志类型、用户数量、分析需求等等的不断增长,越来越多的问题会逐渐浮现出来,日志分析这件事情可能就不再像我们最初想的那么简单,会变得越来越有价值,也越来越有挑战。
转自:http://stblog.baidu-tech.com/?p=310
发表评论
-
用Sqoop把数据从HDFS导入到MYSQL
2012-10-27 23:30 2353转自:http://www.kaifajie.cn/mySQL ... -
大数据的储存:百度HDFS集群的数据压缩
2012-08-30 17:48 12072012年4月13日,由IT168(ITP ... -
用sqoop进行mysql和hdfs系统间的数据互导
2012-07-31 16:32 1940转自:http://abloz.com/2012/07/19/ ... -
从hive将数据导出到mysql
2012-07-31 16:31 1824转自:http://abloz.com/2012/07/20/ ... -
Hive SQL
2012-07-19 13:49 1426转自:http://www.tbdata.org/ ... -
Hive优化总结
2012-07-09 15:18 4331优化时,把hive sql当做ma ... -
hadoop/mapred 优化方法
2012-06-12 11:47 1396从三个方面着手优化 : 1. hadoop配置 2. ... -
hadoop集群dfs.data.dir目录权限问题导致节点无法启动
2012-06-11 18:32 6227安装使用Hive的时候发现文件无法从本地拷贝到hadoo ... -
hadoop中的balancer
2012-06-11 15:49 1143对于HDFS集群,经常长时间的运行,尤其是大量的delete操 ... -
Hadoop集群上使用Lzo压缩
2012-05-28 11:03 934转自:http://www.tech126.com/hadoo ... -
使用Hive读取Hbase中的数据
2012-05-23 13:12 2274转自:http://www.4ucode.com/Study/ ... -
在XP系统下配置eclipse集成hadoop开发
2012-05-05 11:09 1048一、目的:由于hadoop只能在Linux环境下运行,所以对于 ... -
使用Hive读取Hbase中的数据
2012-04-18 14:24 1097转自:http://www.4ucode.com/Study/ ... -
应用sqoop将MySQL数据库中的数据导入Hbase
2012-04-12 11:31 2066转自:http://www.bwxxkj.com/a/jish ... -
hadoop中的trash机制,恢复删除的文件
2012-03-31 13:46 2200Hadoop回收站trash,默认是关闭的。 1.修改con ... -
Hadoop 和DBMS 的互补性
2012-03-29 12:22 672随着Microsoft 也加入Hadoop 阵营,Hadoop ... -
Hadoop 中的两表join
2012-03-29 12:20 850转自:http://www.gemini52013 ... -
各版本编译hadoop eclipse plugin
2012-03-29 12:19 1382转自:http://www.gemini52013 ... -
hadoop常见错误
2012-03-24 13:04 1665错误1:bin/hadoop dfs 不能正常启动,持续提 ... -
hbase运维
2012-03-23 17:33 1307转自:http://blog.bluedavy.c ...
相关推荐
### Web日志挖掘数据预处理技术的研究与实现 #### 摘要 本文旨在探讨Web日志挖掘数据预处理技术的重要性和其实现方法。Web日志挖掘是指通过对Web服务器日志进行数据分析,揭示用户访问模式及其行为特征的一种数据...
【Web日志数据挖掘模型研究】是针对海量的Web日志数据进行分析和挖掘的科研领域,旨在通过解析用户访问模式来提升服务质量。在信息爆炸的时代,了解用户需求成为企业竞争的关键,而Web日志正是获取用户行为的重要...
为了加强服务器的安全防护,利用Web日志数据挖掘技术进行安全分析和威胁监测成为了一种有效的方法。 Web日志数据挖掘主要是在分析用户存取模式的基础上,对网络上的相关数据进行深入挖掘,以便及时发现用户访问的...
本文将详细探讨服务器Web日志分析软件的相关知识点,以及如何利用这样的工具进行有效的数据挖掘。 首先,我们要理解什么是Web日志。Web日志是Web服务器在处理HTTP请求时记录的一系列事件,包括但不限于用户访问、...
### 基于数据仓库Web日志的数据挖掘实例解析 #### 一、引言 随着互联网的普及和发展,大量的用户行为数据被记录下来,成为宝贵的商业资源。如何有效地利用这些数据,提取有价值的信息,成为了现代商业竞争的关键之...
未来,随着Hadoop框架的不断演进和优化,以及更多智能算法的融入,基于Hadoop的Web日志挖掘将在互联网数据分析领域发挥更加关键的作用,为企业决策提供更为精准的数据支持。 #### 六、参考文献 由于篇幅限制,此处...
本文旨在探讨Web日志挖掘技术,重点介绍两种主流的技术方法:基于Web事务的方法和基于数据立方体的方法。此外,文中还提出了一种应用案例——用户自适应的Web站点,并详细阐述了该系统的实现方法及其特点。 #### ...
基于Web日志的数据挖掘,正是数据挖掘技术的一个应用分支,其目的在于分析存储在Web服务器上的日志数据,从中挖掘出用户访问行为的模式和潜在的价值。 Web日志文件记录了用户访问网站时的行为和交互过程,这些日志...
在IT行业中,Web日志安全分析是网络安全领域的重要一环,尤其在当今互联网环境中,网站安全面临着各种威胁,如SQL注入、XSS攻击、DDoS等。"Web日志安全分析工具 v2.0"是一款专门针对这些问题设计的工具,其主要目标...
### 基于Web的数据挖掘概述 #### 一、引言 随着互联网的快速发展和广泛应用,数据挖掘成为了处理海量信息的重要工具。数据挖掘是从大量、不完全、有噪声、模糊和随机的数据中提取有价值信息的过程。本文将重点探讨...
基于Web日志的数据挖掘初探.pdf
"WEB服务器日志数据"这个主题涉及到的知识点广泛,包括日志文件的结构、内容、分析方法以及其在WEB挖掘中的应用。 1. **日志文件结构**:Web服务器日志文件通常遵循特定格式,如IIS(Internet Information Services...
Hive提供的HQL查询语句,使得这些复杂的分析任务变得简单高效。 5. 结果展示模块:将分析的结果以图表或报表的形式展现出来,为用户提供直观的分析结果。 在实施Web日志分析系统的过程中,还需要考虑系统的可扩展...
其中结构化数据的抽取、信息整合、观点挖掘和Web使用挖掘等4章是《Web数据挖掘》的特色,这些内容在已有书籍中没有提及,但它们在Web数据挖掘中却占有非常重要的地位。当然,传统的Web挖掘主题,如搜索、页面爬取和...
Web日志挖掘作为数据挖掘的一个重要分支,未来的研究方向包括提高挖掘算法的效率和准确性,更好地处理大规模数据集,以及利用新算法和模型来应对日志数据的多样性和复杂性。此外,随着大数据和云计算技术的发展,...
Hadoop的分布式计算能力使得对海量日志数据的分析变得可能。例如,使用Hive进行SQL查询,可以快速获取各种统计信息;或者使用Pig进行数据流处理,灵活定义数据转换逻辑。 3. **统计结果的导出** 结果导出通常涉及...
web mining_xml web日志挖掘
尤其是在Web环境下,由于信息的庞杂性和用户的注意力限制,数据挖掘技术的应用变得尤为重要。本文主要介绍数据挖掘技术在Web中的应用,特别是基于Apriori算法的Web日志挖掘技术。 #### 二、Web数据挖掘概述 ##### ...
命令行下的Web日志审计工具,旨在帮助使用者能够在终端上快速得进行Web日志审计和排查,包含了日志审计、统计的终端图形化和机器学习识别恶意请求的功能。 访问量统计 日志审查 请求等统计 恶意请求分析 【安装运行...