接下来,我们来看看如何抓取任务
(1)单击WebUI菜单栏上的“Jobs”标签,就可以进入任务创建页面。
(2)在任务创建页面中,有4种创建任务的方式,具体含义如下。
1. Based on existing job:以一个已经有的抓取任务为模板,创建所有抓取属性和抓取起始URL的列表。
2 Based on a recovery:在以前的某个任务中,可能设置过一些状态点,新的任务将从这个设置的状态点开始。
3 Based on a profile:专门为不同的任务设置了一些模板,新建的任务将按照模板来生成。
4.With defaults:这个最简单,表示按默认的配置来生成一个任务。
在Heritrix中,一个任务对应一个描述文件。这个描述文件的默认的名称为order.xml。每次创建一个新任务时,都相当于生成了一个order.xml的文件。文件中详细记录了Heritrix在运行时需要的所有信息。例如,它包括该用户所选择的Processor类、Frontier类、Fetcher类、抓取时线程的最大数量、连接超时的最大等待时间等信息。上面所说的4种创建抓取任务的方式,其实都是在生成一个order.xml文件。其中,第4种With defaults,则是直接拷贝默认的order.xml文件。在所创建的Eclipse工程或是命令行启动的Heritrix下载包中,该默认的order.xml文件均是放于profiles/default目录下的。 关于order.xml的细节,在此还不必深究。因为它里面所有的内容,都会在WebUI上看到。
(3)单击With defaults链接,创建一个新的抓取任务。
(4)在新建任务的名称上,填入“Sohu_news”,表示该抓取任务将抓取搜狐的新闻信息。在Description中随意填入字符,然后再在seeds框中,填入搜狐新闻的网址。 这里需要解释一下seeds的含义。所谓seeds,其实指的是抓取任务的起始点。每次的抓取,总是需要从一个起始点开始,在得到这个起始点网页上的信息后,分析出新的地址加入抓取队列中,然后循环抓取,重复这样的过程,直到所有链接都分析完毕。
(5)设置了搜狐新闻的首页为种子页面,以此做为起始点。用户在使用时,也可以同时输入多个种子,每个URL地址单独写在一行上,。
当然,凭着目前的设置,还没法开始抓取网页,还需要对这个任务进行详细的设置。
设置抓取时的处理链
seeds文本框下有一排按钮,单击“Modules”按钮,就进入了配置抓取时的处理链的页面。
从上而下,可以看到,需要配置的内容共有7项,其中CrawlScope和Frontier是两个最重要的组件。CrawlScope用于配置当前应该在什么范围内抓取网页链接。比如,如果选择BroadScope,则表示当前抓取的范围不受限制,但如果选择了HostScope,则表示抓取的范围在当前的Host内。 从笔者的经验看来,在抓取时,无论是HostScope或PathScope都不能真正的限制到抓取的内容。需要对Scope内的代码进行一定的修改才可以,因此,暂时选择BroadScope来充当示例中的范围限定,其实也就是对范围不做任何的限定。即从news.sohu.com开始,抓取任何可以抓取到的信息。
Frontier则是一个URL的处理器,它将决定下一个被处理的URL是什么。同时,它还会将经由处理器链所解析出来的URL加入到等待处理的队列中去。在例子中,使用BdbFrontier类来做为处理器,全权掌管URL的分配。
除了这两个组件外,还有5个队列要配。这五个队列根据先后的顺序,就依次组成了Heritrix
的整个处理器链。5个队列的含义分别如下:
(1)PreProcessor:这个队列中,所有的处理器都是用来对抓取时的一些先决条件做判断的。比如判断robot.txt的信息等,它是整个处理器链的入口。
(2)Fetcher:从名称上看,它用于解析网络传输协议,比如解析DNS、HTTP或FTP等。在演示中,主要使用FetchDNS和FetchHTTP两个类。
(3)Extractor:它的名字就很好的揭示了它的作用。它主要用是于解析当前获取到的服务器返回内容,这些内容通常是以字符串形式缓存的。在这个队列中,包括了一系列的工具,如解析HTML、CSS等。在解析完毕,取出页面中的URL后,将它们放入队列中,等待下次继续抓取。在演示中,使用两种Extractor,即ExtractorHTTP和ExtractorHTML。
(4)Writer:主要是用于将所抓取到的信息写入磁盘。通常写入磁盘时有两种形式,一种是采用压缩的方式写入,在这里被称为Arc方式,另一种则采用镜象方式写入。当然处理起来,镜象方式要更为容易一些,因此,在演示中命名用镜象Mirror方式。
(5)PostProcessor:在整个抓取解析过程结束后,进行一些扫尾的工作,比如将前面Extractor解析出来的URL有条件的加入到待处理队列中去。
值得一提的是,在处理器链的设置过程中,每一个队列中的处理器都是要分先后顺序的,信息的处理流程实际上是不可逆的,因此,在设置时,可以看见在队列的右侧总是有“Up”、“Down”和“Remove”这样的操作,以帮助能够正确的设置其顺序。 在设置完Hertrix所需的处理链后,仍然还不能够马上开始抓取任务,还需对默认的运行时参数做一些修改,以适应真正的需要。
设置运行时的参数
在设置完处理链后,在页面顶部或底部都可以找到如图10-30所示的菜单项,单击“Settings”链接,就进入了属性设置的页面。
在属性设置页面上有非常多的输入域,Heritrix在抓取网页时,这些域是用来对的各个组件的值进行预设。
由于页面上的内容非常多,使用者可能无法全部了解它们的作用。所以Heritrix提供了一个辅助功能,来在最大程度上让使用者了解每个参数的含义。
可以看到,在每个属性的右侧都有一个小问号,当单击问号时,就会弹出一个Javascript的Alert提示框,上面介绍了当前属性的作用。例如,在上图中单击“max-bytes-download”属性,通过Alert的提示可以知道,它表示的是抓取器最大下载的字节数,当下载字节数超过这个属性上所设定的值时,抓取就会自动停止。另外,如果将这个值设为0,则表示没有限制。
事实上,当在第一次使用Heritrix时,所需要设置的参数并不多,以默认设置为主。以下就来介绍一些必须要在第一次使用时就要配置好的参数。
1.max-toe-threads
该参数的含义很容易了解,它表示Heritrix在运行该抓取任务时,为任务分配多少个线程进
行同步抓取。该参数的默认值为100,而事实上根据笔者的经验,在机器配置和网络均很好
的情况下,设置50个线程数就已经足够使用了。
2.HTTP-Header
在HTTP-Header这个属性域下面,包括两个属性值“user-agent”和“from”。默认情况下,
这两个属性的值。
很明显,这样的值是无法完成真实的HTTP协议的模拟的,所以,必须要将值改掉。
z “@VERSION@”字符串需要被替换成Heritrix的版本信息。 例如:1.12.1
z “PROJECT_URL_HERE”可以被替换成任何一个完整的URL地址。 例如:http://192.168.200.26
z “from”属性中不需要设置真实的E-mail地址,只需是格式正确的邮件地址就可以了。 例如:90caoxu@163.com
当正确设置了上述的两个属性后,Heritrix就具备了运行的条件。单击“Submit”链接,提交这个抓取任务。
运行抓取任务
(1)当单击“Submit job”链接后,会看到页面。页面中最上方很清楚的显示了“Job created”,这表示刚才所设置的抓取任务已经被成功的建立。同时,在下面的“Pending Jobs”一栏,可以清楚的看到刚刚被创建的Job,它的状态目前为“Pending”。
(2)下面启动这个任务。回到“Console”界面上,可以看到,刚刚创建的任务已经显示了出来,等待我们开始它。
(3)在面版的右测,它显示了当前Java虚拟机的一些状态,可以看到当前的堆大小为4184KB,而已经被使用了3806KB,另外,最大的堆内容可以达到65088KB,也就是在64M左右。
(4)此时,单击面版中的“Start”链接,就会将此时处于“Pending”状态的抓取任务激活,令其开始抓取
(5)刚才还处于“Start”状态的链接已经变为了Hold状态。这表明,抓取任务已经被激活。
(6)此时,面版中出现了一条抓取状态栏,它清楚的显示了当前已经被抓取的链接数量,另外还有在队列中等待被抓取的链接数量,然后用一个百分比显示出来。
(7)在绿红相间的长条左侧,是几个实时的运行状态,其中包括抓取的平均速度(KB/s)和每秒钟抓取的链接数(URIs/sec),另外的统计还包括抓取任务所消耗的时间和剩余的时间,不过这种剩余时间一般都不准,因为URI的数量总是在不断变化,每当分析一个网页,就会有新的URI加入队列中。
(8)在绿红相间的长条右侧,是当前的负载,它显示了当前活跃的线程数量,同时,还统计了Heritrix内部的所有队列的平均长度。
(9)真正的抓取任务还没有开始,队列中的总URI数量,以及下载的速率都还基本为0。这应该还处于接收种子URL的网页信息的阶段。让我们再来看一下当Heritrix运行一段时间后,整个系统的资源消耗和进度情况。
(10)在页面中,清楚的看到系统的资源消耗。其中,每秒下载的速率已经达到了23KB,另外,平均每秒有19.3个URI被抓取。在负载方面,初设的50个线程均处于工作状态,最长的队列长度已经达到了415个URI,平均长度为5。从进度条上看,总共有3771个URI等待抓取,已经完成了718个URI的抓取,另外,下载的字节总数也已经达到了1390KB。再观察一下左边,仅用时32s。可见,多线程抓取的速度还是很快的。
(11)不过,当抓取继续进行时,观察Java虚拟机的内存使用,发现其已达饱合状态。64M的最大Heap显然不够用。
(12)由于这仅是一次演示,可以忽略内存的影响。但在真正的开发过程中,使用Heritrix时,至少应为其分配512M的最大HeapSize,也就是在启动它时,应该设置-Xmx512m这个属性。在使用命令行方式启动Heritrix的脚本中,笔者已经为其加入了该参数,而如果要在使用Eclipse启动Heritrix时也设置该参数。
在运行的过程中,值得注意的一点是,进度条的百分比数量并不是准确的。因为这个百分比实际上是已经处理的链接数和总共分析出的链接数的比值。当页面在不断被抓取分析时,链接的数量也会不断的增加,因此,这个百分比的数字也在不断的变化。
读者可能已经发现,在Heritrix中,大量的链接被称为URI。从理论上说,URL应该是一个完整的地址,而URI应该是去除协议、主机和端口后剩余的部分。Heritrix中可能有一定程度的混淆,希望读者不要对此感到奇怪。
至此,已经把Heritrix成功的运行起来,并且抓取了一定的内容。接下来,看一下它是如何存储抓取下来的信息的。
Heritrix的镜象存储结构
由于在前面设置了Writer的类型为MirrorWriter。因此,磁盘上应该留有了所抓取到的网页的各种镜象。那么,究竟Heritrix是如何存储下镜象信息的呢? 打开Eclipse的workspace目录,进入heritrixProject的工程,里面有一个jobs目录。进入后,找到以刚才job的名称打头的文件夹,这里面的内容,就是Heritrix在运行时实时生成的。
其中,有一个mirror目录,进入后,就可以看到很多镜像了。
其实所谓镜象方式存储,就是将URL地址按“/”进行切分,进而按切分出来的层次存储,比如一个URL地址为:
http://news.sohu.com/index.html
那么它在mirror目录中的保存位置就该是new.sohu.com目录下的index.html文件。为了验证这一说法的准确性,打开new.sohu.com目录。
果然,index.html文件就在这个目录下。另外,Heritrix也同样将各种图片或脚本信息按路径进行了保存,例如,在news.sohu.com目录下有一个images目录,其中就保存了URL地址如http://news.sohu.com/images/xxx.gif这样的图片信息。
终止抓取或终止Heritrix的运行
当用户进行某个抓取任务时,有两种方法会让任务停止下来。
1.正常终止
第一种方法当然就是任务的自然结束,其条件为所有队列中的URI都已经被处理过了。此时,任务将自然终止。在“Jobs”面版上会看到任务已经完成,被加入到“Completed jobs”列表中。
2.强行终止
当然,任务不可能总是运行完,这可能是因为对任务的控制不够,结果抓取了太多不相关的信息,进而造成URL队列无限制膨胀,无法终止。在这种情况下,就需要强行将任务终止。在Console面版上有一排链接,最后一个“Terminate”链接,就是用来终止当前运行的任务。
单击“Terminate”链接后,当前在运行的抓取任务就会立即终止,并同样将任务放置到“Jobs”面版上的“Completed jobs”列表中,只不过在“status”上,它会显示“Finished - Ended by operator”这样的提示。
当然,如果用户希望关闭Heritrix,并终止所有正在运行的任务,也可以单击Console面版上的“Shutdown Heritrix software”的链接,此时,Heritrix会弹出一个警告,告诉你如果关闭Heritrix,则当前一切正在运行的任务都将被终止。
关闭前的提示
如果选择“I’m sure, shut it down”,则Heritrix的WebUI将会终止,虚拟机进程结束。