百度实时搜索技术的架构演变.docx

百度实时搜索技术的架构演变.docx

《百度实时搜索技术的架构演变.docx》由会员分享，可在线阅读，更多相关《百度实时搜索技术的架构演变.docx（10页珍藏版）》请在冰豆网上搜索。

XX实时搜索技术的架构演变

XX实时搜索技术的架构演变

【内容简介】XX搜索引擎从起初的文本搜索演化成有推荐，有图文的搜索形式，在AI时代，XX在移动搜索上做出了很多大胆的尝试来提升用户体验，而整个实时搜索技术又全部搭建在分布式表格存储系统Tera之上，那么Tera的基本原理是什么？

XX又如何基于Tera逐步构建出实时搜索系统的？

本案例将分享XX实时搜索技术的架构演变过程。

XX架构师郑然

搜索引擎

1 AI时代的移动搜索

为了让大家在移动搜索方面有更好的体验，XX做了很多工作来丰富移动搜索的结果，例如视频类搜索，一些垂类的，像音乐、娱乐等方面的信息搜索，以及电商搜索等。

XX搜索引擎根本的目标，是通过 WEB 平台链接人与信息，或者人与服务。

2 创造优质内容和用户体验

XX正在致力于创造优质内容，让搜索的体验能与媒体APP相媲美。

进而推出了PWA解决方案，和木桶网页的加速平台。

近期XX又推出了熊掌号平台，希望通过熊掌号把B端的站长和C端的作者相连接，鼓励他们创作出更多优质的内容来服务广大的用户。

但其实这些优质的内容也好，多种形式的搜索产品也好，都离不开XX后端搜索技术，那么搜索引擎究竟是一个什么样的架构呢？

内容抓取

由分布式爬虫系统实时抓取网络上的优质内容，抓取的范围包含互联网、APP及各种自媒体平台，并通过分布式索引构建系统，将抓取到的内容形成索引；其实抓取主要分两大部分：

第一，最基本的网页抓取，页面的解析，需要浏览器内核技术做动态渲染，把页面结果抓过来，第二，还有链接的抓取，最终的结果会存储两个库里，很多计算都是围绕着这两个库进行的。

一些批量挖掘计算和离线分析计算，最终计算出来的结果仍然会回到这两个数据库里。

索引构建

在得到页面信息后，需要进行索引筛选。

索引筛选其实就是通过分析页面的特征和价值，提取出需要构建索引的网页集合并计算出每个网页的优先级和时效长度，之后进行正排和倒排计算得到索引结果；

检索系统

因为实际的检索系统逻辑非常复杂，故此处仅讨论主要的架构层级。

核心的中枢（排序）服务需要调用底层索引服务，根据用户输入的需求做召回，经过分析和权重PK，最终将索引信息返回，通过展现服务友好的将结果呈现给用户，包括标题、摘要、缩略图、视频等形式；

以上三个计算环节都是基于Tera构建的，这样复杂的系统是怎样由批量转换成流式计算或者实时计算的呢？

首先要了解XX自研的分布式表格系统Tera。

分布式表格系统Tera

XX面临的问题：

XX存取着万亿链接，千亿的索引，每天需要更新几十亿网页。

在没有 Maprediuce 之前，机器的故障和错误会让人非常头疼，我们机器量越来越多，数据量越来越大，给运维，给线上服务的维护带来很多弊端。

但 Maprediuce 会存在着很严重的长尾问题。

Maprediuce 有一个特点是不得不进行全量计算，举一个例子，我们要计算叶子节点上的和，假设又新增了一个节点，想计算和怎么办？

用 Maprediuce 必须把所有的数据重新计算一遍，才能得到最终的计算结果。

如果不想重新全量计算，就必须把中间所有结果保存。

这对 Maprediuce 这种计算模型来说难度是非常大的。

所以不得不进行的全量计算就意味着我们在计算过程中有很多浪费，因为我们有一个非常大 base 的数据，但是往往每天变化的数据只是这个 base 数据的一小部分。

这种情况启发我们希望用一种流式计算方式逐步的替换掉 Maprediuce 的方式。

一方面能够提升我们实效性和效率，来降低大家使用 Maprediuce 当中遇到的问题。

但是常规的流式计算存在一些问题，第一，流式计算系统往往注重的是低延迟。

但是我们发现在海量的数据的条件下，其实对于搜索引擎来说，低延迟要求往往没有那么高。

另外中间的数据不容易持久化。

如果大家用过 MTI，或者这种迭代计算的计算模型，这种计算模型往往由很多轮迭代计算组成，每一轮中间数据不容易持久化，如果不持久化，任何一个任务失败，整个过程又要重新执行。

所以我们就考虑能不能改善传统的流式计算，提出一种新的流式计算来去规避它的缺点？

基于Tera的实时搜索

于是我们发现了一篇论文，也是启发我们去思考有没有一个更适合于搜索引擎增量的流式计算系统满足我们需求？

我们发现要想实现大规模的增量的流式计算系统，我们需要一个非常强大的分布式存储系统。

分布式存储系统我们需要提供 PB 级的数据的随机读写能力，需要支持高速吞吐，当然对延迟要求没有那么高，还要求提供ACID事物能力。

搜索引擎存在两类计算：

一种是以网页为中心的计算。

这个计算的过程不需要和其他的网页做交互，只需要自己和自己计算，这是一种方式。

常规的流式计算系统处理这种计算比较容易。

第二种计算需要网页和网页之间的计算，像索引筛选，在索引筛选过程中，比如说我们以筛选出十亿个需要建库的网页，当抓取系统新抓取一个网页后，就要剔除其中一个网页，这样的话才能保持数据很好的一致性。

搜索引擎有这样数据访问特点：

给定站点获取该站点下所有网页数据。

网页去重的时候读取相同内容签名集合的网页。

所以这样的访问特点让我们去研发我们的大规模的表格系统 Tera。

Tera 有什么特点？

首先它是一个大型的分布式表格系统，线上部署了几千台服务器，可以支持高吞吐，可以伸缩，半结构化序列存储，可以非常方便做扩展存储。

这就是 Tera 的基础架构。

Tera都实现了哪些核心技术？

•Tera 是全局有序；

•提供实时读写和数据扫描的能力；

•行式存储和列式存储相混合；

•要在设计和实现过程中对分布式文件系统友好；

•通过SIDCache热数据；

•支持一些常规的压缩算法，在实现的过程中大量采用了异步IO和分组提交；

•实现秒级分裂合并，基于这个更好实现负载均衡的算法；

•支持行级的事务；

Tera在Bigtable上同时可以搜索。

Tera是XX搜索系统批量系统转向实时计算的架构基础

Tera为我们提供了流式数据处理能力，可以实时读写，提供更快速的生效。

Tera还提供了海量数据存储的能力。

研发上也更为容易，因为中间数据是可见的，没有中间数据，这样大家Debug更容易。

总结和思考

流式计算是我们一个大的趋势。

新型硬件会发挥更强大的力量。

Tera之所以能够提供这么高的实时读写能力，因为我们硬件的提升。

之前恐怕是软件推动硬件，现在是硬件推动软件的发展。

其实Tera本身或者说Bigtable论文，Google从06年就提出了，但是真正的实践这样的一套系统其实需要非常强的工程能力，同时需要在真实场景中磨炼，比如做负载均衡，比如故障自愈，比如根据实际场景遇到的读写热点做性能优化这样的工作。

其实大量工作都来自于线上的生产环境。