08-谷歌文件系统GFS

第8章谷歌文件系统(GFS)Google思路Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。不要小看那些便宜、不牢靠的PC级服务器，一台服务器也许确实不牢靠，但是45万台的有机集成却成为了全球最完善、最稳定的系统之一。Google需要：-跨数据中心的高可靠性-成千上万的网络节点的伸缩性-大读写带宽的需求-支持大块的数据，可能为上千兆字节-高效的跨节点操作分发来减少瓶颈Google数字在2006年大约有450,000台廉价服务器，这个数量到2010年增加到了1,000,000台。在2005年Google索引了80亿Web页面，现在没有人知道具体数目，近千亿并不断增长中。目前在Google有超过500个GFS集群。一个集群可以有1000或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量可以达到每秒40兆字节。目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序。BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择。Google服务器猜想不论何时，不论何地，也不论你搜索多么冷门的词汇，只要你的电脑连接互联网，只要你轻轻点击“google搜索”，那么这一切相关内容google都会在1秒钟之内全部搞定，这甚至比你查询“我的文档”都要快捷。这也就是为什么Google创业12年，市值超过2000亿美元的原因。有人可能认为Google拥有几台“蓝色基因”那样的超级计算机来处理各种数据和搜索，事实是怎样的呢？Google服务器猜想截止到2010年，Google大约有100万台服务器，有超过500个计算机集群，处理不同地域的不同任务。这45万台服务器都不是什么昂贵的服务器，而是非常普通的PC级别服务器，其中的服务器硬盘在两年前还普遍是IDE接口、并且采用PC级主板而非昂贵的服务器专用主板。Google的存储呢？Google存储着海量的资讯，近千亿个网页、数百亿张图片。早在2004年，Google的存储容量就已经达到了5PB。Google没有使用任何磁盘阵列，哪怕是低端的磁盘阵列也没用。Google的方法是将集群中的每一台PC级服务器，配备两个普通IDE硬盘来存储。这样的一个以PC级别服务器搭建起来的系统，怎么能承受巨大的工作负载呢？怎么能保证高可用性呢？Google的云计算应用均依赖于四个基础组件分布式文件存储，GFS并行数据处理模型MapReduce分布式锁Chubby结构化数据表BigTableGoogle云计算应用MapReduceBigTableGFSChubby组件调用关系分析Google云计算应用BigTableGFSMapReduceChubbyChubby的作用为GFS提供锁服务，选择Master节点；记录Master的相关描述信息通过独占锁记录ChunkServer的活跃情况为BigTable提供锁服务，记录子表元信息（如子表文件信息、子表分配信息、子表服务器信息）（可能）记录MapReduce的任务信息为第三方提供锁服务与文件存储GFS的作用存储BigTable的子表文件为第三方应用提供大尺寸文件存储功能文件读操作流程API与Master通信，获取文件元信息根据指定的读取位置和读取长度，API发起并发操作，分别从若干ChunkServer上读取数据API组装所得数据，返回结果BigTable的作用为Google云计算应用（或第三方应用）提供数据结构化存储功能类似于数据库为应用提供简单数据查询功能（不支持联合查询）为MapReduce提供数据源或数据结果存储MapReduce的作用对BigTable中的数据进行并行计算处理（如统计、归类等）使用BigTable或GFS存储计算结果Google的平台--GFSGFS/MapReduce/BigTable/这三个平台，是Google最引以为傲的平台，全部架构在Linux之上。GFS（GoogleFileSystem）Google文件系统，一般的数据中心检索时候需要用到数据库系统。但是Google的情况很特殊——Google拥有全球上百亿个Web文档，如果用常规数据库系统检索，那么检索速度就可想而知了。当Crawlers采集到许多新的Web后，Google将很多的Web都汇集到一个文件里进行存储管理，而且Google将Web文件压缩成Chunk块，进一步减少占用空间(64MB一个chunk)。最后，Google只检索压缩后的部分。GFS(GoogleFileSystem）正是在这样的检索技术上构建的文件系统，GFS包括了GFSMaster服务器和Chunk服务器。Google运用GFS大大简化了检索的难度。总结：Google独特的一个面向大规模数据密集型应用的、可伸缩的分布式文件系统，由于这个文件系统是通过软件调度来实现的，所以Google可以把GFS部署在很多廉价的PC机上，来达到用昂贵服务器一样的效果。Google的平台--MapReduceGoogle拥有不少于45万台服务器，看起来每台服务器的职能都非常明确，但是其中却有重要的协同问题有待解决：如何并发计算，如何分布数据，如何处理失败，如何负载均衡？MapReduce是Google开发的C++编程工具，用于大规模数据集的并行运算。MapReduce主要功能是提供了一个简单强大的接口，可以将计算自动的并发和分布执行。MapReduce主要从两方面提升了系统：首先是失效的计算机问题。如果某一台计算机失效了，或者是I/O出现了问题——这在Google以廉价服务器组建的集群中极为常见，MapReduce的解决方法是用多个计算机同时计算一个任务，一旦一台计算机有了结果，其它计算机就停止该任务，而进入下一任务。其次，在MapReduce之间传输的数据都是经过压缩的，节省了很多带宽资源。BigTable，这是一个用来处理大数据量的系统，适合处理半结构化的数据。MotivationGoogleneededagooddistributedfilesystem首先，组件失效不再被认为是意外，而是被看做正常的现象。Redundantstorageofmassiveamountsofdataoncheapandunreliablecomputers“Modest”numberofHUGEfiles其次，按照传统的标准来看，Google的文件非常巨大。Eachis100MBorlarger;multi-GBfilestypicalFilesarewrite-once,mostlyappendedto第三，在Google大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新数据。AssumptionsHighcomponentfailurerates(这个系统由许多廉价易损的普通组件组成)InexpensivecommoditycomponentsfailoftenLargestreamingreads(大规模的流式读取和小规模随机读取)Highsustainedthroughputfavoredoverlowlatency(高度可用的带宽比低延迟更加重要)文件以数据块的形式存储数据块大小固定，每个数据块拥有句柄。利用副本技术保证可靠性每个数据块至少在3个块服务器上存储副本。每个数据块作为本地文件存储在Linux文件系统中。主服务器维护所有文件系统的元数据每个GFS簇只有一个主服务器。利用周期性的心跳信息更新服务器GFS的设计思想Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那部分。Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦被Master服务器指明，客户端程序就会直接从Chunk服务器读取文件。GFS的设计思想缓存无论是客户端还是Chunk服务器都不需要缓存文件数据。客户端缓存数据几乎没有什么用处，因为大部分程序要么以流的方式读取一个巨大文件，要么工作集太大根本无法被缓存。无需考虑缓存相关的问题也简化了客户端和整个系统的设计和实现。（不过，客户端会缓存元数据。）Chunk服务器不需要缓存文件数据的原因是，Chunk以本地文件的方式保存，Linux操作系统的文件系统缓存会把经常访问的数据缓存在内存中。GFS的体系结构如图所示，系统的流程从GFS客户端开始：GFS客户端以chunk偏移量制作目录索引并且发送请求——GFSMaster收到请求通过chunk映射表映射反馈客户端——客户端有了chunkhandle和chunk位置，并将文件名和chunk的目录索引缓存，向chunk服务器发送请求——chunk服务器回复请求传输chunk数据。GFS的体系结构什么是主服务器？在独立的主机上运行的一个进程存储的元数据信息：文件命名空间文件到数据块的映射信息数据块的位置信息访问控制信息数据块版本号GFS的体系结构文件数据块：64MB的大数据块优点：减少master上保存的元数据的规模，使得可以将metadata（元数据）放在内存中。Client在一个给定块上很可能执行多个操作，和一个块服务器保持较长时间的TCP连接可以减少网络负载。在client中缓存更多的块位置信息。缺点：一个文件可能只包含一个块，如果很多client访问该文件，存储块的块服务器可能会成为访问热点。GFS的体系结构块位置信息Master并不为块服务器的所有块的副本保存一个不变的记录。Master在启动时或者在有新的client加入这个簇时通过简单的查询获取这些信息。Master可以保持这些信息的更新，因为它控制所有块的放置并通过心跳消息（heartbeat）来监控。GFS的体系结构内存数据结构master的操作很快，所以master可以轻易而且高效地定期在后台扫描它的整个状态。块垃圾收集。为平衡负载和磁盘空间而进行的块迁移。块服务器出现故障时的副本复制。整个系统的容量受限于master的内存，64KB/64MB。如果一个块大小采用64KB，元数据量将增加1000倍。若要支持更大的文件系统，那么增加一些内存的方法对于我们将元数据保存在内存中所获得的简单性、可靠性、高性能和灵活性来说，只是一个很小的代价。GFS的体系结构主服务器和块服务器之间的通信定期地获取状态信息块服务器是否关闭？块服务器上是否有硬盘损坏？是否有副本出错？块服务维护哪些块的副本？主服务器发送命令给块服务器：删除已存在的块。创建新的块。GFS的体系结构操作日志操作日志包含了对metadata（元数据）所作的修改的历史记录，被复制在多个远程块服务器上。它可以从本地磁盘装入最近的检查点来恢复状态。它作为逻辑时间基线定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。Master可以用操作日志来恢复它的文件系统的状态。GFS的体系结构服务请求：Client从主服务器检索元数据（metadata）。在client和主服务器之间读/写数据流。单个主服务器并不会成为瓶颈，因为它在读/写操作中的工作量很小。Google是通过减少client与主服务器的交互来解决的，client均是直接与chunkserver通信，主服务器仅仅提供查询数据块所在的chunkserver以及详细位置。GFS的读操作GFS的读操作计算数据块位置信息：（假设：文件位置在201,359,161字节处）块大小=64MB64MB=1024*1024*64bytes=67,108,864bytes201,359