Google云计算技术技术及应用

Google云计算技术主要内容•Google的“云”在哪里？•Google云计算应用场景•Google云计算的技术框架•Google云计算的关键技术Google的“云”在哪里？•云计算是一个新概念–于07年第3季度被提出，是并行计算、分布式计算和网格计算等技术的混合演进，–经过商业包装的概念•为分布式存储和分布式计算找到了盈利模式–提出以来发展迅速，Google、Amazon、Microsoft等公司都提出了自己的云计算方案•为什么Google需要“云”？–系统规模对系统设计的重要性–Google提供的服务：海量信息＋海量用户，如何又好又快地提供服务？Google的“云”在哪里？•Google的“云”无所不在–Google Earth、Gmail……–Google Docs，Google Wave……–云计算技术是Google大部分应用的基础设施–没有“云计算”，就没有Google的创新服务Google云计算应用场景•Google的云计算梦想–应用向互联网迁移–数据向互联网迁移–计算能力向互联网迁移–存储空间向互联网迁移“浏览器＝操作系统”Google ChromeGoogle云计算应用场景•Google云计算应用的分类–总体上，云计算可以分为IaaS、PaaS和SaaS三种类型Google云计算应用场景•Google云计算应用的分类–目前，Google云计算应用可以归于SaaS和PaaS两类SaaS Google Docs Google MapsGmail Google Calendar Google Wave……PaaSGoogle App Engine——Google Docs•Google在线文档–创建在线的Word和Excel，支持主要的文档编辑功能——Google Docs•Google在线文档–在线创建演示文档（PPT），并支持在线演示——Google Docs•Google在线文档–支持实时协作（多人同时编辑）–使用丰富的在线模板，快速构建文档–支持移动设备访问和编辑–与其他产品集成，如Gmail等——Google Maps •Google提供的电子地图服务——Google Maps•Google提供的电子地图服务–提供全球详尽的矢量电子地图–不仅仅是地图•街景•地形•交通流量•卫星图片–不仅仅是地图•商业信息•导航–支持移动设备访问，对外提供服务——Gmail•Google提供的电子邮件服务–超大附件、海量存储空间——Google Calendar •Google提供的日程安排工具——Google Wave•Google的信息分享、协作、发布平台–一个创新和整合的平台–整合了Gmail、即时通讯、文字处理、在线协作（游戏）等功能——App Engine•隶属于PaaS的Google云计算–属于部署在云端的应用执行环境–支持Python和Java两种语言–通过SDK提供Google的各种服务，如图形、MAIL和数据存储等–用户可快速、廉价（可免费使用限定的流量和存储）地部署自己开发的应用（如创新的网站、游戏等）Google云计算应用场景•上述应用的特点–应用（功能实现）在云端–存储在云端–计算在云端Google云计算的技术架构•Google的云计算应用均依赖于四个基础组件–文件存储，Google File System，GFS–并行数据处理MapReduce–分布式锁Chubby–结构化数据表BigTableGoogle云计算应用MapReduce BigTableGFS Chubby——GFS•Google文件系统的假设与目标–硬件出错是正常而非异常•系统应当由大量廉价、易损的硬件组成•必须保持文件系统整体的可靠性–主要负载是流数据读写•主要用于程序处理批量数据，而非与用户的交互或随机读写•数据写主要是“追加写”，“插入写”非常少–需要存储大尺寸的文件•存储的文件尺寸可能是GB或TB量级，而且应当能支持存储成千上万的大尺寸文件——GFS•GFS的架构•如何存储大文件？•节点分为Client、Master和Chunk Server三类——GFS•GFS的架构–Master：管理节点，逻辑上唯一（物理上多个），保存系统元数据，负责整个文件系统的管理，是GFS的“大脑”——GFS•GFS的架构–Chunk Server：负责具体的存储工作•GFS可以包含多个Chunk Server，其数目决定了GFS的存储规模•GFS将文件分块存储，块大小默认为64M，每隔块均具有唯一索引号（index）——GFS•GFS的架构–GFS的访问流程——GFS•GFS的架构–访问流程实现了控制流和信息流的分离•Client与Master仅有控制流，使Master不成为瓶颈•Client与Chunk Server直接存储数据，实现高速的数据并发读取——GFS•GFS的架构的特点–采用中心服务器模式•可以方便地增加Chunk Server•Master掌握系统内所有Chunk Server的情况，方便进行负载均衡•不存在元数据的一致性问题–不缓冲数据•GFS的文件操作大部分是流式读写，不存在大量的重复读写，使用Cache对性能提高不大•Chunk Server上的数据存取使用本地文件系统，如果某个Chunk读取频繁，文件系统具有Cache•从可行性看，Cache与实际数据的一致性维护也极其复杂——GFS•GFS的架构的特点–在用户态下实现•直接利用Chunk Server的文件系统存取Chunk，实现简单•用户态应用调试较为简单，利于开发•用户态的GFS不会影响Chunk Server的稳定性–只提供专用的访问接口•降低GFS的实现复杂度——GFS•GFS的容错机制–Chunk Server容错•每个Chunk有多个存储副本（通常是3个），分别存储于不通的服务器上•每个Chunk又划分为若干Block（64KB），每个Block对应一个32bit的校验码，保证数据正确（若某个Block错误，则转移至其他Chunk副本）–Master容错•三类元数据：命名空间（目录结构）、Chunk与文件名的映射以及Chunk副本的位置信息•前两类通过日志提供容错，Chunk副本信息存储于ChunkServer，Master出现故障时可恢复——GFS•基于GFS的Google数据中心–节点廉价、易损坏，但整体可靠、稳定——MapReduce•MapReduce–Google提出的一个软件架构，是一种处理海量数据的并行编程模式–用于大规模数据集（通常大于1TB）的并行运算•MapReduce实现了Map和Reduce两个功能–Map把一个函数应用于集合中的所有成员，然后返回一个基于这个处理的结果集–Reduce对结果集进行分类和归纳–Map()和Reduce() 两个函数可能会并行运行，即使不是在同一的系统的同一时刻——MapReduce •业务处理流程——MapReduce•案例：单词记数问题(Word Count)–给定一个巨大的文本（如1TB），如何计算单词出现的数目？——MapReduce•使用MapReduce求解该问题–定义Map和Reduce函数——MapReduce•使用MapReduce求解该问题–Step 1: 自动对文本进行分割——MapReduce•使用MapReduce求解该问题–Step 2:在分割之后的每一对<key,value>进行用户定义的Map进行处理，再生成新的<key,value>对——MapReduce•使用MapReduce求解该问题–Step 3:对输出的结果集归拢、排序(系统自动完成）——MapReduce•使用MapReduce求解该问题–Step 4:通过Reduce操作生成最后结果——MapReduce•实践证明，MapReduce是出色的分布式计算模型–Google宣布，其对分布于1000台计算机上的1TB数据进行排序仅仅需要68s–对4000台计算机上的1PB数据进行排序处理仅需要6小时2分钟（每次测试至少会损坏1块硬盘）–在08年1月份，Google MapReduce平均每天的数据处理量是20PB，相当于美国国会图书馆当年5月份存档网络数据的240倍——Chubby•分布式一致性问题–在一个分布式系统中，有一组的Process，它们需要确定一个Value。

于是每个Process都提出了一个Value，一致性就是指只有其中的一个Value能够被选中作为最后确定的值，并且当这个值被选出来以后，所有的Process都需要被通知到——Chubby•Google云计算中的分布式一致性问题–例如，GFS在物理上往往包含多个Master，但需要在逻辑上确定唯一的Master。

如何确定？这是一个分布式一致性问题•Chubby是Google为解决分布式一致性问题而设计的提供粗粒度锁服务的文件系统——Chubby•Chubby是一个文件系统，如何提供“锁”服务？–Chubby中的锁就是文件–在GFS的例子中，创建文件就是进行“加锁”操作，创建文件成功的那个server其实就是抢占到了“锁”–用户通过打开、关闭和读取文件，获取共享锁或者独占锁；并且通过通信机制，向用户发送更新信息–因此，通过Chubby可以解决Google云计算中的分布式一致性问题——BigTable•为什么需要设计BigTable？–Google需要存储的数据种类繁多•网页，地图数据，邮件……•如何使用统一的方式存储各类数据？–海量的服务请求•如何快速地从海量信息中寻找需要的数据？•BigTable：基于GFS和Chubby的分布式存储系统–对数据进行结构化存储和管理–与GFS的区别——BigTable•BigTable的设计目标–具有广泛的适应性•支持Google系列产品的存储需求–具有很强的可扩展性•根据需要随时加入或撤销服务器–高可用性•尽管单个节点易损，但要确保几乎所有的情况下系统都可用–简单性•简单的底层系统可减少系统出错概率，为上层开发带来便利——BigTable•BigTable的数据模型–总体上，与关系数据库中的表类似——BigTable•BigTable的数据模型–行键•任意的字符串（小于64K），表中的数据按照行键进行排序•URL是较为常见的行键，存储时需要倒排–统一地址域的网页连续存储，便于查找、分析和压缩/index.asp→com.baidu.mp3/index.asp——BigTable•BigTable的数据模型–列键•列键采用列族:限定词的语法规则进行定义•如anchor:, anchor:my.look.ca•同一个族的数据被压缩在一起保存•族是必须的，是BigTable中访问控制的基本单元——BigTable•BigTable的数据模型–时间戳•保存不同时期的数据，如“网页快照”–与关系数据库的表不同•表中的列可以不受限制地增长•表中的数据几乎可以无限地增加——BigTable•BigTable的基本架构–BigTable数据模型所隐含的问题•海量的数据如何存储？•表结构巨大，如何快速查询BigTable中的数据？•如何应对海量的访问请求？分解！——BigTable•BigTable的基本架构Bigtable 主服务器Bigtable 客户端Bigtable 客户端程序库Bigtable 子表服务器Bigtable 子表服务器Bigtable 子表服务器处理数据处理数据处理数据Google WorkQueueGFS Chubby 执行Open()操作负责故障处理及监控保存子表数据及日志负责元数据存储及主服务器的选择执行元数据操作及负载平衡。