360搜索的百亿级网页搜索引擎的架构设计与实现( 三 ) _360搜索

首先离线建库这一块，我们要有一些基础设施，主要有三部分：Hbase/HDFS、Map-reduce、Storm/Kaka 。
第一个是Hbase和HDFS 。我们的网页量级很大，我们会把互联网上所有的网页抓取过来存到Hbase库里，我们也会把我们提供检索的网页存到Hbase库里面。为什么用Hbase呢，因为Hbase是一个面向分布式，并支持列存储的。支持列存储这一点对我们很重要，因为我们所有的网页在抓取的过程中，包括rank同学在做rank计算的过程中，都会做一些部分更新，就是按照他们所需要的数据进行更新，那列存储就很容易满足我们的需求。HDFS 主要用于建索引和存储产出的索引文件，这些都是落地数据，启动了和线上更新衔接的作用(线上从HDFS拉取数据) 。
当然我们的搜索引擎也会涉及到时效性的问题，特别是突发时效性，可能会也需要有实时计算模型。我们目前的话也基于Storm，当然还有我们自己内部在做的一些实时性的开发项目。
整个离线建库主要的核心点有三个部分。
第一个就是索引划分。所谓索引划分，百亿级的网页我们不可能用一个数据库就表示出来，即使我们能表示出来一点，也没有这么大的机器来提供这样一个磁盘存放这些数据，因为索引大概是几P的一个量级。所以说我们需要把索引划分成小的网页集合，然后再针对小的网页集合做索引库，在小的网页集合的基础上和线上的在线服务做一个一一对应的关系。
第二点是索引创建。索引创建这一块基本上是基于Map-reduce跑的批量任务。因为我们上百亿的网页需要跑下来的话，可能需要的资源很多，时间也会拉得很长，Map-reduce本身提供了分布式计算的机制，能够满足我们的需求。
第三点是索引更新。这一块主要涉及到的一是我们每天新抓过来的数据；二是rank的同学要做线上特征，或者属性的一些迭代计算，要更新到线上。所以说也会涉及到百亿级别的数据的索引更新。
在线检索
在线检索的基础设施有三部分：分布式服务、请求广播、负载均衡。

分布式的服务框架是在线检索的一个基础配件；
在索引划分的时候，我们会把大的网页集合换成小的集合，在提供检索的时候，我们会以广播的方式来广播到各个小的索引单元，收集所有符合预期的网页集合才能够把它做归并排序，选出最优数据；
在线检索服务我们需要考虑更多的还有系统本身的稳定性，这个主要靠负载均衡来保证。

在线检索里面最底层的两个核心模块是求交计算和基础相关性计算。
架构
我会通过下面这个图给大家大概讲解一下搜索引擎整体架构的流程。

文章插图

首先我们先从官网上抓取网页，抓取的网页会存到基于Hbase的网页库里。这个是一个万亿量级的网页库，下一步要做的工作是质量筛选，然后我们会把通过质量筛选的网页放到我们的索引网页库中，所有的建库，包括rank计算，以及所有与搜索引擎相关的部分都是依赖于下边的网页索引库进行的。我们在建索引的时候，会做一个分片处理，分片的机制采用了区间划分。那么区间划分基本上我们就是用md5作为Key，本身md5是64位的整数，按照这64位整数的范围作为一个区间划分。从url转换上md5它本身是均匀分布的，那我们分片按照这个区间划分也会是均匀的，实际上我们划分的各个索引节点的量级也是均等的。
进行分片之后，我们会针对每个分片基于Map-reduce来跑，生成索引，索引主要包括上面讲的正排索引和倒排索引。然后会把索引推送到下面的在线服务推荐，每个在线服务推荐负责一个索引库。这里可以看到，我们根据网页的类型对索引库也做了一个划分，比如说重要网页索引库和普通网页索引库。
还有一个问题，就是我们每天的新增的网站，超过我们实时的网页怎么办？这种情况我们会走另外一个流程，在网页抓取过来之后，也会有一个质量筛选，这个质量筛选有2个流程，第一个是实时计算，通过我们刚才讲到的Storm集群，包括我们目前公司内部的Titan集群，进行实时计算来生成实时性的索引。第二个是我们会把每天更新的这些数据做批量计算，基于Map-reduce生成一个相互索引，这样的话在时间上能够覆盖到所有的时间点。
整个离线建库基本是这样一个流程，下面介绍一下在线检索的模块。用户检索过来之后，我们首先做一个query分析。然后我们把query分析的结果扔给分布式服务的一个请求节点，这个请求节点通过广播的方式会把请求广播到这几种索引库这里。在索引库内部会做一些求交计算。第二步我们会做基础相关性的计算，然后把优质结果的Top N 来返回给上层的服务请求节点。服务请求节点还会做一些策略，比如说用户的一些特定需求，包括一些机器学习的排序，最终返回给用户的网页基本上是几百条的一个量级。