尽管与Google Analytics相比,Google Urchin有诸多不足,但作为一款入门级的付费流量统计工具,Google Urchin仍然非常实用。我觉得最大的优点在于实时性、大数据量的应用,对于大部分电商已经够用,当然进一步的路径和交叉细分等Google Analytics的新功能仍然是Urchin的痛,谷歌甚至在2012.3.28完全停止Urchin的售卖。Anyway,这并不影响它的使用,仍然有很多公司在用Urchin,而且很多同学可以把Urchin作为付费流量统计工具的入门工具来学习。今天主要来谈一下Google Urchin系统优化的问题。本篇先介绍针对系统本身的优化。

要谈Google Urchin的系统优化,我们需要了解它的工作原理:①按照日志过滤器规则,从指定目录中抓取日志包;②按照过滤器规则,从日志包中抓取指定字段;③按照设置的数据规则,对数据进行重组、筛选和分析;④将分析后的数据归档储存,当用户从客户端查看数据时,系统会在指定的数据目录调取数据。现在我们知道应该从哪些方面进行优化了——当然是针对系统运行的每个节点。(注:升级硬件,优化服务器的事情就交给系统运维同事把,此部分只谈与Urchin有关的优化)

一、优化Log日志包

谷歌Urchin日志包优化

(一)优化需要抓取的Log日志包数量
Urchin系统运行的第一步就是抓取日志包,日志包数量过多会增加系统抓取的时间,造成日志包过多的原因大概有两个:
1.在日志分割和传输的过程中,时间节点控制的过细。意思是,如果日志包是以小时为单位传输的,一天是12个包;但是如果是以一刻钟(15分钟)为单位传输的,一天是60个包。日志包过多会直接增加Urchin对日志包的判断时间,从而消耗系统资源。有的同学会说,那就按照小时传输——这需要一个平衡。细分日志包是为了更实时的传输日志,对大型促销活动的数据查看和数据细分分析尤为重要。如果你的网站没有这种需求(按照小时实时查看),那就以小时为单位传输就好。
2.时间过长导致的日志包堆积。通常情况下我们会指定一个目录存放原始Log包,但是随着时间的积累,日志包会越来越多。如果工程师给力,那就做个简单的小程序吧,规则很简单——指定目录里只存放最近2天的Log包,其他日志包自动移动到按照月/周命名的文件夹里。如果不够给力的话,那只能手动。
(二)优化Log日志包的传输速度
Log日志包的传输速度主要受存放位置的影响,这里的存放位置指的是Urchin运行程序和Log存储的位置。如果二者是存放在同一台远程服务器,那么日志的抓取会很容易;但如果二者分别在不同的服务器上,日志抓取就可能会受网络情况的限制。

二、优化过滤器

(一)减少过滤器数量
过滤器数量越多,Google Urchin在按照规则进行过滤时所花费的时间越多。这个容易理解。
(二)优化正则表达式
1.提高每个正则表达式的运行效率。正则表达式几乎可以应用在Google Urchin的所有过滤条件中,更精确的匹配会让系统更容易识别并应用规则。举个栗子,假设我们只需要过滤首页URL的流量(假设首页就是abc.com),那么 ^abc.com$ 会比 abc.com$ 执行效率更高,因为前者通过规则限定,以a为开头,以m为结尾的URL;而后者的规则是以m为结尾的所有URL。我不是技术专家,更多规则请大家自行百度一下,以下提供一些常识性的建议:

  • 如果你的正则工具支持,在不需要引用括号内文本的时候使用非捕获型括号:(?:expression) 。
  • 如果括号是非必须的,请不要加括号。
  • 不要滥用字符数组,比如[.],请直接用\. 。
  • 使用锚点^ $ ,这会加速定位。
  • 从两次中提取必须元素,如:x+写成xx*,a{2,4}写成aa{0,2}。
  • 提取多选结构开头的相同字符,如the|this 改成th(?:e|is)。(如果你的正则引擎不支持这么使用就改成th(e|is));尤其是锚点,一定要独立出来,这样很多正则编译器会根据锚点进行特别的优化: ^123|^abc 改成^(?:123|abc)。同样的$也尽量独立出来。
  • 多选结构后边的一个表达式放入多选结构内,这样能够在匹配任何一个多选结构的时候在不退出多选结构的状态下查看后一匹配,匹配失败的更快。这种优化需要谨慎使用。
  • 忽略优先匹配和优先匹配需要你视情况而定。如果你不确定,请使用匹配优先,它的速度是比忽略优先快的。
  • 拆分较大正则表达式成一个个小的正则表达式,这是非常有利于提高效率的。
  • 模拟锚点,使用合适的环视结构来预测合适的开始匹配位置,如匹配十二个月份,可以先预查首字符是否匹配:(?=JFMASOND)(?:Jan|Feb|…|Dec)。这种优化请根据实际情况使用,有时候环视结构开销可能更大。
  • 很多情况下使用固化分组和占有优先量词能够极大提高速度。
  • 避免像(this|that)*这样的几乎无尽的匹配。上边提到的 (…+)*也类似。
  • 如果能简单的匹配大幅缩短目标字符串,可以进行多次正则匹配,经过实践十分有效。

2.合理使用高级过滤器。
高级过滤器是为了满足特定需求而使用的,常用来显示主域、显示自定义URL标记参数、显示搜索词、将特定URL分组和字段值组合等,如果你的业务没有那些需求,那就不要用高级过滤器。

三、优化分析日志

分析日志是Google Urchin对原始日志进行分析后的数据,按月归档存放在指定的目录中,如Program Files\Urchin7\data\reports。这意味着,无论前台是按月、周或者日查看数据,在后台Urchin都是在月度数据中查找定位。如果前台查找的数据是跨月的,Urchin还需要从两个文件夹中调去数据,因此会占用更多系统资源,减慢查询速度。因此,如果业务没有特殊需求,我们可以将其他月份数据备份后移除,只保留最近两个月数据即可。(Tips:建立配置文件时,建议中英文结合,原因是Urchin分析数据目录不支持中文,在后台是转码的,英文可以帮助我们更快的找到相应的配置文件分析数据,这对分析数据的转移非常重要)

四、优化调度

Google Urchin时间调度优化
调度是Google Urchin非常重要的时间管理和配置工具,是系统自动运行的时间控制中枢。Urchin时间调度分为五种:从不、每小时、每天、每周和每月。
(一)优化调度频率
1、每天。此调度下,第二天可以看到昨天数据,通常可以满足90%以上的业务节点数据需求。由于配置文件每天运行,指定运行目录日志包仅包含最近一天可最大化提高运行效率。
2、每小时。每小时运行适用于大型推广活动当天或重大特殊事件时的数据实时监控,由于数据是按小时跑,因此日志包最低传输频率是每小时一次。根据我的操作经验,实际指定的运行日志包目录,跟每天运行相同即可,运行效率很高,不会影响系统情况。
3、每周/月。每周/月运行的调度,我用的不多,主要原因是时间过长造成的原始Log日志包数据过多,要持续运行一周/月的数据将持续消耗系统资源,对系统响应造成极大影响。因此,我建议不要采用这两种调度程序,而改成每天运行,将数据细分到每天的运行当中即可。不过,如果你的服务器硬件绝对没有问题,并且日志量不大,跑一个月的数据速度也会比较快,不会对系统响应造成太大影响。
(二)优化调度时间
调度时间段最小选择单位是以五分钟为单位的分钟,其次是小时。通常我们会选择在第二天凌晨运行程序,这样白天工作时间各业务节点可以马上查看昨天数据。因此,保证分析日志在上午9点之前跑完是必须的。要实现这个业务需求,首先要清楚在当前软硬件配置下,每个配置文件大概在什么时间运行、每次运行多长时间,建议大家做一个简单统计即可(此数据在“配置文件任务历史记录”中有记录)。
通常按天跑的配置文件,每次运行时间不长,我操作过的配置文件在全数据量的条件下也只运行3个多小时,其他有过滤的配置文件或按小时的配置文件运行时间更短。这里有一点要注意,配置文件的运行时间跟当时同时运行的配置文件数量紧密相关,这意味着,如果我们改变调度时间,运行时间也可能发生改变。我们要做的就是梳理下每个配置文件的开始时间、运行时间和结束时间,避免多个配置文件在同一时间同时运行形成系统运行瓶颈。

五、优化负载平衡与并行日志处理

对访问量负载较重的网站来说,使用一个网络服务器可能不够。通过使用负载平衡,并行工作的几个网络服务器可以分摊访问量。所用的并行网络服务器组称为簇。采用这种方式,可在任何可用的并行日志中记录各个网站的活动。 “配置文件设置”向导提供了”并行日志处理”选项。当启用并行日志处理时,Urchin 会立即打开所有日志文件并轮流进行读取,每次读取一部分,每部分对应 15 分钟的日志活动。启用”并行日志处理”可大幅提升负载平衡网站的性能。

上面五条都是针对系统本身的优化,下一篇我们再来谈谈针对业务节点的优化措施。



除非注明,本博客文章均为 数据研究与商业应用(TonySong) 原创.
转载请注明本文地址: http://www.searchmarketingart.com/google-urchin-7-system-optimization.html