Google背后的分布式计算架构策略

1、google是与众不同的。它的独特不仅仅表现于革新的思维和充满创意的应用 (比如那个大堂里的地球模型)，更在于其有别常规的it策略 加利福尼亚州山景城(mountain view)google公司(google，下称google)总部有一个43号大楼，该建筑的中央大屏幕上显示着一个与google地球(google earth)相仿的世界地图，一个转动的地球上不停地闪动着五颜六色的光点，恍如罗马宫廷的千万烛灯，每一次闪动标志着地球的这个角落一名google用 户发起了一次新的搜索。 这同时意味着google又一次满足了人们对未知信息的好

2、奇与渴望。 google是与众不同的。它的独特不仅仅表现于革新的思维和充满创意的应用 (比如那个大堂里的地球模型)，更在于其有别常规的it策略。从人们的常理来看，简单的硬件商品和免费软件是无法构建出一个帝国的，但是google做到 了。在性能调整后，google把它们变成一个无可比拟的分布式计算平台，该平台能够支持大规模的搜索和不断涌现的新兴应用。我们原本认为这些应用都是个 人消费级别的，但是google改变了这一切。现在商业世界也在使用它们，这就令这家搜索公司显得那么与众不同。 googleweb 服务背后的it架构对无数使用搜索引

3、擎的用户来说也许并不是非常重要，但它是google几百位致力于把全球信息组织起来，实现“随处可达，随时可用”目 标的工程师们的最核心工作。这就需要一个在覆盖范围和野心上都与google的商业愿景完全相符的it蓝图作为支撑。 google 的经理们一直对公司的it策略话题保持沉默，他们厌恶谈及特定的厂商或者产品，当被问到他们的服务器和数据中心时，他们总是闭口不谈。但与几位 google的it领导一起呆了一天后，我们最终得以揭示该公司的it是如何运作的，那可不仅仅是一个运行在无数服务器集群上的、表面看来非常简单的搜索 引擎。在其简单的外表下，蕴涵着

4、许多内部研发软件、定制硬件、人工智能，以及对性能的执着追求和打破常规的人力管理模式。 it理念方面，google对同行有一条建议：尽量避免那些人人都在使用的系统和软件，以自己的方式做事会更有独特的竞争优势。 “企业文化决定了你的做事方式。”道格拉斯"美林(douglas merrill)，这位google工程副总裁和事实上的首席信息官(cio) 指出，“到了我们这样的发展阶段，企业观念和文化非常与众不同，这也反过来鞭策我们必须要采用与众不同的方式来运行那些他人看来很常规的系统。” google 最大的it优势在于它能建造出既

5、富于性价比(并非廉价)又能承受极高负载的高性能系统。因此it顾问史蒂芬"阿诺德(stephen arnold)指出，google与竞争对手，如亚马逊网站(amazon)、电子港湾公司(ebay)、微软公司(microsoft，下称微软)和雅 虎公司 (yahoo，下称雅虎)等公司相比，具有更大的成本优势。google程序员的效率比其他web公司同行们高出50%100%，原因是google已 经开发出了一整套专用于支持大规模并行系统编程的定制软件库。据他估算，其他竞争公司可能要花上四倍的时间才能获得同等的效果。 打造服务器 g

6、oogle 究竟是怎样做到这点的呢?其中一个手段，美林认为，“是因为我们自己动手打造硬件。”google并不制造计算机系统，但它根据自己的参数定制硬件，然后 像mtv的节目“靓车打造”(pimp my ride)那样自己安装和调整硬件系统。开源程序经理克里斯"迪博纳(chris dibona)评论道：“我们很善于购买商业服务器，并且改造他们为我们所用，最后把性能压榨和发挥到极致，以致有时候他们热得像要融化了似的。” 这种亲手打造的方式，来源于google从车库诞生时与生俱来的节俭风格，更与google那超大型的系统规模息息相

7、关，良好的习惯一直延续至 今。据说 google在65个数据中心拥有20万45万台服务器这个数目会有偏差(取决于你如何定义服务器和由谁来做这项统计)。但是，不变的是持续上升的趋 势。 google不会去讨论这些资产，因为它认为保密也是一种竞争优势。事实上，google之所以喜欢开源软件也是因为它的私密性。“如果我们购 买了软件许可或代码许可，人们只要对号入座，就可以猜出google的it基础架构。”迪博纳分析说， “使用开源软件，就使我们多了一条把握自己命运的途径。” google喜欢规模化的服务器运行方式。当有成百上千台机

8、器时，定制服务器的优势也会成倍增加，效果也会更趋明显。google正在俄勒冈州 哥伦比亚河边的达勒斯市建造一个占地30亩的数据中心，在那儿它可以获得运算和降温需要的低价水力电力能源(参见边栏google数据中心自有一套)。 google以“单元”(cell)的形式组织这些运行 linux操作系统的服务器，迪博纳把这种形式比喻成互联网服务的“磁盘驱动器”(但别和一直谣传的google存储服务gdrive混淆了，“并没有 gdrive这回事。”一位google女发言人明确表示。)，公司的软件程序都驻扎在这些并不昂贵的电脑机箱里，由程序员决定它们的冗余工作量。

9、这种由 很多单元组成的文件系统代替了商业存储设备;迪博纳表示google这些单元设备更易于建造和维护，他还暗示他们能处理更大规模的数据。 google 不会漏过对任何技术细节的关注。多年来，公司的工程师就在研究微处理器的内部工作机制，随着google规模的持续壮大，必然会用到特别定制和调节过的芯 片。知名工程师路易斯"巴罗索(luiz barroso)去年在一篇发表在工业杂志上的论文中证实，近年来google的主要负荷都由单核设计的系统承担着。但许多服务器端的应用，如 google搜索索引服务，所需的并行计算在单核芯片的指令

10、级别上执行得并不好。 曾在数据设备公司(digital equipment)和康柏公司(compaq)当过芯片设计师的巴罗索认为，随着amd公司、英特尔公司(intel)、太阳计算机系统公司(sun)开始制造多核芯片，必将会出现越来越多芯片级别的并行计算。 google 也曾考虑过自己制造计算机芯片，但从业界潮流来看，这个冒险的举动似乎不是很必要。“微处理器的设计非常复杂而且成本昂贵，”运营高级副总裁乌尔斯"霍尔 茨勒(urs holzle)表示。google宁愿与芯片制造商合作，让他们去理解自己的应用并设计适合的芯片。这是

11、一种客户建议式的设计，其关注点在于总体吞吐量、 效能，以及耗电比，而不是看单线程的峰值性能。霍尔茨勒表示，“这也是最近多核cpu的设计潮流与未来方向。” 裁缝般地定制软件 为了能尽量压榨硬件性能，google开发了相当数量的定制软件。创新产品主要包括用于简化处理和创建大规模数据集的编程模型 mapreduce;用于存储和管理大规模数据的系统bigtable;分析分布式运算环境中大规模数据集的解释编程语言sawzall;用于数据密集型 应用的分布式文件系统的 “google文件系统”(google file syst

12、em);还有为处理分布式系统队列分组和任务调度的“google工作队列”(google workqueue)。 正是从sawzall这些工具里体现出google对计算效率的执著关注。并不是每家公司都能从底层去解决效率问题，但是对google来说， 为常规关系型数据库无法容纳的大规模数据集专门设计一种编程语言是完全合理的。即使其他编程工具可以解决问题，google的工程师们仍然会为了追求效率 而另外开发一套定制方案。google工程师认为，sawzall能与c+中的mapreduce相媲美，而且它更容易编写一些。 google 对效率的

13、关注使它不可能对标准linux内核感到满意;google会根据自己的需要运行修改过的内核版本。通过调整linux的底层性能，google 工程师们在提高了整体系统可靠性的基础上，还一并解决了数据损坏和数据瓶颈等一系列棘手问题。对内核的修改也使google的计算机集群系统因为通信效率 的提高而运行得更快。 当然，google偶尔也会出现系统故障，情况一旦发生，无数的用户就会受到影响了。三年前一次持续30分钟的系统故障使20%的搜索流量受到影响。 google 开发了自己的网站服务器却没有使用开源的apache服务器，尽管它在网站服务器的市场占有率

14、超过60%。迪博纳认为，google的网站服务器可以运行 在更多数量的主机上，对google站点上内容庞大又彼此互相依赖的应用程序来说，这种服务器的负载均衡能力远比apache的能力更高。同时，在用标准 公共网关接口(cgi)访问数据库动态网页方面，google服务器的编程难度要比 apache更高，但是最终运行速度却更快。“如果我们能够压榨出10%20%的性能，我们就可以节省出更多系统资源、电量和人力了。”迪博纳在总结中 指出。 google还设计了自己的客户关系管理(crm)系统用于支持自己基于竞价和点击的互联网广告收费业务。但对是否需要设

15、计自己的工具，google的态度也不是一成不变的。比如在财会软件上，它就使用了甲骨文公司(oracle)的financials软件。 美林拿着一只叉子举例说明现成的产品也可以带来价值。但在有些场合现成的软件产品就不一定适用了。“我们的文化在各个层面对我们的运作都有深远影响，”他表示，“所以我们不想让购买所得的工具改变我们的工作方式和文化层面。” google's bigtable 原理 （翻译）     题记：google 的成功除了一个个出色的创意外，还因为有 je

16、ff dean 这样的软件架构天才。                                             &#

17、160;     - 编者 官方的 google reader blog 中有对bigtable 的解释。这是google 内部开发的一个用来处理大数据量的系统。这种系统适合处理半结构化的数据比如 rss 数据源。 以下发言  是 andrew hitchcock  在 2005 年10月18号 基于： google 的工程师&

18、#160;jeff dean 在华盛顿大学的一次谈话 (creative commons license). 首先，bigtable 从 2004 年初就开始研发了，到现在为止已经用了将近8个月。（2005年2月）目前大概有100个左右的服务使用bigtable，比如： print,search history,maps和 orkut。根据google的一贯做法，内部开发的bigtable是为跑在廉价的pc机上设计的。bigtable 让google在提供新服务时的

19、运行成本降低，最大限度地利用了计算能力。bigtable 是建立在 gfs ，scheduler ，lock service 和 mapreduce 之上的。 每个table都是一个多维的稀疏图 sparse map。table 由行和列组成，并且每个存储单元 cell 都有一个时间戳。在不同的时间对同一个存储单元cell有多份拷贝，这样就可以记录数据的变动情况。在他的例子中，行是urls ，列可以定义一个名字，比如：contents。conte

20、nts 字段就可以存储文件的数据。或者列名是：”language”，可以存储一个“en”的语言代码字符串。 为了管理巨大的table，把table根据行分割，这些分割后的数据统称为：tablets。每 个tablets大概有 100-200 mb，每个机器存储100个左右的 tablets。底层的架构是：gfs。由于gfs是一种分布式的文件系统，采用tablets的机制后，可以获得很好的负载均衡。比如：可以把经常响应 的表移动到其他空闲机器上，然后快速重建。 tablets在系统中的存储方式是不可修改的 

21、immutable 的sstables，一台机器一个日志文件。当系统的内存满后，系统会压缩一些tablets。由于jeff在论述这点的时候说的很快，所以我没有时间把听到的都记录下来，因此下面是一个大概的说明： 压缩分为：主要和次要的两部分。次要的压缩仅仅包括几个tablets，而主要的压缩时关于整个系统的压缩。主压缩有回收硬盘空间的功能。tablets的位置实际上是存储在几个特殊的bigtable的存储单元cell中。看起来这是一个三层的系统。 客户端有一个指向metao的tablets的指针。如果metao的tablets被频繁使用，那个这台机器就会放弃其他的t

22、ablets专门支持 metao这个tablets。metao tablets 保持着所有的meta1的tablets的记录。这些tablets中包含着查找tablets的实际位置。（老实说翻译到这里，我也不太明白。）在这个系统中不存在大的瓶颈，因为被频繁调用的数据已经被提前获得并进行了缓存。     现在我们返回到对列的说明：列是类似下面的形式： family:optional_qualifier。在他的例子中，行：www.search-  也许有列：”contents:其中包含ht

23、ml页面的代码。 “ anchor:    (翻译到这里我要插一句，以前我看过一个关于万能数据库的文章，当时很激动，就联系了作者，现在回想起来，或许google的 bigtable 才是更好的方案，切不说分布式的特性，就是这种建华的表结构就很有用处。)     注意这里说的是列信息，而不是列类型。列的信息是如下信息，一般是：属性/规则。 比如：保存n份数据的拷贝或者保存数据n天长等等。当 tablets 重新建立的时候，就运用上面的规则

24、，剔出不符合条件的记录。由于设计上的原因，列本身的创建是很容易的，但是跟列相关的功能确实非常复杂的，比如上文提到 的 类型和规则信息等。为了优化读取速度，列的功能被分割然后以组的方式存储在所建索引的机器上。这些被分割后的组作用于 列 ,然后被分割成不同的 sstables。这种方式可以提高系统的性能，因为小的，频繁读取的列可以被单独存储，和那些大的不经常访问的列隔离开来。 在一台机器上的所有的 tablets 共享一个log，在一个包含1亿的tablets的集群中，这将会导致非常多的文件被打开和写操作。新的log块

25、经常被创建，一般是64m大小，这个gfs的块大小相等。当一个机器down掉后，控制机器就会重新发布他的log块到其他机器上继续进行处理。这台机器重建tablets然后询问控制机器处理结构的存储位置，然后直接对重建后的数据进行处理。 这个系统中有很多冗余数据，因此在系统中大量使用了压缩技术。     dean 对压缩的部分说的很快，我没有完全记下来，所以我还是说个大概吧：压缩前先寻找相似的 行，列，和时间数据。     他们使用不同版本的： bmdiff&#

26、160;和 zippy 技术。    bmdiff 提供给他们非常快的写速度： 100mb/s  1000mb/s 。zippy 是和 lzw 类似的。zippy 并不像 lzw 或者 gzip 那样压缩比高，但是他处理速度非常快。     dean 还给了一个关于压缩 web 蜘蛛数据的例子。这个例子的蜘蛛 包含&#

27、160;2.1b 的页面，行按照以下的方式命名：“n.www/index.html:http”.在未压缩前的web page 页面大小是：45.1 tb ，压缩后的大小是：4.2 tb ， 只是原来的 9.2%。links 数据压缩到原来的 13.9% , 链接文本数据压缩到原来的 12.7%。 google 还有很多没有添加但是已经考虑的功能。     1.  数据

28、操作表达式，这样可以把脚本发送到客户端来提供修改数据的功能。     2. 多行数据的事物支持。     3.  提高大数据存储单元的效率。     4. bigtable 作为服务运行。     好像：每个服务比如： maps 和 search history 历史搜索记录都有他们自己的集群运行&

29、#160;bigtable。     他们还考虑运行一个全局的 bigtable 系统，但这需要比较公平的分割资源和计算时间。 大表(bigtable):结构化数据的分布存储系统 中是译者评论,程序除外 本文的翻译可能有不准确的地方,详细资料请参考原文. 摘要 bigtable是设计来分布存储大规模结构化数据的，从设计上它可以扩展到上50字节，分布存储在几千个普通服务器上google的很多项目使用 bt来存储数据，包括网页查询，google earth和g

30、oogle金融这些应用程序对bt的要求各不相同：数据大小（从url到网页到卫星图象）不同，反应速度不同（从后端的大批处理到实时数 据服务）对于不同的要求，bt都成功的提供了灵活高效的服务在本文中，我们将描述bt的数据模型这个数据模型让用户动态的控制数据的分布和结构我 们还将描述bt的设计和实现 介绍 在过去两年半里，我们设计，实现并部署了btbt是用来分布存储和管理结构化数据的bt的设计使它能够管理250 bytes(petabytes)数据，并可以部署到上千台机器上bt完成了以下目标：应用广泛，可扩展，高性能和高可用性（high a

31、vailability）. 包括google analytics, google finance, orkut, personalized search, writely和google earth在内的60多个项目都使用bt.这些应用对bt的要求各不相同，有的需要高吞吐量的批处理，有的需要快速反应给用户数据它们使用的bt集群也各不相同，有的只有几台机器，有的有上千台，能够存储240字节(terabytes)数据 bt在很多地方和数据库很类似：它使用了很多数据库的实现策略并行数据库14和内存数据库

32、13有可扩展性和高性能，但是bt的界面不同bt不支持完全的关系数据模型；而是为客户提供了简单的数据模型，让客户来动态控制数据的分布和格式就是只存储字串，格式由客户来解释，并允许客户推断底层存储数据的局部性以提高访问速度数据下标是行和列的名字，数据本身可以是任何字串bt的数据是字串，没有解释类型等客户会在把各种结构或者半结构化的数据串行化比如说日期串到数据中通过仔细选择数据表示，客户可以控制数据的局部化最后，可以使用bt模式来控制数据是放在内存里还是在硬盘上就是说用模式，你可以把数据放在离应用最近的地方毕竟程序在一个时间只用到一块数据在体系结构里，就是：locality, locali

33、ty, locality 第二节描述数据模型细节第三节关于客户api概述第四节简介bt依赖的google框架第五节描述bt的实现关键部分第6节叙述提高bt性 能的一些调整第7节提供bt性能的数据在第8节，我们提供bt的几个使用例子，第9节是经验教训在第10节，我们列出相关研究最后是我们的结论 数据模型 bt是一个稀疏的，长期存储的存在硬盘上，多维度的，排序的映射表这张表的索引是行关键字，列关键字和时间戳每个值是一个不解释的字符数组数据都是字符串，没类型，客户要解释就自力更生吧 (row:string, column:stri

34、ng,time:int64)->string 能编程序的都能读懂，不翻译了 我们仔细查看过好些类似bigtable的系统之后定下了这个数据模型。举一个具体例子（它促使我们做出某些设计决定）， 比如我们想要存储大量网页及相关信息，以用于很多不同的项目；我们姑且叫它webtable。在webtable里，我们将用url作为行关键字，用网页 的某些属性作为列名，把网页内容存在contents:列中并用获取该网页的时间戳作为标识，如图一所示。 图一：一个存储web网页的范例列表片断。行名是一个反向url即n.www。contents列族原文用&#

35、160;family，译为族，详见列族 存放网页内容，anchor列族存放引用该网页的锚链接文本。cnn的主页被sports illustrater即所谓si，cnn的王牌体育节目和my-look的主页引用，因此该行包含了名叫“anchor:”和 “anchhor:my.look.ca”的列。每个锚链接只有一个版本由时间戳标识，如t9，t8；而contents列则有三个版本，分别由时间 戳t3，t5，和t6标识。 行 表中的行关键字可以是任意字符串（目前支持最多64kb，多数情况下10100字节足够了）。在一个行关键字下的每一个读写操

36、作都是原子操作（不管读写这一行里多少个不同列），这是一个设计决定，这样在对同一行进行并发操作时，用户对于系统行为更容易理解和掌控。 bigtable通过行关键字的字典序来维护数据。一张表可以动态划分成多个连续行。连续行在这里叫做“子表”tablet，是数据分布和负载 均衡的单位。这样一来，读较少的连续行就比较有效率，通常只需要较少机器之间的通信即可。用户可以利用这个属性来选择行关键字，从而达到较好数据访问地域 性locality。举例来说，在webtable里，通过反转url中主机名的方式，可以把同一个域名下的网页组织成连续行。具体来说，可以把 列族&#

37、160;一组列关键字组成了“列族”，这是访问控制的基本单位。同一列族下存放的所有数据通常都是同一类型（同一列族下的数据可压缩在一起）。列族必须先创 建，然后在能在其中的列关键字下存放数据；列族创建后，族中任何一个列关键字均可使用。我们希望，一张表中的不同列族不能太多（最多几百个），并且列族在 运作中绝少改变。作为对比，一张表可以有无限列。 列关键字用如下语法命名：列族：限定词。 列族名必须是看得懂printable的字串，而限定词可以是任意字符串。比如，webtable可以有个列族叫language，存放撰写网页的语 言。我们在language

38、列族中只用一个列关键字，用来存放每个网页的语言标识符。该表的另一个有用的列族是anchor；给列族的每一个列关键字代表 一个锚链接，如图一所示。而这里的限定词则是引用该网页的站点名；表中一个表项存放的是链接文本。 访问控制，磁盘使用统计，内存使用统计，均可在列族这个层面进行。在webtable举例中，我们可以用这些控制来管理不同应用：有的应用添加新的基本数据，有的读取基本数据并创建引申的列族，有的则只能浏览数据（甚至可能因为隐私权原因不能浏览所有数据）。 时间戳 bigtable表中每一个表项都可以包含同一数据的多个版本，由时间戳来索引。bigtable

39、的时间戳是64位整型。可以由bigtable来 赋值，表示准确到毫秒的“实时”；或者由用户应用程序来赋值。需要避免冲突的应用程序必须自己产生具有唯一性的时间戳。不同版本的表项内容按时间戳倒序排 列，即最新的排在前面。 为了简化对于不同数据版本的数据的管理，我们对每一个列族支持两个设定，以便于bigtable对表项的版本自动进行垃圾清除。用户可以指明只保留表项的最后n个版本，或者只保留足够新的版本（比如，只保留最近7天的内容）。 在webtable举例中，我们在contents:列中存放确切爬行一个网页的时间戳。如上所述的垃圾清除机制可以让我们只保留每个网

40、页的最近三个版本。 3.api bt的api提供了建立和删除表和列族的函数还提供了函数来修改集群，表和列族的元数据，比如说访问权限 / open the table table *t = openordie(”/bigtable/web/webtable”); / write a new anchor and delete an old anchor rowmutation r

41、1(t, “n.www”); r1.set(”anchor:”, “cnn”); r1.delete(”anchor:”); operation op; apply(&op, &r1); 图 2: 写入bigtable. 在bt中，客户应用可以写或者删除值，从每个行中找值，或者遍历一个表中的数据子集图2的c+代码是使用rowmutation抽象表示来进行一系列的更新（为保证代码精简，没有包括无关的细节）调用apply函数，就对ebt

42、able进行了一个原子修改：它为scanner scanner(t); scanstream *stream; stream = scanner.fetchcolumnfamily(”anchor”); stream->setreturnallversions(); scanner.lookup(”n.www”); for (; !stream->done(); stream->next()  printf(”%s %s

43、0;%lld %sn”, scanner.rowname(), stream->columnname(), stream->microtimestamp(), stream->value();  图3: 从bigtable读数据. 图3的c+代码是使用scanner抽象来遍历一个行内的所有锚点客户可以遍历多个列族有很多方法可以限制一次扫描中产生的行，列和时间戳 例如，我们可以限制上面的扫描，让它只找到那些匹配正则表达式*的锚点，或者那些时间戳在当前时间前10天的锚点 

44、bt还支持其他一些更复杂的处理数据的功能首先，bt支持单行处理这个功能可以用来对存储在一个行关键字下的数据进行原子的读-修改-写操作 bt目前不支持跨行关键字的处理，但是它有一个界面，可以用来让客户进行批量的跨行关键字处理操作其次，bt允许把每个表项用做整数记数器最后，bt 支持在服务器的地址空间内执行客户端提供的脚本程序脚本程序的语言是google开发的sawzall28数据处理语言目前，我们基于的 sawzall的api还不允许客户脚本程序向bt内写数据，但是它允许多种形式的数据变换，基于任何表达式的过滤和通过多种操作符的摘要 bt可以和mapred

45、uce12一起使用mapreduce是google开发的大规模并行计算框架我们为编写了一套外层程序，使bt可以作为mapreduce处理的数据源头和输出结果 4.建立bt的基本单元 bt是建立在其他数个google框架单元上的bt使用google分布式文件系统(gfs)17来存储日志和数据文件yeah, right, what else can it use, fat32?一个bt集群通常在一个共享的机器池中工作，池中的机器还运行其他的分布式应用虽然机器便宜的跟白菜似的，可是一样要运行多个程序，命苦的象小

46、白菜，bt和其他程序共享机器bt的瓶颈是/内存，可以和cpu要求高的程序并存bt依赖集群管理系统来安排工作，在共享的机器上管理资源，处理失效机器并监视机器状态典型的server farm结构，bt是上面的应用之一 bt内部存储数据的格式是google sstable格式一个sstable提供一个从关键字到值的映射，关键字和值都可以是任意字符串映射是排序的，存储的不会因为掉电而丢失，不可改写的可以进行以下操作：查询和一个关键字相关的值；或者根据给出的关键字范围遍历所有的关键字和值在内部，每个sstable包含一列数据块（通常每个块的大小是64kb,但是大小是可以配置

47、的索引大小是16 bits，应该是比较好的一个数）块索引（存储在sstable的最后）用来定位数据块；当打开sstable的时候，索引被读入内存性能每次查找都可以用一个硬盘搜索完成根据索引算出数据在哪个道上，一个块应该不会跨两个道，没必要省那么点空间：首先在内存中的索引里进行二分查找找到数据块的位置，然后再从硬盘读去数据块最佳情况是：整个sstable可以被放在内存里，这样一来就不必访问硬盘了想的美，前面是谁口口声声说要跟别人共享机器来着？你把内存占满了别人上哪睡去？ bt还依赖一个高度可用的，存储的分布式数据锁服务chubby8看你怎么把这个high perfo

48、rmance给说圆喽一个chubby服务由5个活的备份机器构成，其中一个被这些备份选成主备份，并且处理请求这个服务只有在大多数备份都活着并且互相通信的时候才是活的绕口令？去看原文吧，是在有出错的前提下的冗余算法当有机器失效的时候，chubby使用paxos算法9,23来保证备份的一致性这个问题还是比较复杂的，建议去看引文了解一下问题本身chubby提供了一个名字空间，里面包括了目录和小文件万变不离其宗每个目录或者文件可以当成一个锁来用，读写文件操作都是原子化的chubby客户端的程序库提供了对chubby文件的一致性缓存究竟是提高性能还是降低性能？如果访问是分布的，就是提高性能每个chubby

49、客户维护一个和chubby服务的会话如果一个客户不能在一定时间内更新它的会话，这个会话就过期失效了还是针对大server farm里机器失效的频率设计的当一个会话失效时，其拥有的锁和打开的文件句柄都失效根本设计原则：失效时回到安全状态chubby客户可以在文件和目录上登记回调函数，以获得改变或者会话过期的通知翻到这里，有没有人闻到java的味道了？ bt使用chubby来做以下几个任务：保证任何时间最多只有一个活跃的主备份；来存储bt数据的启动位置（参考5.1节）；发现小表 （tablet）服务器，并完成tablet服务器消亡的善后（5.2节）；存储bt数据的模式

50、信息（每张表的列信息）；以及存储访问权限列表如果有相当长的时间chubby不能访问，bt就也不能访问了任何系统都有其弱点最近我们在使用11个chubby服务实例的14个bt集群中度量了这个效果，由于chubby不能访问而导致bt中部分数据不能访问的平均百分比是0.0047%,这里chubby不能访问的原因是chubby本身失效或者网络问题单个集群里，受影响最大的百分比是0.0326%基于文件系统的chubby还是很稳定的. gfs是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，但可以提供容错功能。它可以给大量的用户提供总体性能较

51、高的服务。 出处：1、设计概览 （1）设计想定 gfs与过去的分布式文件系统有很多相同的目标，但gfs的设计受到了当前及预期的应用方面的工作量及技术环境的驱动，这反映了它与早期的文件系统明显不同的设想。这就需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。 gfs与以往的文件系统的不同的观点如下： 1、部件错误不再被当作异常，而是将其作为常见的情况加以处理。因为文件系统由成百上千个用于存储的机器构成，而这 些机器是由廉价的普通部件组成并被大量的客户机访问。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法

52、恢复。所以实时地监控、错 误检测、容错、自动恢复对系统来说必不可少。 2、按照传统的标准，文件都非常大。长度达几个gb的文件是很平常的。每个文件通常包含很多应用对象。当经常要处理 快速增长的、包含数以万计的对象、长度达tb的数据集时，我们很难管理成千上万的kb规模的文件块，即使底层文件系统提供支持。因此，设计中操作的参数、 块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。 3、大部分文件的更新是通过添加 新数据完成的，而不是改变已存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦

53、写完，文件就只可读，很多数据都有这些特性。一些数据可能组成一 个大仓库以供数据分析程序扫描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据。 由于这些对大型文件的访问方式，添加操作成为性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。 4、工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中， 可能要读几百kb，通常达 1mb和更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的

54、偏移处读几个kb。性能敏感的应用程序通常将对少量 数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回回的读。 5、工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。 6、系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。 （2）系统接口 gfs提供了一个相似地文件系统界面，虽然它没有向posix那样实现标准的api。文件在目录中按层次组织起来并由路径名标识。 （3）体系结构

55、： 一个gfs集群由一个master和大量的chunkserver构成，并被许多客户（client）访问。如图1 所示。master和 chunkserver通常是运行用户层服务进程的linux机器。只要资源和可靠性允许，chunkserver和client可以运行在同一个机器 上。 文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunkhandle标识，chunk handle是在块创建时由 master分配的。chunkserver将块当作linux文件存储在本地磁盘并可以读和写由chunkhandle

56、和位区间指定的数据。出于可靠 性考虑，每一个块被复制到多个chunkserver上。默认情况下，保存3个副本，但这可以由用户指定。 master维护文件系统所以的元数据（metadata），包括名字空间、访问控制信息、从文件到块的映射以及块 的当前位置。它也控制系统范围的活动，如块租约（lease）管理，孤儿块的垃圾收集，chunkserver间的块迁移。master定期通过 heartbeat消息与每一个 chunkserver通信，给chunkserver传递指令并收集它的状态。 与每个应用相联的gfs客户代码实现了文件系统的ap

57、i并与master和chunkserver通信以代表应用程序读和写数据。客户与master的交换只限于对元数据（metadata）的操作，所有数据方面的通信都直接和chunkserver联系。 客户和chunkserver都不缓存文件数据。因为用户缓存的益处微乎其微，这是由于数据太多或工作集太大而无法 缓存。不缓存数据简化了客户程序和整个系统，因为不必考虑缓存的一致性问题。但用户缓存元数据（metadata）。chunkserver也不必缓存文 件，因为块时作为本地文件存储的。 （4）单master。 只有一个master也极大的简化了设计并使

58、得master可以根据全局情况作出先进的块放置和复制决定。但是我们 必须要将master对读和写的参与减至最少，这样它才不会成为系统的瓶颈。client从来不会从master读和写文件数据。client只是询问 master它应该和哪个 chunkserver联系。client在一段限定的时间内将这些信息缓存，在后续的操作中client直接和chunkserver交互。 以图1解释一下一个简单的读操作的交互。 1、client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引（chunk index）。 

59、2、给master发送一个包含文件名和块索引的请求。 3、master回应对应的chunk handle和副本的位置（多个副本）。 4、client以文件名和块索引为键缓存这些信息。（handle和副本的位置）。 5、client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunk handle（chunkserver以chunk handle标识chunk）和块内的一个字节区间。 6、除非缓存的信息不再有效（cache for a limited ti

60、me）或文件被重新打开，否则以后对同一个块的读操作不再需要client和master间的交互。 通常client可以在一个请求中询问多个chunk的地址，而master也可以很快回应这些请求。 （5）块规模： 块规模是设计中的一个关键参数。我们选择的是64mb，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的linux文件存储，在需要的时候可以扩展。 块规模较大的好处有： 1、减少client和master之间的交互。因为读写同一个块只是要在开始时向master请求块位置信息。对于读写大型文件这种减少尤为重要。即使对于访问少量数据

61、的随机读操作也可以很方便的为一个规模达几个tb的工作集缓缓存块位置信息。 2、client在一个给定的块上很可能执行多个操作，和一个chunkserver保持较长时间的tcp连接可以减少网络负载。 3、这减少了master上保存的元数据（metadata）的规模，从而使得可以将metadata放在内存中。这又会带来一些别的好处。 不利的一面： 一个小文件可能只包含一个块，如果很多client访问改文件的话，存储这些块的chunkserver将成为访问的热点。但在实际应用中，应用程序通常顺序地读包含多个块的文件，所以这不是一个主要问题。 （6）元

62、数据（metadata）： master存储了三中类型的metadata：文件的名字空间和块的名字空间，从文件到块的映射，块的副本的位 置。所有的metadata都放在内存中。前两种类型的metadata通过向操作日志登记修改而保持不变，操作日志存储在master的本地磁盘并在几 个远程机器上留有副本。使用日志使得我们可以很简单地、可靠地更新master的状态，即使在master崩溃的情况下也不会有不一致的问题。相反， mater在每次启动以及当有 chuankserver加入的时候询问每个chunkserver的所拥有的块的情况。 

63、a、内存数据结构： 因为metadata存储在内存中，所以master的操作很快。进一步，master可以轻易而且高效地定期在后台扫描它的整个状态。这种定期地扫描被用于实现块垃圾收集、chunkserver出现故障时的副本复制、为平衡负载和磁盘空间而进行的块迁移。 这种方法的一个潜在的问题就是块的数量也即整个系统的容量是否受限与master的内存。实际上，这并不是一个严重 的问题。master为每个 64mb的块维护的metadata不足64个字节。除了最后一块，文件所有的块都是满的。类似的，每个文件的名字空间数据也不足64个字节，因为文件名 

64、是以一种事先确定的压缩方式存储的.如果要支持更大的文件系统，那么增加一些内存的方法对于我们将元数据（metadata）保存在内存种所获得的简单 性、可靠性、高性能和灵活性来说，这只是一个很小的代价。 b、块位置： master并不为chunkserver所拥有的块的副本的保存一个不变的记录。它在启动时通过简单的查询来获得这些信息。master可以保持这些信息的更新，因为它控制所有块的放置并通过heartbeat消息来监控chunkserver的状态。 这样做的好处：因为chunkserver可能加入或离开集群、改变路径名、崩溃、重启等，一个集群重有成百个

65、server，这些事件经常发生，这种方法就排除了master与chunkserver之间的同步问题。 另一个原因是：只有chunkserver才能确定它自己到底有哪些块，由于错误，chunkserver中的一些块可能会很自然的消失，这样在master中就没有必要为此保存一个不变的记录。 c、操作日志： 操作日志包含了对metadata所作的修改的历史记录。它作为逻辑时间线定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。 操作日志是如此的重要，我们必须要将它可靠地保存起来，并且只有在metadata的改变

66、固定下来之后才将变化呈现给用户。所以我们将操作日志复制到数个远程的机器上，并且只有在将相应的日志记录写到本地和远程的磁盘上之后才回答用户的请求。 master可以用操作日志来恢复它的文件系统的状态。为了将启动时间减至最小，日志就必须要比较小。每当日志的长度增长到超过一定的规模后，master就要检查它的状态，它可以从本地磁盘装入最近的检查点来恢复状态。 创建一个检查点比较费时，master的内部状态是以一种在创建一个检查点时并不耽误即将到来的修改操作的方式来组 织的。master切换到一个新的日子文件并在一个单独的线程中创建检查点。这个新的检查点记录了切换前所有的修改。在一个有数十万文件的集群中用一分钟 左右就能完成。创建完后，将它写入本地和远程的磁盘。 （7）数据完整性 名字空间的修改必须是原子性的，它们只能有master处理：名字空间锁保证了操作的原子性和正确性，而master的操作日志在全局范围内定义了这些操作的顺序。 文 件区间的状态在修改之后依赖于修改的类型，不论操作成功