百度第三代Spider是什么？在过去，百度搜索引擎的数据处理的多数工作是由MapReduce系统完成的，处理延时达到天级。从2014年开始，Spider系统进行了大规模重构，以搜索结果更新延迟从周级缩短到分钟级为目标，设计实现了海量实时数据库Tera。在此基础上，构建了每天实时处理几万亿链接与网页更新的百度第三代Spider系统。
区别于上一代系统，新系统的核心流程全部实时化，从互联网上出现一篇新网页，到基于历史分析与机器学习快速发现链接，到基于链接价值的抓取调度，再到对网页进行分类、筛选每个步骤都在几秒钟内完成，以保证新网页能以分钟级更新到搜索结果中。
也就是说，当互联网上产生一个新的网页时，Spider 2.0把它下载回来的时间大概是2-3天，而Spider 3.0却只需要5分钟，相当于大概是3个量级的提升。
搜索引擎与Spider3.0
首先故事从互联网和搜索引擎开始，大家平时经常接触到的互联网以及百度搜索引擎，很多人也思考过互联网上的网页怎么转化成百度搜索引擎里面这十条结果的。这里面的工作分为很多阶段，最开始，由Spider去做信息采集。
后面的Pagerank其实代表了一系列的计算，包含了反作弊、去重和基于页面质量的筛选等等。此阶段之后会对网页进行切词，计算网页的正排，再做转置变成倒排。最后进入检索系统供网民直接检索。Spider是该系统的起点，它的主要目的就是快速、全面地采集全网数据。那么，全网数据到底是什么概念呢？
大家设想一下，当前中文互联网到底有多少网页？不知道有多少人尝试算过或者估算过，其实我们也不知道具体的数字，但是我们通过搜索引擎估算，结果大概有100万亿的网页。其中高质量的部分大概有10万亿，这10万亿就是百度Spider所要采集网页的核心任务。
但是，光采集回来还不够，还要知道它到底有没有价值。中文互联网每天新增多少网页？100亿，也就是说互联网每天就会产生100亿的新网页。那么会产生多少条超级链接呢？每个网页上会有多少条链接？百度统计的大概结果是，平均一张网页上有120条链接，这不是指特定某个网页上有120条，而是平均值。从这一点就看到整个百度Spider每天要处理的数据量，大概每天要处理1万多亿的链接。
怎么去处理这么大规模的数据，其实在过去有个比较通用的解决方案：Hadoop。所有持久化数据存储在HDFS中，通过MapReduce任务进行选取、挖掘、回灌和抓取结果入库。
但这个Spider有什么问题吗？其实它的首要问题就是线性扩展的问题。很多时候大家接触到的线性扩展或者水平扩展都是一个褒义词，即用10倍的机器就能处理10倍的数据，线性增长，处理能力没有明显的下降。
但是，在这里它却变成了一个严重的问题：举个例子，在过去Spider系统每天处理1000亿链接的时候需要500台服务器，而今天互联网上的链接呈爆炸性的增长，系统每天要处理10万亿级的链接，就需要5万台服务器，这肯定是一个不可承受的代价或者成本，所以这时候必须得有新的解决方案，不能再做全量的处理，必须有一种增量的，只处理新链接的方式。
很多人看到后可能有些失望，百度Spider就这么点东西吗？其实大家仔细去想，简单代表了更更大的灵活性和更强的扩展性。它其实就是一个流式计算系统，然后系统中的每一个策略也好，或者过程也好，都是流式系统上的一个算子，比如调度、抓取、页面解析、页面打分、链接权值打分。
整套系统的核心在于数据。一方面，做实时数据处理，表面上完成工作的是这些算子和计算流程，而每个算子的计算都依赖与数据的输入和输出，算子的计算延迟很大程度上决定于输入数据的获取延迟，输出数据的写出延迟。算子计算的稳定性又依赖与数据的不重不丢，这些数据必须有一个持久存储，又能随时、随地获取的方式，这样才能更好的去做实时的流式的处理。
另一方面，区别于普通的流式处理，如果仅去对单个链接或网页做流式处理，常规的Strom、Flink这些框架都是可以做到的。那么，它的真正的难点是什么？其实整个搜索引擎的计算，数据之间是有依赖性的，一张网页的价值谁说了算，一部分是由所在站点的权值和路径深度决定，更多的是由指向它的链接（前链）来投票决定。
也就是说处理一张网页时其实要同时处理整个数据集里面上百处位置的状态，一张网页价值变化了，要同时更新网页上包含的所有链接对应网页的权值，同样，在判断一个链接的价值时，也可能要依赖它的成百上千个前链上的实时数据。这就要求前面提到的那个可以随时、随地访问的数据集不是一个局部数据集，而是涵盖互联网全网数据的全集。