1 / 54

Google 云计算原理

Cloud Computing. Google 云计算原理. 电子工业出版社 刘鹏主编 《 云计算 》 教材配套课件 4. 主要内容( 6 学时). Google 的云计算. 课程回顾. 分布式文件系统 GFS. GFS 的容错措施有哪些?. GFS 的容错方法. GFS 的容错机制 Chunk Server 容错 每个 Chunk 有多个存储副本(通常是 3 个),分别存储于不通的服务器上

Télécharger la présentation

Google 云计算原理

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Cloud Computing Google云计算原理 电子工业出版社 刘鹏主编《云计算》教材配套课件4

  2. 主要内容(6学时)

  3. Google的云计算 课程回顾

  4. 分布式文件系统GFS GFS的容错措施有哪些?

  5. GFS的容错方法 • GFS的容错机制 • Chunk Server容错 • 每个Chunk有多个存储副本(通常是3个),分别存储于不通的服务器上 • 每个Chunk又划分为若干Block(64KB),每个Block对应一个32bit的校验码,保证数据正确(若某个Block错误,则转移至其他Chunk副本) • Master容错(影子节点热备) • 三类元数据:命名空间(目录结构)、Chunk与文件名的映射以及Chunk副本的位置信息 • 前两类通过日志提供容错,Chunk副本信息存储于Chunk Server,Master出现故障时可恢复

  6. 并行数据处理模型MapReduce 1、处理流程 2、分片方式

  7. 问题讨论 • MapReduce处理流程中各类文件的存储位置在哪里? • MapReduce的容错方法? • MapReduce的处理优化方法? • MapReduce仅能对GFS之上的文件进行处理吗?

  8. 灵活的MapReduce • 所有步骤均可控,可灵活处理各类分布式问题

  9. 云计算应用实践作业调整 • 除了排序,新增两道题目 • 使用MapReduce实现倒排索引 • 输入:100个文本文档 • 输出:倒排索引 • 任务 • 实现算法,给出数据结构描述、执行过程描述等 • 作业要求同“排序” • 要求尽可能提高执行效率,节约网络IO带宽

  10. 云计算应用实践作业调整 • 除了排序,新增两道题目 • 使用MapReduce实现快速查询 • 查询目标是存储在BigTable之中的网页数据,给定关键字,快速查询含有该内容的网页(假定没有倒排索引) • 要求 • 设计BigTable存储方式(表含有哪些列、无需关心数据如何取得) • 设计快速查询的MapReduce处理方法 • 作业要求同“排序”

  11. Google的云计算 分布式锁服务Chubby

  12. Chubby是什么? • 主要用于解决分布式一致性问题 • 在一个分布式系统中,有一组的Process,它们需要确定一个Value。于是每个Process都提出了一个Value,一致性就是指只有其中的一个Value能够被选中作为最后确定的值,并且当这个值被选出来以后,所有的Process都需要被通知到 • 粗粒度的分布式锁服务 • Chubby是Google为解决分布式一致性问题而设计的提供粗粒度锁服务的文件系统 • 其他分布式系统可以使用它对共享资源的访问进行同步

  13. Chubby的设计目标 • 需要实现的特性 • 高可用性 • 高可靠性 • 支持粗粒度的建议性锁服务 • 支持小规模文件直接存储 • 不作考虑的特性 • 高性能 • 存储能力

  14. Chubby的系统架构

  15. 文件系统中文件的权限 文件系统中文件操作的权限有哪些? 这些权限之间的互斥关系是怎样的?

  16. Chubby文件系统 • Chubby系统本质上就是一个分布式的、存储大量小文件的文件系统 • Chubby中的锁就是文件 • 在GFS的例子中,创建文件就是进行“加锁”操作,创建文件成功的那个server其实就是抢占到了“锁” • 用户通过打开、关闭和存取文件,获取共享锁或者独占锁;并且通过通信机制,向用户发送更新信息

  17. Client与Chubby的通信协议

  18. Chubby的应用 • 主节点选举 • 独占锁 • 共享锁 • 数据存取应用 • 获取GFS ChunkServer信息 • 元数据存储 • ……

  19. Goolge的云计算 分布式数据表BigTable

  20. BigTable • 为什么需要设计BigTable? • Google需要存储的数据种类繁多 • 网页,地图数据,邮件…… • 如何使用统一的方式存储各类数据? • 海量的服务请求 • 如何快速地从海量信息中寻找需要的数据? • BigTable:基于GFS和Chubby的分布式存储系统 • 对数据进行结构化存储和管理 • 与GFS的联系

  21. Google的需求 • 数据存储可靠性 • 高速数据检索与读取 • 存储海量的记录(若干TB) • 可以保存记录的多个版本

  22. 假设 • 与写操作相比,数据记录读操作占绝大多数工作负载 • 单个节点故障损坏是常见的 • 磁盘是廉价的 • 可以不提供标准接口 • Google既能控制数据库设计,又能进行应用系统设计

  23. 设计目标 • 具有广泛的适应性 • 支持Google系列产品的存储需求 • 具有很强的可扩展性 • 根据需要随时加入或撤销服务器 • 应对不断增多的访问请求 • 高可用性 • 单个节点易损,但要确保几乎所有的情况下系统都可用 • 简单性 • 简单的底层系统可减少系统出错概率,为上层开发带来便利

  24. 逻辑视图 • 总体上,与关系数据库中的表类似 关系数据库中的表是什么样的?有什么特征? 关系数据库中的表设计需要遵循什么原则?

  25. 数据模型 • 行 • 每行数据有一个可排序的关键字和任意列项 • 字符串、整数、二进制串甚至可串行化的结构都可以作为行键 • 表按照行键的“逐字节排序”顺序对行进行有序化处理 • 表内数据非常‘稀疏’,不同的行的列的数完全目可以大不相同 • URL是较为常见的行键,存储时需要倒排 • 统一地址域的网页连续存储,便于查找、分析和压缩 mp3.baidu.com/index.asp→com.baidu.mp3/index.asp

  26. 数据模型 • 列 • 特定含义的数据的集合,如图片、链接等 • 可将多个列归并为一组,称为族(family) • 采用 族:限定词 的语法规则进行定义 • fileattr:owning_group”, “fileattr:owning_user”, etc • 同一个族的数据被压缩在一起保存 • 族是必须的,是BigTable中访问控制的基本单元

  27. 数据模型 • 时间戳 • 保存不同时期的数据,如“网页快照” • “A big table” • 表中的列可以不受限制地增长 • 表中的数据几乎可以无限地增加 通过(row, col, timestamp)查询 通过(row, col, MOST_RECENT)查询

  28. 数据模型 • 无数据校验 • 每行都可存储任意数目的列 • BigTable不对列的最少数目进行约束 • 任意类型的数据均可存储 • BigTable将所有数据均看作为字符串 • 数据的有效性校验由构建于其上的应用系统完成 • 一致性 • 针对同一行的多个操作可以分组合并 • 不支持对多行进行修改的操作符

  29. 物理视图

  30. 物理视图 • 逻辑上的“表”被划分为若干子表(Tablet) • 每个Tablet由多个SSTable文件组成 • SSTable文件存储在GFS之上 • 每个子表存储了table的一部分行 • 元数据:起始行键、终止行键 • 如果子表体积超过了阈值(如200M),则进行分割

  31. 体系结构

  32. 主节点的职责 • 为每个子表服务器分配子表,对外提供服务 • 与GFS垃圾回收进行交互,收回废弃的SSTable • 探测子表服务器的故障与恢复 • 负载均衡 有效缓解单点故障

  33. 子表服务器故障

  34. 子表服务器故障

  35. 子表服务器故障

  36. 数据访问方式

  37. 数据写的流程 • 任何对子表的写操作都会记录到一个存储在GFS之上的commit log中 • 每个子表服务器上所有子表变化对应于一个commit log • 新的数据存储到子表服务器的内存(memtable)中 • 次压缩 • 旧数据存储在SSTable中,而新数据存放在memtable中 • 当memtable体积超过一定阈值,将形成SSTable,并写入GFS • 每个tablet对应多个SSTable

  38. 合并压缩 • tablet含有多个SSTable导致查询效率低 • 合并压缩操作读取多个SSTable,创建一个新的SSTable来保持其中的最新数据 • 旧的SSTable删除 • 如果合并压缩操作完成后,tablet只包含一个SSTable,那么该操作也称为主压缩

  39. 数据存储与读取流程

  40. 子表服务器故障恢复 • 新的故障 • 子表服务器内存中的memtable丢失 • 恢复方法 • 按照tablet将该服务器对应的日志分片 • 为每个失效tablet分配新的子表服务器 • 新子表服务器读取对应的分段commit log,并按照日志修改tablet • 删除commitlog中已实施的内容 • 重新对外提供服务

  41. 性能优化 • 局部性群组(Locality Group) • 根据需要,将原本不存储在一起的数据,以列族为单位存储至单独的子表 • 如用户对网站排名、语言等分析信息感兴趣,那么可以将这些列族放至单独的子表,减少无用信息读取,改善存取效率 • 布隆过滤器(Bloom Filter) • 什么是布隆过滤器?判断某个元素是否隶属于集合 • 优点:误判概率低,其存储空间仅为Hash表的1/8至1/4 • 用于判断列键是否位于SSTable中,快速确定某个列键的位置

  42. BigTable小结

  43. 综合讨论 • Google云计算架构中GFS、MapReduce和BigTable中是否存在集群节点复用的情况? • 如何复用? • 节点复用的好处有哪些? • Google云计算架构的设计对你有哪些启发?有哪些收获?

  44. Goolge的云计算 Google App Engine

  45. 简介 • GoogleAppEngine是隶属于PaaS类型的云服务 • 一个计算环境,支持Python和Java语言 • 可使用Google的基础服务,如BigTable和GFS等 • 用户仅需提供应用代码,无需服务器维护 • 应用程序可根据访问量和数据存储需要的增长轻松进行扩展

  46. 应用程序环境 • 特性 • 动态网络服务功能,能够完全支持常用的网络技术 • 具有持久存储的空间,可支持查询、分类等基本操作 • 具有自主平衡网络和系统的负载、自动进行扩展的功能 • 可对用户的身份进行验证,并且支持使用Google账户发送邮件 • 具有一个功能完整的本地开发环境,开发人员可以在自身的计算机上模拟Google App Engine环境

  47. 应用程序环境 • 沙盒 • 一个虚拟环境 • 将开发者开发的应用程序隔离在自身的安全可靠的环境中,该环境和网络服务器的硬件、系统以及物理位置完全无关 • 仅提供开发人员对基础操作系统的有限访问权限 • 可以对开发人员进行更多的限制 • 只能通过网址抓取API和邮件服务API访问其他计算机 • 其他计算机只能通过HTTP或HTTPS与沙盒应用交互 • 应用程序无法对平台文件系统进行写入操作,只能读取代码文件 • 应用程序必须使用平台的Data Store来存储应用程序运行期间持续存在的数据 • …… 通过隔离来保证平台和其他开发者的安全

  48. 平台服务 • 图像操作API • 开发人员可通过该API对JPEG和PNG图像进行缩放、裁剪、旋转和翻转等操作 • 邮件API • 为开发人员开发的应用程序提供电子邮件发送服务 • Memcache API • 高性能的内存键值缓存,用户可使用应用程序访问该缓存 • 可提高应用程序的性能并减少数据库的负载 • 网址抓取API • 可以使用HTTP或HTTPS等网址来对数据进行检索

  49. 平台服务 • 用户API • 使应用程序与Google帐号集成,支持Google帐号身份认证 • 数据库API • 为用户提供查询引擎和事务存储服务

  50. Hello World print 'Content-Type: text/plain' print '' print 'Hello, world!'

More Related