《大数据与云计算》课件-5.GOOGLE云计算

知识点GOOGLE云计算简介GOOGLE云计算简介3分布式锁服务Chubby21文件系统GFS分布式数据处理MapReduce54分布式结构化数据表Bigtable分布式存储系统MegaStore系统的节点分为三类Client(客户端)Client是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。应用程序直接调用这些库函数，并与该库连接在一起。Master(主服务器)Master是GFS的管理节点，在逻辑上只有一个，它保存系统的元数据，负责整个文件系统的管理，是GFS文件系统中的”大脑“。ChunkServer(数据块服务器)ChunkServer负责具体的存储工作。数据以文件的形式存储在ChunkServer上，ChunkServer的个数可以有多个，它的数目直接决定了GFS的规模。GFS将文件按照固定大小进行分块，默认为64MB,每一块称为一个Chunk(数据块)，每个Chunk都有一个对应的索引号（index）。系统架构文件系统GFS运行过程

Client在访问GFS时，首先访问Master节点，获取与之进行交互的ChunkServer信息，然后直接访问这些ChunkServer，完成数据存取工作。系统架构文件系统GFS实现了控制流和数据流的分离。

Client与Master之间只有控制流，而无数据流，极大地降低了Master的负载。Client与ChunkServer之间直接传输数据流，同时由于文件被分成多个Chunk进行分布式存储，Client可以同时访问多个ChunkServer，从而使得整个系统的I/O高度并行，系统整体性能得到提升。)采用中心服务器模式Master管理分布式文件系统中所有的元数据。文件被划分为Chunk进行存储，对于Master来说，每个ChunkServer只有一个存储空间。Client发起的所有操作都需要先通过Master才能执行。优点增加新的ChunkServer容易，ChunkServer只需要注册到Master上即可，ChunkServer之间无任何关系。如果采用完全对等的，无中心的模式，那么如何将ChunkServer的更新信息通知到每一个ChunkServer，会是一个设计难点，而且也将在一定程度上影像系统的扩展性Master维护了一个统一的命名空间，同时掌握整个系统内ChunkServer的情况，据此可以实现整个系统范围内数据存储的负载均衡由于只有一个中心服务器，元数据的一致性问题自然得到了解决缺点极易成为整个系统的瓶颈GFS采用多种机制来避免Master成为系统性能和可靠性上的瓶颈，如尽量控制元数据的规模、对Master进行远程备份、控制信息和系统分流等GFS的特点文件系统GFS不缓存数据缓存（Cache）机制是提升文件系统性能的一个重要手段，通用文件系统为了提高性能一般需要实现复杂的缓存机制。GFS文件系统根据应用的特点，没有实现缓存。Client发起的所有操作都需要先通过Master才能执行。无缓存原因客户端大部分是流式顺序读写，不存在大量的重复读写，缓存这部分数据的作用不大；对于ChunkServer，由于GFS在ChunkServer上以文件的形式存储，如果对某块数据读取频繁，本地的文件系统自然会将其缓存维护缓存与实际数据之间的一致性极其复杂，在GFS中各个ChunkServer的稳定性都无法确保，加之网络等多种不确定因素，一致性问题更为复杂；另外由于读取的数据量巨大，以当前的内存容量无法完全缓存Master有缓存Master需要频繁操作元数据，把元数据直接保存在内存中，提高了操作效率采用相应的压缩机制降低元数据占用空间的大小，提高内存的利用率GFS的特点文件系统GFS在用户态下实现文件系统作为操作系统的重要组成部分，其实现通常位于操作系统底层。以Linux为例，无论是本地文件系统如Ext3文件系统，还是分布式文件系统如Lustre等，都是在内核态实现的。在内核态实现文件系统，可以更好地和操作系统本身结合，向上提供兼容的POSIX接口。然而，GFS却选择在用户态下实现原因在用户态下实现，直接利用操作系统提供的POSIX编程接口就可以存取数据，无需了解操作系统的内在实现机制和接口，降低了实现的难度，提高了通用性。POSIX接口提供的功能更为丰富，在实现过程中可以利用更多的特性，而不像内核编程那样受限用户态下有多种调试工具，而在内核态中调试相对比较困难用户态下，Master和ChunkServer都以进程的方式运行，单个进程不会运行整个操作系统，从而可以对其进行充分优化。在内核态下，如果不能很好地掌握其特性，效率不但不会高，甚至还会影响到整个系统运行的稳定性用户态下，GFS和操作系统运行在不同的空间，两者耦合度降低，方便GFS自身和内核的单独升级GFS的特点文件系统GFS只提供专用接口通常的分布式文件系统一般都会提供一组与POSIX规范兼容的接口。其优点是应用程序可以通过操作系统的统一接口来透明地访问文件系统，而不需要重新编译程序。GFS在设计之初，是完全面向Google的应用的，采用了专用的文件系统访问接口。接口以库文件的形式提供，应用程序与库文件一起编译，Google应用程序在代码中通过调用这些库文件的API，完成对GFS文件系统的访问优点实现的难度：通常与POSIX兼容的接口需要在操作系统内核一级实现，而GFS是在应用层实现的专用接口可以根据应用的特点对应用提供一些特殊支持，如支持多个文件并发追加的接口等接口直接和Client、Master、ChunkServer交互，减少了操作系统之间上下文的切换，降低了复杂度，提高了效率GFS的特点文件系统GFS分而治之，是计算机处理问题的一个非常重要的思想，简称为分治法。分治法也就是将一个很复杂的且很难进行直接解决的大问题，分割成一堆规模较小的并且能直接简单求解的子问题，然后将这些子问题的结果进行合并就是原始问题的结果。问题规模较大或较复杂，且可以分解成多个规模较小的、简单的同类型问题进行求解。子问题之间相互独立，不包含公共子问题。子问题可以合并得到原问题的解。计算过程Map阶段

将大数据计算任务拆分为多个子任务，拆分后的子任务通常具有如下特征：相对于原始任务来说，划分后的子任务与原任务是同质的。Reduce阶段

第一阶段拆分的子任务计算完成后，汇总所有子任务的计算结果，以得到最终结果。抽象模型分布式数据处理MapReduce设计上具有以下主要的技术特征MapReduce集群的构建完全选用价格便宜易于扩展的低端商用服务器，而非价格昂贵、不易扩展的高端服务器对于大规模数据处理，由于有大量数据存储需要，显而易见，基于低端服务器的集群远比基于高端服务器的集群优越，这就是为什么MapReduce并行计算集群会基于低端服务器实现的原因向“外”横向扩展，而非向“上”纵向扩展MapReduce集群中使用大量的低端服务器，因此，节点硬件失效和软件出错是常态任何节点失效都不应当导致结果的不一致或不确定性；任何一个节点失效时，其他节点要能够无缝接管失效节点的计算任务；当失效节点恢复后应能自动无缝加入集群，而不需要管理员人工进行系统配置失效被认为是常态传统高性能计算系统通常有很多处理器节点与一些外存储器节点相连，如用存储区域网络（StorageArea，SANNetwork）连接的磁盘阵列，因此，大规模数据处理时外存文件数据I/O访问会成为一个制约系统性能的瓶颈。MapReduce采用了数据/代码互定位的技术方法，计算节点将首先尽量负责计算其本地存储的数据，以发挥数据本地化特点，仅当节点无法处理本地数据时，再采用就近原则寻找其他可用计算节点，并把数据传送到该可用计算节点。把处理向数据迁移分布式数据处理MapReduce设计上具有以下主要的技术特征大规模数据处理的特点决定了大量的数据记录难以全部存放在内存，而通常只能放在外存中进行处理。由于磁盘的顺序访问要远比随机访问快得多，因此MapReduce主要设计为面向顺序式大规模数据的磁盘访问处理MapReduce可以利用集群中的大量数据存储节点同时访问数据，以此利用分布集群中大量节点上的磁盘集合提供高带宽的数据访问和传输。顺序处理数据、避免随机访问数据MapReduce提供了一种抽象机制将程序员与系统层细节隔离开来，程序员仅需描述需要计算什么（Whattocompute），而具体怎么去计算（Howtocompute）就交由系统的执行框架处理隐藏系统层细节在集群规模上，要求算法的计算性能应能随着节点数的增加保持接近线性程度的增长。绝大多数现有的单机算法都达不到以上理想的要求对于很多计算问题，基于MapReduce的计算性能可随节点数目增长保持近似于线性的增长平滑无缝的可扩展性分布式数据处理MapReduceChubby是一种面向松耦合的分布式系统的锁服务，通常用于为一个由适度规模的大量小型计算机构成的松耦合的分布式系统提供高可用的分布式锁服务。锁服务的目的是允许它的客户端进程同步彼此的操作，并对当前所处环境的基本状态信息达成一致。01Chubby的主要设计目标是为一个由适度大规模的客户端进程组成的分布式场景提供高可用的锁服务，以及易于理解的API接口定义。而值得一提的是，在Chubby的设计过程中，系统的吞吐量和存储容量并不是首要考虑的因素02Chubby的客户端接口设计非常类似于文件系统结构，不仅能够对Chubby上的整个文件进行读写操作，还能够添加对文件节点的锁控制，并且能够订阅Chubby服务端发出的一系列文件变动的事件通知。03分布式锁服务ChubbyBigtable是一个为管理大规模结构化数据而设计的分布式存储系统，可以扩展到PB级数据和上千台服务器。很多google的项目使用Bigtable存储数据，这些应用对Bigtable提出了不同的挑战，比如数据规模的要求、延迟的要求。Bigtable能满足这些多变的要求，为这些产品成功地提供了灵活、高性能的存储解决方案。Bigtable看起来像一个数据库，采用了很多数据库的实现策略。但是Bigtable并不支持完整的关系型数据模型；而是为客户端提供了一种简单的数据模型，客户端可以动态地控制数据的布局和格式，并且利用底层数据存储的局部性特征。Bigtable将数据统统看成无意义的字节串，客户端需要将结构化和非结构化数据串行化再存入Bigtable。BigTable的数据模型Bigtable的键有三维，分别是行键（rowkey）、列键（columnkey）和时间戳（timestamp），行键和列键都是字节串，时间戳是64位整型；而值是一个字节串。可以用(row:string,column:string,time:int64)→string来表示一条键值对记录分布式结构化数据表Bigtable在线业务上云给存储带来的挑战高可扩展(highlyscalable)快速开发(rapiddevelopment)低延迟(lowlatency)数据的一致视图(consistentviewofthedata)高可用(highlyavailable)现状RDBMS扩展性差NoSQL开发困难（有限的API，松散一致性模型）Megastore融合RDBMS和NoSQL的优势。通过同步复制(synchronousreplication)达到高可用(highavailability)和数据的一致视图(consistentviewofthedata)。Megastore是Google设计的一种分布式存储系统。Megastore的设计目标很明确，那就是设计一种介于传统的关系型数据库和NoSQL之间的存储技术，尽可能达到高可用性和高可扩展性的统一不支持join查询性能更重要读多写少存储和查询分层很简单(BigTable)分布式存储系统MegaStore思考：GFS的运行过程是怎样的？GFS的特点？MapReduce的计算过程是怎样？什么是Chubby?什么是BigTable?知识点GOOGLE云计算

主要产品3内存大数据分析系统PowerDrill4Google应用程序引擎1大规模分布式系统的监控基础架构Dapper2海量数据交互式分析工具DremelGOOGLE云计算主要产品

当代的互联网的服务，通常都是用复杂的、大规模分布式集群来实现的。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具。大规模分布式系统的监控基础架构Dapper例子：

一个前端服务可能对上百台查询服务器发起了一个Web查询，每一个查询都有自己的Index。这个查询可能会被发送到多个的子系统，这些子系统分别用来处理广告、进行拼写检查或是查找一些像图片、视频或新闻这样的特殊结果。根据每个子系统的查询结果进行筛选，得到最终结果，最后汇总到页面上。我们把这种搜索模型称为“全局搜索”（universalsearch）。

这一次全局搜索有可能调用上千台服务器，涉及各种服务。而且，用户对搜索的耗时是很敏感的，而任何一个子系统的低效都导致导致最终的搜索耗时。如果一个工程师只能知道这个查询耗时不正常，但是他无从知晓这个问题到底是由哪个服务调用造成的，或者为什么这个调用性能差强人意。大规模分布式系统的监控基础架构Dapper

原因这个工程师可能无法准确的定位到这次全局搜索是调用了哪些服务，因为新的服务、乃至服务上的某个片段，都有可能在任何时间上过线或修改过，有可能是面向用户功能，也有可能是一些例如针对性能或安全认证方面的功能改进。不能苛求这个工程师对所有参与这次全局搜索的服务都了如指掌，每一个服务都有可能是由不同的团队开发或维护的。这些暴露出来的服务或服务器有可能同时还被其他客户端使用，所以这次全局搜索的性能问题甚至有可能是由其他应用造成的。大规模分布式系统的监控基础架构DapperDapper的设计要求无所不在的部署：在使用跟踪系统的进行监控时，即便只有一小部分没被监控到，那么人们对这个系统是不是值得信任都会产生巨大的质疑。持续的监控：监控应该是7x24小时的，毕竟，系统异常或是那些重要的系统行为有可能出现过一次，就很难甚至不太可能重现。大规模分布式系统的监控基础架构Dapper四个具体的设计目标低消耗：跟踪系统对在线服务的影响应该做到足够小。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。应用级的透明：对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了延展性：Google至少在未来几年的服务和集群的规模，监控系统都应该能完全把控住。分析速度快：理想情况是数据存入跟踪仓库后一分钟内就能统计出来。尽管跟踪系统对一小时前的旧数据进行统计也是相当有价值的，但如果跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况做出快速反应。大规模分布式系统的监控基础架构Dapper3秒分析1PB数据如果在一个PB级别的数据集上面，将任务缩短到秒级，无疑需要大量的并发，假设磁盘的顺序读速度在100MB/S上下，那么在1S内处理1TB数据，意味着至少需要有1万个磁盘的同时并发读操作。机器越多，出问题概率越大，强如MapReduce都会经常遇到慢节点的问题，而Sql查询引擎在如此大的集群规模中实现短时间计算操作，就需要有足够的容错考虑，保证整个分析的速度不被集群中的个别慢节点影响。

海量数据交互式分析工具Dremel海量数据交互式分析工具DremelDremel是MapReduce交互式查询能力不足的补充，和MapReduce一样，Dremel也需要和数据运行在一起，将计算移动到数据上面，所以它需要GFS这样的文件系统作为存储层。在设计之初，Dremel并非是MapReduce的替代品，它只是可以执行非常快的分析，在使用的时候，常常用它来处理MapReduce的结果集或者用来建立分析原型。Dremel中的数据是用列式存储的，在分析数据的时候，可以只扫描需要的那部分数据，减少CPU和磁盘的访问量。同时，列式存储是压缩友好的，可以综合CPU和磁盘的性能，在存储效率和查询效率上起到平衡的作用。设计思想借鉴了Web搜索中的“查询树”的概念，将一个相对巨大复杂的查询，分割成较小较简单的查询，实现大事化小、小事化了的分布式数据处理思想。和并行DBMS类似，Dremel可以提供了一个SQL-like的接口，就像Hive和Pig那样使用起来非常方便。海量数据交互式分析工具Dremel实时交互查询的问题用户对于实时的交互式数据查询和分析一直都有很高的要求，尤其是在一些数据探索的场景，完成一项任务之前需要先向系统发出请求，根据得到的结果来修正查询内容，并再次向系统发出新的查询，如此反复的过程可能要进行很多次。很显然MapReduce无法实现这种程度的交互式查询。Dremel可以在一定程度上实现实时的交互式查询，但是随着数据规模的增大和Google内部对adhoc查询（即席查询）需求的增多，因此Google设计和开发了新的交互式查询系统PowerDrill。两个假设绝大多数的查询是类似和一致的存储系统中的表只有一小部分是经常被使用的，绝大部分的表使用频率不高内存大数据分析系统PowerDrill设计目标如何尽可能在查询中略去不需要的数据分块如何尽可能地减少数据在内存中的占用，占用越少意味着越多的数据可以被加载进内存中处理Google从2008年开始使用PowerDrill，将其作