深入浅出搜索架构引擎、方案与细节（上）

一、缘起

《100 亿数据 1 万属性数据架构设计》文章发布后，不少朋友对 58 同城自研搜索引擎 E-search 比较感兴趣，故专门撰文体系化的聊聊搜索引擎，从宏观到细节，希望把逻辑关系讲清楚，内容比较多，分上下两期。

主要内容如下，本篇（上）会重点介绍前三章：

（1）全网搜索引擎架构与流程

（2）站内搜索引擎架构与流程

（3）搜索原理、流程与核心数据结构

（4）流量数据量由小到大，搜索方案与架构变迁

（5）数据量、并发量、策略扩展性及架构方案

（6）实时搜索引擎核心技术

可能 99% 的同学不实施搜索引擎，但本文一定对你有帮助。

二、全网搜索引擎架构与流程

全网搜索的宏观架构长啥样？

全网搜索的宏观流程是怎么样的？

全网搜索引擎的宏观架构如上图，核心子系统主要分为三部分（粉色部分）：

（1）spider 爬虫系统

（2）search&index 建立索引与查询索引系统，这个系统又主要分为两部分：

一部分用于生成索引数据 build_index

一部分用于查询索引数据 search_index

（3）rank 打分排序系统

核心数据主要分为两部分（紫色部分）：

（1）web 网页库

（2）index 索引数据

全网搜索引擎的业务特点决定了，这是一个“写入”和“检索”完全分离的系统：

【写入】

系统组成：由 spider 与 search&index 两个系统完成

输入：站长们生成的互联网网页

输出：正排倒排索引数据

流程：如架构图中的 1，2，3，4

（1）spider 把互联网网页抓过来

（2）spider 把互联网网页存储到网页库中（这个对存储的要求很高，要存储几乎整个“万维网”的镜像）

（3）build_index 从网页库中读取数据，完成分词

（4）build_index 生成倒排索引

【检索】

系统组成：由 search&index 与 rank 两个系统完成

输入：用户的搜索词

输出：排好序的第一页检索结果

流程：如架构图中的 a，b，c，d

（a）search_index 获得用户的搜索词，完成分词

（b）search_index 查询倒排索引，获得“字符匹配”网页，这是初筛的结果

（c）rank 对初筛的结果进行打分排序

（d）rank 对排序后的第一页结果返回

三、站内搜索引擎架构与流程

做全网搜索的公司毕竟是少数，绝大部分公司要实现的其实只是一个站内搜索，站内搜索引擎的宏观架构和全网搜索引擎的宏观架构有什么异同？

以 58 同城 100 亿帖子的搜索为例，站内搜索系统架构长啥样？站内搜索流程是怎么样的？

站内搜索引擎的宏观架构如上图，与全网搜索引擎的宏观架构相比，差异只有写入的地方：

（1）全网搜索需要 spider 要被动去抓取数据

（2）站内搜索是内部系统生成的数据，例如“发布系统”会将生成的帖子主动推给 build_data 系统

看似“很小”的差异，架构实现上难度却差很多：全网搜索如何“实时”发现“全量”的网页是非常困难的，而站内搜索容易实时得到全部数据。

对于 spider、search&index、rank 三个系统：

（1）spider 和 search&index 是相对工程的系统

（2）rank 是和业务、策略紧密、算法相关的系统，搜索体验的差异主要在此，而业务、策略的优化是需要时间积累的，这里的启示是：

a）Google 的体验比 Baidu 好，根本在于前者 rank 牛逼

b）国内互联网公司（例如 360）短时间要搞一个体验超越 Baidu 的搜索引擎，是很难的，真心需要时间的积累

四、搜索原理与核心数据结构

什么是正排索引？

什么是倒排索引？

搜索的过程是什么样的？

会用到哪些算法与数据结构？

前面的内容太宏观，为了照顾大部分没有做过搜索引擎的同学，数据结构与算法部分从正排索引、倒排索引一点点开始。

提问：什么是正排索引（forward index）？

回答：由 key 查询实体的过程，是正排索引。

用户表：t_user(uid, name, passwd, age, sex)，由 uid 查询整行的过程，就是正排索引查询。

网页库：t_web_page(url, page_content)，由 url 查询整个网页的过程，也是正排索引查询。

网页内容分词后，page_content 会对应一个分词后的集合 list。

简易的，正排索引可以理解为 Map>，能够由网页快速（时间复杂度 O(1)）找到内容的一个数据结构。

提问：什么是倒排索引（inverted index）？

回答：由 item 查询 key 的过程，是倒排索引。

对于网页搜索，倒排索引可以理解为 Map>，能够由查询词快速（时间复杂度 O(1)）找到包含这个查询词的网页的数据结构。

举个例子，假设有 3 个网页：

url1 -> “我爱北京”

url2 -> “我爱到家”

url3 -> “到家美好”

这是一个正排索引Map。

分词之后：

url1 -> {我，爱，北京}

url2 -> {我，爱，到家}

url3 -> {到家，美好}

这是一个分词后的正排索引Map>。

分词后倒排索引：

我 -> {url1, url2}

爱 -> {url1, url2}

北京 -> {url1}

到家 -> {url2, url3}

美好 -> {url3}

由检索词 item 快速找到包含这个查询词的网页 Map> 就是倒排索引。

正排索引和倒排索引是 spider 和 build_index 系统提前建立好的数据结构，为什么要使用这两种数据结构，是因为它能够快速的实现“用户网页检索”需求 **（业务需求决定架构实现）**。

提问：搜索的过程是什么样的？

假设搜索词是“我爱”，用户会得到什么网页呢？

（1）分词，“我爱”会分词为 {我，爱}，时间复杂度为 O(1)

（2）每个分词后的 item，从倒排索引查询包含这个 item 的网页 list，时间复杂度也是 O(1)：

我 -> {url1, url2}

爱 -> {url1, url2}

（3）求 list 的交集，就是符合所有查询词的结果网页，对于这个例子，{url1, url2} 就是最终的查询结果

看似到这里就结束了，其实不然，分词和倒排查询时间复杂度都是 O(1)，整个搜索的时间复杂度取决于“求 list 的交集”，问题转化为了求两个集合交集。

字符型的 url 不利于存储与计算，一般来说每个 url 会有一个数值型的 url_id 来标识，后文为了方便描述，list 统一用 list 替代。

list1 和 list2，求交集怎么求？

方案一：for * for，土办法，时间复杂度 O(n*n)

每个搜索词命中的网页是很多的，O(n*n) 的复杂度是明显不能接受的。倒排索引是在创建之初可以进行排序预处理，问题转化成两个有序的 list 求交集，就方便多了。

方案二：有序 list 求交集，拉链法

有序集合 1{1,3,5,7,8,9}

有序集合 2{2,3,4,5,6,7}

两个指针指向首元素，比较元素的大小：

（1）如果相同，放入结果集，随意移动一个指针

（2）否则，移动值较小的一个指针，直到队尾

这种方法的好处是：

（1）集合中的元素最多被比较一次，时间复杂度为 O(n)

（2）多个有序集合可以同时进行，这适用于多个分词的 item 求 url_id 交集

这个方法就像一条拉链的两边齿轮，一一比对就像拉链，故称为拉链法

方案三：分桶并行优化

数据量大时，url_id 分桶水平切分 + 并行运算是一种常见的优化方法，如果能将 list1 和 list2 分成若干个桶区间，每个区间利用多线程并行求交集，各个线程结果集的并集，作为最终的结果集，能够大大的减少执行时间。

举例：

有序集合 1{1,3,5,7,8,9, 10,30,50,70,80,90}

有序集合 2{2,3,4,5,6,7, 20,30,40,50,60,70}

求交集，先进行分桶拆分：

桶 1 的范围为 [1, 9]

桶 2 的范围为 [10, 100]

桶 3 的范围为 [101, max_int]

于是：

集合 1 就拆分成

集合 a{1,3,5,7,8,9}

集合 b{10,30,50,70,80,90}

集合 c{}

集合 2 就拆分成

集合 d{2,3,4,5,6,7}

集合 e{20,30,40,50,60,70}

集合 e{}

每个桶内的数据量大大降低了，并且每个桶内没有重复元素，可以利用多线程并行计算：

桶 1 内的集合 a 和集合 d 的交集是 x{3,5,7}

桶 2 内的集合 b 和集合 e 的交集是 y{30, 50, 70}

桶 3 内的集合 c 和集合 d 的交集是 z{}

最终，集合 1 和集合 2 的交集，是 x 与 y 与 z 的并集，即集合 {3,5,7,30,50,70}

方案四：bitmap 再次优化

数据进行了水平分桶拆分之后，每个桶内的数据一定处于一个范围之内，如果集合符合这个特点，就可以使用 bitmap 来表示集合：

如上图，假设 set1{1,3,5,7,8,9}和 set2{2,3,4,5,6,7}的所有元素都在桶值 [1, 16] 的范围之内，可以用 16 个 bit 来描述这两个集合，原集合中的元素 x，在这个 16bitmap 中的第 x 个 bit 为 1，此时两个 bitmap 求交集，只需要将两个 bitmap 进行“与”操作，结果集 bitmap 的 3，5，7 位是 1，表明原集合的交集为{3,5,7}

水平分桶，bitmap 优化之后，能极大提高求交集的效率，但时间复杂度仍旧是 O(n)

bitmap 需要大量连续空间，占用内存较大

方案五：跳表 skiplist

有序链表集合求交集，跳表是最常用的数据结构，它可以将有序集合求交集的复杂度由 O(n) 降至 O(log(n))