搜索引擎体系架构
- 格式:ppt
- 大小:1.52 MB
- 文档页数:101
阿里内外---阿里内部协作平台及其技术架构揭秘众所周知,阿里人拼劲足,能始终保持高效且充满温度、坚守价值观的工作动力,但很少人知道,秘诀之一就在于阿里内部人人都会用的协作平台——阿里内外。
在阿里内外上,员工不仅能进行工作协同,个体的创造性也能被激活。
经过四年发展,许多创新的想法、产品从阿里内外走出,而阿里内外也从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应用或者网络爬虫应用都非常适合这个模型。
“移动计算比移动数据更划算”一个应用请求的计算,离它操作的数据越近就越高效,在数据达到海量级别的时候更是如此。