搜索引擎体系架构

阿里内外---阿里内部协作平台及其技术架构揭秘众所周知，阿里人拼劲足，能始终保持高效且充满温度、坚守价值观的工作动力，但很少人知道，秘诀之一就在于阿里内部人人都会用的协作平台——阿里内外。

在阿里内外上，员工不仅能进行工作协同，个体的创造性也能被激活。

经过四年发展，许多创新的想法、产品从阿里内外走出，而阿里内外也从0做到如今近百万PV。

究竟阿里内外是如何带来组织生命力?背后又有哪些核心技术?通过阿里内外产品及其技术架构的首次揭秘，给你答案。

阿里人每日必逛的神奇内网阿里内外是阿里内部员工使用的企业运行与协作平台。

它诞生于2013年，彼时只是一个门户和企业社交的入口。

但经过3年发展，阿里内外实现了平台化运营，不仅接入众多阿里应用与系统，阿里的生态公司也开始享受阿里内外提供的一体化服务。

今年，阿里内外开始向3.0智能模式发展，通过互联网数据和算法技术，增加诸如企业搜索、企业推荐、智能工作辅助，通过智能模式提高员工协同办公效率。

(阿里内外界面)阿里有一句老话：一个人可以走得很快，但是一群人可以走得很远。

在阿里，组织文化与工作协同是最重要的两大核心生态，作为服务内部员工的协作平台，文化和协同也是阿里内外不可或缺的核心元素。

在组织文化方面，阿里内外上有一个非常具有阿里特色的版块——阿里味。

阿里高管和员工都愿意在阿里味上分享自己的点子和想法，甚至是组织上的一些问题也可以畅所欲言，大大激活了员工的想象力。

此外，通过阿里学习、内外直播等版块，一些技术大牛和产品大牛也会经常把好的经验分享给内部员工，帮助大家一起更好成长。

当然，在交流之后，员工最终还是需要聚焦于自己的工作本身。

在工作协同方面，阿里内外还为员工提供了众多办公协同产品，如答疑、任务跟踪、周报笔记、文档、团队协作等。

员工可以通过一站式搜索快速定位产品，将所有工作内容形成沉淀，大大提升工作效率。

最关键的是，所有数据沉淀后，员工在一年内的工作成果会自然而然地在平台上有所体现，赋予组织更多生命力。

介绍Hadoop分布式文件系统（HDFS）是一种旨在在商品硬件上运行的分布式文件系统。

它与现有的分布式文件系统有许多相似之处。

但是，与其他分布式文件系统的区别很明显。

HDFS具有高度的容错能力，旨在部署在低成本硬件上。

HDFS提供对应用程序数据的高吞吐量访问，并且适用于具有大数据集的应用程序。

HDFS放宽了一些POSIX要求，以实现对文件系统数据的流式访问。

HDFS最初是作为Apache Nutch Web搜索引擎项目的基础结构而构建的。

HDFS是Apache Hadoop Core项目的一部分。

项目URL是/。

NameNode和DataNodesHDFS具有主/从体系结构。

HDFS群集由单个NameNode和管理文件系统名称空间并控制客户端对文件的访问的主服务器组成。

此外，还有许多数据节点，通常是集群中每个节点一个，用于管理与它们所运行的节点相连的存储。

HDFS公开了文件系统名称空间，并允许用户数据存储在文件中。

在内部，文件被分成一个或多个块，这些块存储在一组DataNode中。

NameNode执行文件系统名称空间操作，例如打开，关闭和重命名文件和目录。

它还确定块到DataNode的映射。

数据节点负责处理来自文件系统客户端的读写请求。

DataNode还根据NameNode的指令执行块创建，删除和复制。

NameNode和DataNode是为在普通机器上运行而设计的软件。

这些机器通常运行GNU/Linux操作系统(OS)。

HDFS是使用Java语言构建的;任何支持Java的机器都可以运行NameNode或DataNode软件。

使用高度可移植的Java语言意味着HDFS可以部署在各种机器上。

一个典型的部署有一个专用的机器，它只运行NameNode软件。

集群中的其他每台机器都运行DataNode软件的一个实例。

该体系结构不排除在同一台机器上运行多个datanode，但在实际部署中很少会出现这种情况。

集群中单个NameNode的存在极大地简化了系统的体系结构。

HDFS简介作为Hadoop的核心技术之一，HDFS（Hadoop distributed File System，Hadoop分布式文件系统）是分布式计算中数据存储管理的基础。

它所具有的高容错高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（Large Data Set）的应用处理带来了很多便利。

HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。

HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。

HDFS 是Apache Hadoop Core项目的一部分。

前提和设计目标硬件错误硬件错误是常态而不是异常。

HDFS可能由成百上千的服务器所构成，每个服务器上存储着文件系统的部分数据。

我们面对的现实是构成系统的组件数目是巨大的，而且任一组件都有可能失效，这意味着总是有一部分HDFS的组件是不工作的。

因此错误检测和快速、自动的恢复是HDFS最核心的架构目标。

流式数据访问HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。

比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。

POSIX标准设置的很多硬性约束对HDFS应用系统不是必需的。

为了提高数据的吞吐量，在一些关键方面对POSIX的语义做了一些修改。

大规模数据集HDFS上的一个典型文件大小一般都在G字节至T字节。

因此，HDFS被调节以支持大文件存储。

它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。

一个单一的HDFS实例应该能支撑数以千万计的文件。

简单的一致性模型HDFS应用需要一个“一次写入多次读取”的文件访问模型。

一个文件经过创建、写入和关闭之后就不需要改变。

这一假设简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。

Map/Reduce应用或者网络爬虫应用都非常适合这个模型。

“移动计算比移动数据更划算”一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。

H X-2055信息检索系统方案目录一项目意义随着互联网的快速发展，每天有数千万条信息生成，包括文字信息、图片信息、视频信息、语音信息等，通过百度、谷歌等大型商业搜索引擎可以找到自己想要的信息，但是也存在很多弊端。

百度、谷歌等大型商业搜索引擎的搜索原理是基于网络爬虫（Spider）在世界各地百万台服务器上爬取网页数据，然后存储到数据库之后展现给查询用户，随着网站数量以及网络上信息更新的快速化，这些网络爬虫不能保证把所有的信息都抓到，尤其是特殊行业的行业信息，即便是抓到了也不一定能够在众多数据中展现出来。

所以，对于一个部门来讲，有必要存在一款互联网信息检索系统来检索某一个行业的信息，每天自动在各大行业网站、政府网站等数据库中检索最新信息，通过自建的网络爬虫进行目标数据的抓取、存贮、归类、展现。

通过自己的信息检索系统，可以让自己部门每天轻松地获得世界各地、各个部门都发生了什么，有哪些新的政策，方便管理层在最新的信息数据下快速做出正确的决定。

据统计，内部网上的信息每年以200%的速度增长，其中发布到互联网上的信息只占到信息量的1%-2%，而98%以上的信息是发布在内部网上的。

内部网上的信息既有网页形式的，也包含其他Word、PDF、XML等多种格式的数据。

因此，面对内部网中海量异构的信息资源，如何帮助用户快速找到他们所需要的信息是一个主要的技术挑战。

搜索引擎能帮助用户方便、快捷、安全地获取内部网上的信息，在满足高效的同时，更重要的是保证了较高的查全率和查准率，能提供智能化的概念扩展搜索，极大的提高工作效率。

内部网搜索引擎将组织中分散管理的信息整合在一起，在组织层面上实现新的增值与共享，从而有效实现组织内容利用的最优目标。

搜索引擎的目标是实现内部网全文检索。

系统可对实施了内部网站资源进行爬行，无论内部网上的数据源在何地、以何种形式存在，都能够对其快速地访问，通过准确的分词建立索引，从而实现高质量的搜索查询。

简述搜索引擎结构及分类摘要：网络中的资源非常丰富，但是如何有效的搜索信息却是一件困难的事情。

建立搜索引擎就是解决这个问题的最好方法。

这篇论文就是简单介绍一下基于英特网的搜索引擎的系统结构以及我们常见的搜索引擎分类引言面对浩瀚的网络资源，搜索引擎为所有网上冲浪的用户提供了一个入口，毫不夸张的说，所有的用户都可以从搜索出发到达自己想去的网上任何一个地方。

因此它也成为除了电子邮件以外最多人使用的网上服务。

搜索引擎技术伴随着WWW的发展是引人注目的。

搜索引擎大约经历了三代的更新发展：第一代搜索引擎出现于1994年。

这类搜索引擎一般都索引少于1，000，000个网页，极少重新搜集网页并去刷新索引。

而且其检索速度非常慢，一般都要等待10秒甚至更长的时间。

在实现技术上也基本沿用较为成熟的IR（Information Retrieval）、网络、数据库等技术，相当于利用一些已有技术实现的一个WWW上的应用。

在1994年3月到4月，网络爬虫World Web Worm (WWWW)平均每天承受大约1500次查询。

大约在1996年出现的第二代搜索引擎系统大多采用分布式方案（多个微型计算机协同工作）来提高数据规模、响应速度和用户数量，它们一般都保持一个大约50，000，000网页的索引数据库，每天能够响应10，000，000次用户检索请求。

1997年11月，当时最先进的几个搜索引擎号称能建立从2，000，000到100，000，000的网页索引。

Altavista搜索引擎声称他们每天大概要承受20，000，000次查询。

2000年搜索引擎2000年大会上，按照Google公司总裁Larry Page的演讲，Google正在用3,000台运行Linux系统的个人电脑在搜集Web上的网页，而且以每天30台的速度向这个微机集群里添加电脑，以保持与网络的发展相同步。

每台微机运行多个爬虫程序搜集网页的峰值速度是每秒100个网页，平均速度是每秒48.5个网页，一天可以搜集超过4，000，000网页搜索引擎一词在国内外因特网领域被广泛使用，然而他的含义却不尽相同。

计算机世界/2006年/6月/12日/第B12版技术专题搜索引擎是一种依靠技术取胜的产品,搜索引擎的各个组成部分,包括页面搜集器、索引器、检索器等,都是搜索引擎产品提供商进行比拼的着力点。

搜索引擎的工作机制章森王伟近几年，搜索引擎的商业化取得了巨大的成功，如著名搜索引擎公司Google、Yahoo（本文中提到Yahoo时，特指英文Yahoo）、百度等纷纷成功上市，引发了众多公司涉足于该领域，带动了人力、资本的大量投入，连软件巨人Microsoft公司也禁不住诱惑积极打造自己的搜索引擎。

但是，从性能上来说，目前的搜索引擎还不尽如人意，搜索返回的结果往往与用户的检索要求相去甚远，有效性还不是很高。

本文将对搜索引擎的工作原理及其实现技术进行分析，从中可以了解限制搜索引擎用户体验改善的因素到底有哪些。

搜索引擎的工作过程大型互联网搜索引擎的数据中心一般运行数千台甚至数十万台计算机，而且每天向计算机集群里添加数十台机器，以保持与网络发展的同步。

搜集机器自动搜集网页信息，平均速度每秒数十个网页，检索机器则提供容错的可缩放的体系架构以应对每天数千万甚至数亿的用户查询请求。

企业搜索引擎可根据不同的应用规模，从单台计算机到计算机集群都可以进行部署。

搜索引擎一般的工作过程是: 首先对互联网上的网页进行搜集，然后对搜集来的网页进行预处理，建立网页索引库，实时响应用户的查询请求，并对查找到的结果按某种规则进行排序后返回给用户。

搜索引擎的重要功能是能够对互联网上的文本信息提供全文检索。

搜索引擎通过客户端程序接收来自用户的检索请求，现在最常见的客户端程序就是浏览器，实际上它也可以是一个用户开发的简单得多的网络应用程序。

用户输入的检索请求一般是关键词或者是用逻辑符号连接的多个关键词，搜索服务器根据系统关键词字典，把搜索关键词转化为wordID，然后在标引库（倒排文件）中得到docID列表，对docID列表中的对象进行扫描并与wordID进行匹配，提取满足条件的网页，然后计算网页和关键词的相关度，并根据相关度的数值将前K篇结果(不同的搜索引擎每页的搜索结果数不同)返回给用户，其处理流程如图1所示。

项目1 Hadoop基础知识1.Hadoop是由哪个项目发展来的？答：2002年，开源组织Apache成立开源搜索引擎项目Nutch，但在Nutch开发过程中，始终无法有效地将计算任务分配到多台计算机上。

2004年前后，Google陆续发表三大论文GFS、MapReduce和BigTable。

于是Apache在其Nutch里借鉴了GFS和MapReduce思想，实现了Nutch版的NDFS和MapReduce。

但Nutch项目侧重搜索，而NDFS和MapReduce则更像是分布式基础架构，因此，2006年，开发人员将NDFS和MapReduce移出Nutch，形成独立项目，称为Hadoop。

2.Hadoop主要有哪些版本？答：目前Hadoop的发行版除了Apache的开源版本之外，还有华为发行版、Intel发行版、Cloudera发行版(CDH)、Hortonworks发行版（HDP）、MapR等，所有这些发行版均是基于Apache Hadoop衍生出来的。

Apache Hadoop版本分为两代，第一代Hadoop称为Hadoop 1.0，第二代Hadoop称为Hadoop 2.0。

第一代Hadoop包含三个大版本，分别是0.20.x，0.21.x和0.22.x，其中，0.20.x 最后演化成1.0.x，变成了稳定版，而0.21.x和0.22.x增加了NameNode HA等新的重大特性。

第二代Hadoop包含两个版本，分别是0.23.x和2.x，它们完全不同于Hadoop 1.0，是一套全新的架构，均包含HDFS Federation和YARN两个系统，相比于0.23.x，2.x增加了NameNodeHA和Wire-compatibility两个重大特性。

3.简要描述Hadoop的体系结构，分析1.x与2.x版本间的区别。

答：Hadoop 2.x相比Hadoop 1.x最大的变化是增加了YARN组件，YARN是一个资源管理和任务调度的框架，主要包含三大模块：ResourceManager（RM）、NodeManager（NM）和ApplicationMaster（AM）。

Tera在百亿级实时搜索架构中的应用⻬齐志宏2017.05自我介绍 齐志宏 • 现任百度网页搜索基础架构&调研架构团队技术经理 • 08-12年供职腾讯 • 12年10月加入百度，从事搜索架构相关工作 • 调研架构 • 基础技术架构 内容 • 搜索引擎架构 • Tera在实时搜索架构中的应用  • 链接存储 • 索引筛选 • 用户行为分析 Web连接人与信息 连接人与服务 搜索引擎 抓取  (Spider)  索引构建 检索系统 Web 连接人与信息 连接人与服务 搜索引擎 Spider 索引构建 检索系统 抓取 解析  网页库  链接库 调度中心  链接提取  挖掘回灌  调度  属性计算 Web 连接人与信息 连接人与服务 搜索引擎 Spider 索  引  构  建 检索系统 抓取 解析  网页库  链接库 调度中心  链接提取  挖掘回灌  调度  属性计算  倒排计算  正排计算  索引筛选 页面特征获取  页面价值计算  重复度  计算  索引价值排序 Web 连接人与信息 连接人与服务 搜索引擎 Spider 索  引  构  建 检  索  系  统  抓取 解析  网页库  链接库 调度中心  链接提取  挖掘回灌  调度  属性计算  倒排计算  正排计算  索引筛选 页面特征获取  页面价值计算  重复度  计算  索引价值排序  展现层  归并服务  索引  服务  query 分析 关于Tera • 什么是Tera – 大型分布式表格存储系统 – 高性能、可伸缩的结构化存储 – 用来管理搜索引擎万亿量级的超链与网页信息  • 应用规模 – 链接存储：10PB+，万亿次/天 – 索引筛选：20PB+，万亿次/天 – 用户行为分析：1PB+，百亿次/天 内容 • 搜索引擎架构 • Tera在实时搜索架构中的应用  • 链接存储 • 索引筛选 • 用户行为分析 Tera应用——链接存储 • 什么是链接存储 – 位于Spider架构中 – 即链接库，以URL为KEY，存储了所有已抓取和待抓取的链接  – 用于持续抓取 • 互联网爆发式的增长趋势 2008 2009 2010 2011 2012 2013 2014 2015 2016收录量 百度网页收录量 • Spider架构演进中的链接存储 Spider  1.0  链接存储  多机分环架构 链接入库：分环merge  Spider  2.0  链接存储 MapReduce架构 链接入库：批量merge Spider  3.0  链接存储 BigTable架构（基于Tera） 链接入库：实时读写 • Spider架构的演进 Web  链接提取  网页库 抓取 调度  入库 链接库 • Spider架构的演进：Spider  1.0 – 多机分环 抓取 链接  提取 链接库 调度  入库 Cirlce  0 ……分发 网页库 抓取 链接  提取  链接库 调度 入库 Cirlce  N 分发 网页库 …………• Spider架构的演进：Spider  2.0 – 基于HDFS+MR的Hadoop架构 抓取 页面解析 调度  入链接库  链接提取 分发 url队列  时间筛选 链接库  分布式存储     H DFS 网页库 • Hadoop架构下的问题 – 效率 • 1个链接从发现到选出  ->3天？ • 多轮MR带来的长尾效应 – 资源浪费 • 重复计算：不必要的全量计算，导致计算资源浪费  – 开发成本 • MR程序调试困难，不易追查 调度 抓取 页面解析 页面价值  计算 页面类型  计算  更新预测 挖掘回灌 • Spider架构的演进 – Spider  3.0 – 基于Tera的实时架构 Tera  (链接库)  (网页库) • Spider3.0实时架构的优势 – 数据容量 • 链接数量：千亿  ->  万亿，总容量达到百PB – 访问性能 • 亿级QPS，每天访问万亿次 – 数据实时更新 • 链接实时入库，从抓取到入库的时延大幅缩减  – 策略实时生效 • 每秒亿级的随机读写  =>  批量策略转为实时策略  – 数据实时统计 • 全局有序，支持区间访问  =>实时统计各站点的链接数据 内容 • 搜索引擎架构 • Tera在实时搜索架构中的应用  • 链接存储 • 索引筛选 • 用户行为分析 • 索引筛选在搜索引擎中的位置  Tera应用——实时索引筛选 索引构建  I. 索引筛选  II. 正排计算 III. 倒排计算 Web搜索引擎 Spider 索  引  构  建 抓取 解析 网页库 链接库 调度中心 属性计算 质量打分 回灌调度 链接发现  倒排计算 正排计算 索引筛选 页面特征获取 页面价值计算 重复度  计算 索引价值排序 检  索  系  统 展现层  归并服务 索引  服务 query 分析 • 实时索引筛选在搜索架构中的作用和效果 – 网页筛选 • 作用：去除低质网页、去除重复网页 • 效果：影响索引的收录效果 – 索引分层 • 作用：索引价值排序 • 效果：影响搜索结果的展现效果 • 批量索引筛选的架构  索引  筛选  (MR)  特征获取 页面价值 网页去重 索引排序 索引库分类 索引库库层 输入 网页数据 网页属性 输出 • 批量索引筛选的架构的问题 – 索引时新性 • 网页收录量增大  =>  单个网页的check频次间隔被拉长 • 索引容量增长  =>  索引更新速度慢 – 索引有效性 • 实时索引构建，要求实时索引筛选 • 实时索引筛选的架构  分布式文件系统  D FS Tera 流式  计算 特征拼接 页面价值 网页去重 索引排序 观察者  Scan  驱动实时计算 网页库  去重库  结果库 • 实时索引筛选的价值 – 索引时新性 • 单个网页从抓取到筛选完成，从天级别降低到分钟、秒级 • 为缩短索引库更新周期，提供前提条件 – 索引有效性 • 实时全局筛选加大去重力度 • 对uniq资源的精准识别，等同于扩大索引量 内容 • 搜索引擎架构 • Tera在实时搜索架构中的应用  • 链接存储 • 索引筛选 • 用户行为分析 • 用户行为分析在搜索引擎中的作用  – 对搜索效果的改进 • 索引筛选策略 • 用户搜索意图分析 • 时效性事件的识别 • 排序算法的优化 – 对搜索引擎的评价 • 评价指标、评价体系的建立 • 辅助产品及策略的迭代 – 判断功能、效果好坏 – 选择较优方案 – 挖掘优化点 – 核心：用户行为数据 • 用户行为数据流架构（批量） 日志  计算  (MR ) 日志解析 反作弊计算 Session 计算 日  志  合  并 输出 日志  HDFS 点击  展现  用户行为  日志  HDFS • 批量模式下的效率问题 – 日志延迟：  • 小时级日志延迟：n小时 • 天级日志延迟：近半天 – 业务影响 • 用户行为对搜索效果的反馈太慢 • 评估结论的产出需要2-3天 – Day  1上线=》Day  2完整的数据=》Day  3产出结论  – 效率决定了整体迭代速度 • 用户行为数据流架构（实时） Tera 实时数据计算 导入 & 清洗 (ETL) 迭代计算 数据 导出  反作弊日志 点击 展现 …… 日志合并Session触发计算 Tera应用——实时用户行为分析  • 效果 – 日志产出速度 • 实时日志：秒级 • 小时级日志：1小时 • 天级日志：2小时 Tera对实时搜索架构的价值 • 效率 – 实时读写，极大的提升了搜索引擎的实时处理能力 • 资源 – 批量计算转变为单条的实时计算，避免了不必要的全量计算  • 开发成本 – 中间数据直接可见，相比MR任务，Debug成本大幅下降   T era是百度搜索从批量处理迈向实时计算的架构基础 h0ps:///baidu/tera t era_dev@。