Google的体系架构.doc

Google的体系架构 Google的体系架构2010-10-23 13：39Google是可伸缩性之王。每个人都知道Google是因为他们对大量，复杂信息的快速搜索，但是Google的技术并不只是在搜索领域闪闪发光。他们构建大型应用的平台方式能够让他们以惊人的竞争速度在网络规模应用上面大展拳脚。Google的目标一直是构建更高性能更高规模基础设施来支持他们的产品。他们怎么做到的呢? 平台 Linux 多种不同的语言：Python,Java,C++ 数据揭秘 目前的情形： 2006年估计有450,000个价格便宜的商用服务器 2005年Google索引了80亿的web页面。到现在为止有多少，已经无法统计出来了。 目前Google有超过200GFS的集群。一个集群能有1000甚至5000个机器。成百上千的机器从运行大到5peta字节存储的GFS集群检索数据。通过集群的总的读写吞吐量达到每秒400亿字节。 目前在Google有6000个MapReduce应用，并且每个月有几百个新的应用正在出现。 架构的层次 Google把他们的基础设施架构描述为三个层次栈： 产品：检索，广告，电子邮件，地图，视频，聊天，博客 分布式系统基础设施：GFS,MapReduce,以及BigTable。 计算平台：很多不同数据中心的很多机器 确保公司员工容易低成本配置。 看看每个应用基线的价格性能数据。把更多的钱花在硬件上以期不丢失日志数据，但是在其他类型的数据上花少一点。既然这样处理，实际上他们就不会丢数据。 使用GFS(Google文件系统)的可靠存储机制 可靠的可伸缩存储是任何应用的一个核心需要。GFS就是他们的核心存储平台。 Google文件系统-大的分布式日志结构化文件系统，里面有大量数据 为什么不用其他的而非要构建一个文件系统呢?因为他们需要控制所有的事情，而正是这个平台把他们和其他任何一个区分开来。他们需要： -通过数据中心的高可靠性 -对于几千个网络节点的可伸缩性 -大的读写带宽需求 -支持十亿字节大的数据块 -高效的通过节点减少瓶颈的分布式操作 系统有主服务器和分块服务器(chunk servers) -主服务器在各种数据文件上保存元数据。数据以64MB大的块存储在文件系统中。客户机和主服务器对话来操作文件里的元数据，定位包含了磁盘上他们需要的数据的分块服务器。 一个新的应用可以使用一个已经存在的GFS集群或者他们自己制作。去理解他们使用的通过数据中心的这个供应过程将是非常有趣的。 主键是足够的基础设施来确保人们对他们的应用有多种选择。可以调整GFS以适应个人应用需要。 使用MapReduce对数据做一些事情 既然你有了一个好的存储系统，你怎样使用如此多的数据呢?假如说你有很多TB的数据存储在1000台机器上。数据库不能扩展或者有效地扩展到这样的规模。这时就要用到MapReduce了。 MapReduce是一个编程模型和用来处理和产生大规模数据集。用户指定一个映射函数处理一个键/值对来产生中间的键/值对集合，还指定一个缩小函数来合并所有的与同一中间键相关的中间值。 许多现实世界的任务在这个模型里被表示出来。用这个函数风格写的程序自动并行化并且在一大集群商务机器上执行。运行时系统关心分割输入数据的细节，通过一系列的机器安排程序的执行，处理机器事故，以及管理所需的机器内部通信。这使得没有任何并行和分布式系统经验的程序员能够容易地利用一个大的分布式系统的资源。 为什么使用MapReduce呢? -在大量机器上分割任务的极佳方式 -处理机器故障 -在不同类型的应用上工作，如搜索和广告。几乎每个应用都有映射简化类型之类的操作。你可以预计算有用的数据，统计字数，分类几TB的数据，等等。 -计算可以自动地更加靠近IO源。 MapReduce系统有三个不同类型的服务器。 -主服务器分配用户任务以映射和减少服务器。它也跟踪任务的状态。 -映射服务器接收用户输入，在它们上面实行映射操作。结果写入中间文件。 -化简服务器接收由映射服务器产生的中间文件并在它们上面实行化简操作。 例如，你想要统计所有网页中字符的个数。你可以把存储在GFS中的页面放入MapReduce。这些都将在1000秒内发生，包括机器同步和协调，任务安排，事故处理和数据传输将会自动完成。 -步骤如下：GFS-Map-Shuffle-Reduction-把结果存回GFS -在MapReduce里，一个映射把一个视图映射到另一个，产生一个键值对，在我们的例子里是单词和数量。 -Shuffling聚合键的类型 -化简把所有的键值对加起来产生最后的结果。 Google索引管道有大概20个不同的映射化简。一个管道把数据看做记录的一个整体束和聚合键。第二个映射-化简进来把那个结果拿走做其他的一些事情。