日志分析–日志搜集

作者: JerryHouse 分类: 日志分析 发布时间: 2014-07-19 17:34 ė 6没有评论

“云”的出现使得拥有和维护网站变得简单和便捷,只需要按照服务商提供的按照帮助手册上的指示点击一系列按钮,一个新的网站随之诞生,再花上几十元钱,申请一个指向这个网站的域名,它就可以被全世界的人访问。在这些形形色色的网站中,有些用于记录和展示私人经历,而另外一些则肩负着带来更多购买公司产品的顾客的使命。公司尤其是互联网公司在衡量网站的状态是否达到目标时会采用很多指标,例如访问量(PV),访客数(UV),新客率,跳出率,转化率等等。其中的一些指标可以借助Google Analytics之类的第3方服务提供商得到,而另外一些指标就需要挖掘网站的访问日志才能够获得。<!–more–>设计合理的网站日志系统记录了用户在网站停留过程中每一次有价值的行为,通过挖掘这些记录,工程师们在统计上述指标之外可以发现更多的细节。我的第一份工作是家提供垂直搜索互联网公司的搜索工程师,工作的主要内容就是改进搜索结果排序,提升搜索质量,帮助用户更快,更简单地找到用户感兴趣的餐馆,酒吧,KTV等类型的商户。我们的搜索系统每天要处理千万次的搜索请求,这些搜索请求的关键词各不相同,即使是同样的关键词在不同的场景下用户也希望得到不同的结果,那么我们怎么知道用户到底想要什么呢?网站搜集到的日志在这个时候就排上了大用场,我们改进搜索排序的各种策略,也就是排序算法,都是通过挖掘用户的搜索日志得到的。

文章的标题叫做日志分析,其实忽略一个很重要的步骤:日志搜集。咋一想之下,大家会觉得日志搜集和日志分析是两个完全不同的阶段,两者之间是应该完全独立,互不影响的,相信大家看过我的经验之后应该会对这个问题有所改观:日志搜集系统数据存储方式设计的好,会极大的方便分析时数据的读取,搜集策略设计的好,可以极大的提升数据获取的及时性。

公司的日志搜集的流程如图1所示:

log

用户通过浏览器向HTTP服务器发起请求,然后HTTP服务器将搜索关键词,商户类型等条件查询传递给搜索服务器,搜索服务器从事先建立好的商户搜索引中得到满足这些查询条件的商户的集合。有时满足查询条件的商户的数量会比较多,用户从这个结果中找到他们需要的信息无异于大海捞针,所以搜索服务还需要使用特定的排序算法对结果列表中的商户进行排序,使得那些最有可能被用户点击的商户排在靠前的位置。排好序的商户列表随后被传递给HTTP服务器,HTTP服务器再将商户列表最终展现在用户的浏览器页面中。用户浏览行为的搜集工作由嵌在网页中的JavaScript片段完成,网页的载入,鼠标点击,键盘输入和拖拽等浏览器事件都会触发相应的JavaScript片段,JavaScript片段会将这些搜集到的数据以异步的方式发送给日志服务器。日志服务器会对原始日志进行清洗,去重,统一格式等工作,处理好后的日志会被同步到Hadoop集群中,本文称这部分数据为基础流量日志。搜索服务器除了接收搜索请求,返回高质量的搜索结果,同时还要记录处理搜索请求的整个过程,例如商户排序时使用的算法,匹配到的商户,商户的排序,Query处理等信息。搜索服务器记录的日志的格式统一以后,也会同步到Hadoop集群中,本文中称这部分数据为搜索流量日志。

如果我们仅仅想要知道网站一天有哪些页面被访问,每个页面被访问了多少次,用户在网站上进行了哪些搜索,每类搜索发生的次数以及这类搜索给出的商户列表是否被用户点击过,基础流量日志就可以满足我们的需求。搜索系统为了提高搜索结果质量,往往同时要上线多种不同的排序算法,分词算法并对比它们的效果,而这些搜索请求处理的细节信息存放在搜索流量日志中,因此需要将基础流量日志和搜索流量日志关联起来。关联工作的技巧在于使用query_id唯一标识一次搜索请求:HTTP服务器在请求搜索服务时会生成一个全球唯一的query_id,然后将该query_id和搜索请求同时传递给搜索服务器,搜索服务在返回搜索结果给HTTP服务器的同时也记录下query_id和处理这次请求的详细过程,HTTP服务器用得到搜索结果生成特定格式的网页时会将query_id嵌入到网页中。经过上述的一系列query_id的传递,客户端发回的任何和搜索相关的日志中都带有了query_id。这样设计的好处在于HTTP服务器不用关心搜索服务对请求的复杂的处理过程,在需要分析搜索后端的不同算法时,只需要通过query_id将基础流量日志和搜索流量日志关联。代码1是处理用户点击商户链接事件的JavaScript代码,在用户点击商户链接时该代码会将query_id, 商户id传递HTTP服务器。

<a target="_blank" track="tg_shanghai_recentlyview_3|1|module#3_nav_near,action#click,index#3,dealgrp_id#6049988,content#/deal/6049988" href="/deal/6049988"> <div class="image"> <img src="http://t1.s2.com/pc/ae(216c135)/thumb.jpg" title="代金券"> </div> </a>

代码1:日志搜集JavaScript代码

从图1的设计中可以看到:不论是基础流量日志还是搜索流量日志,最终都要同步到Hadoop集群中。一个中等规模的商业网站每天要生成千万级到亿级的日志记录,这么大规模的海量日志的处理是Mysql不能胜任的,而采用压缩文件的存储方式则会给日志分析工作带来很多不便,一是日志的数据量大到单机硬盘的存储和CPU的处理跟不上,而是会有很多像按时间顺序对日志进行排序之类的重复性的工作,因此公司将日志最终都存放在了Hadoop集群中,一方面Hadoop的分布式存储文件系统HDFS很好的解决了单机硬盘存储不足的问题,另一方面,Hadoop的分布式计算框架MapReduce很好的解决了单机计算能力不足的问题,此外Hive使得用户可以使用传统关系型数据库中使用的SQL对数据进行分析,不用再为排序,group by等重复性的操作而分心。

本文出自 dcharm,转载时请注明出处及相应链接。

本文永久链接: http://www.dcharm.com/?p=6

0

发表评论

Ɣ回顶部