百度实时搜索技术的架构演变Word格式文档下载.docx

上传人:b****2 文档编号:5844054 上传时间:2023-05-05 格式:DOCX 页数:10 大小:567.62KB
下载 相关 举报
百度实时搜索技术的架构演变Word格式文档下载.docx_第1页
第1页 / 共10页
百度实时搜索技术的架构演变Word格式文档下载.docx_第2页
第2页 / 共10页
百度实时搜索技术的架构演变Word格式文档下载.docx_第3页
第3页 / 共10页
百度实时搜索技术的架构演变Word格式文档下载.docx_第4页
第4页 / 共10页
百度实时搜索技术的架构演变Word格式文档下载.docx_第5页
第5页 / 共10页
百度实时搜索技术的架构演变Word格式文档下载.docx_第6页
第6页 / 共10页
百度实时搜索技术的架构演变Word格式文档下载.docx_第7页
第7页 / 共10页
百度实时搜索技术的架构演变Word格式文档下载.docx_第8页
第8页 / 共10页
百度实时搜索技术的架构演变Word格式文档下载.docx_第9页
第9页 / 共10页
百度实时搜索技术的架构演变Word格式文档下载.docx_第10页
第10页 / 共10页
亲,该文档总共10页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

百度实时搜索技术的架构演变Word格式文档下载.docx

《百度实时搜索技术的架构演变Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《百度实时搜索技术的架构演变Word格式文档下载.docx(10页珍藏版)》请在冰点文库上搜索。

百度实时搜索技术的架构演变Word格式文档下载.docx

WEB 

平台链接人与信息,或者人与服务。

创造优质内容和用户体验

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

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

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

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

内容抓取

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

其实抓取主要分两大部分:

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

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

索引构建

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

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

检索系统

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

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

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

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

分布式表格系统Tera

XX面临的问题:

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

在没有 

Maprediuce 

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

但 

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

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

用 

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

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

这对 

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

所以不得不进行的全量计算就意味着我们在计算过程中有很多浪费,因为我们有一个非常大 

base 

的数据,但是往往每天变化的数据只是这个 

数据的一小部分。

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

的方式。

一方面能够提升我们实效性和效率,来降低大家使用 

当中遇到的问题。

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

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

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

如果大家用过 

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

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

基于Tera的实时搜索

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

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

分布式存储系统我们需要提供 

PB 

级的数据的随机读写能力,需要支持高速吞吐,当然对延迟要求没有那么高,还要求提供ACID事物能力。

搜索引擎存在两类计算:

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

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

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

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

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

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

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

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

Tera。

Tera 

有什么特点?

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

这就是 

的基础架构。

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

•Tera 

是全局有序;

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

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

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

•通过SIDCache热数据;

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

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

•支持行级的事务;

Tera在Bigtable上同时可以搜索。

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

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

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

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

总结和思考

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

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

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

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

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

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

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 解决方案 > 学习计划

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2