Transcript Google云计算原理
1 Google云计算背景 分布式文件系统GFS 并行数据处理模型MapReduce 分布式锁服务Chubby 分布式数据库BigTable Google AppEngine Google云计算技术小结 2 Google云计算的背景 3 4 Google和微软之间日益激烈的对立将是一场史诗 般的企业战争，将对两家公司的成功和发展产生重 要影响，并规定着消费者和企业如何工作、购物、 通讯，以及“他们过的数字生活” Google认为这一切将发生在遥远的数据中心中的 服务器，用户可以通过许多有线和无线设备访问这 些服务，这就是所谓的“云计算” 微软也认为未来在于Web，但它的重心仍然是其桌 面PC软件 5 90%计算任务都能够通过“云计算”技术 完成 桌面软件正在向Web软件转型 云计算是开放标准 ，业界不会有公司独裁 中小企业、大学、消费者会相对迅速地转 向基于Web的“云计算”技术 新的赢利模式 ◦ 低廉的云计算给Google带来更多的流量，进而 带来更多的广告收入 Google CEO 埃立克.施米特 承认“云计算”不会在一夜之间普及 ◦ 大公司通常会慢慢地改变自己的习惯 ◦ 其它问题，例如“飞机问题”，以及在不能上网 时用户如何工作。 6 在计算机上安装的传统软件是微软的根本 比尔·盖茨(Bill Gates)接受媒体采访时曾 提出：“我们致力于推动PC成为一切的 孰优孰劣，等待市场检验！ 中心” 微软将自身的战略称为“软件加服务” 微软将Google的乐观称作是一厢情愿。 ◦ 利用Web软件收发电子邮件、处理文档和电子 表格、进行协作很方便吗？ ◦ 高速宽带连接会象Google断言的那样普及和 可靠吗？ ◦ 企业、大学、消费者会让Google保存他们的 资料吗？ Microsoft CEO 史蒂夫.鲍尔默 7 应用规模对于系统架构设计的重要性 Google应用的特性 ◦ 海量用户+海量数据 ◦ 需要具备较强的可伸缩性 ◦ 如何又快又好地提供服务？ 秘密武器：云计算平台 8 应用向互联 网迁移 数据向互联 网迁移 计算能力向 互联网迁移 存储空间向 互联网迁移 “浏览器＝操作系统” 9 SaaS Google Docs PaaS Google App Engine Google Maps Gmail Google Calendar Google Wave ……… 10 Google在线文档 11 Google地图 12 Google邮件 13 Google日历 14 Google Wave ◦ 信息分享、协作、发布平台 15 隶属于PaaS的Google云计算 ◦ 属于部署在云端的应用执行环境 ◦ 支持Python和Java两种语言 ◦ 通过SDK提供Google的各种服务，如图形、MAIL和数据 存储等 ◦ 用户可快速、廉价（可免费使用限定的流量和存储）地部 署自己开发的应用（如创新的网站、游戏等） 16 应用场景特点 应用（功能实现）在云端 存储在云端 计算在云端 17 Google云计算平台技术架构 ◦ ◦ ◦ ◦ 文件存储，Google Distributed File System，GFS 并行数据处理MapReduce 分布式锁Chubby 结构化数据表BigTable Google云计算应用 MapReduce GFS BigTable Chubb y 18 分布式文件系统GFS Google Distributed File System 19 什么是文件系统？ ◦ FAT, FAT32, NTFS, EXT, …… ◦ 用于持久地存储数据的系统 通常覆盖在底层的物理存储介质上 ◦ 硬盘、CD、磁带等 数据组织的基本单元：文件 ◦ 具有文件名（1.txt） ◦ 通常支持层次化嵌套（目录结构） 20 文件路径 ◦ 文件与目录的结合，用于定位文件 ◦ 绝对路径，/home/aaron/foo.txt ◦ 相对路径，docs/someFile.doc 规范路径 ◦ 定位文件的最短绝对路径 ◦ /home/aaron/foo.txt, /home/../home/aaron/./foo.txt ◦ 所有规范路径的集合构成了文件系统的目录结构 21 文件系统的存储内容 ◦ 主要内容：用户的实际数据 ◦ 元数据：驱动器元数据与文件元数据 驱动器元数据 文件元数据 • 可用空间 • 文件名 • 格式信息 • 创建者 • 字符集 • 修改者 • …….. • 创建时间 • 修改时间 • ……… 22 文件分块存储 A B C (free space) A B C A (free space) A (free space) C A (free space) A D C A D (free) 23 文件系统设计的考虑因素 ◦ 最小存储单元 较小可减少浪费空间，较大则可提高文件顺序读取速度（随 机访问呢？） ◦ 文件系统的设计目标是提高访问速度还是提高使用率？ 文件系统的安全性 ◦ 多用户环境下的文件安全 ◦ 读/写权限分配 ◦ 文件附带访问控制列表（ACL） 文件系统缓存 ◦ 提高文件系统读写效率 24 Google需要一个支持海量存储的文件系统 ◦ 购置昂贵的分布式文件系统与硬件？ 是否可以在一堆廉价且不可靠的硬件上构建 可靠的分布式文件系统？ 25 为什么不使用当时现存的文件系统？ ◦ Google所面临的问题与众不同 不同的工作负载，不同的设计优先级（廉价、不可靠的硬件） ◦ 需要设计与Google应用和负载相符的文件系统 26 硬件出错是正常而非异常 ◦ 系统应当由大量廉价、易损的硬件组成 ◦ 必须保持文件系统整体的可靠性 主要负载是流数据读写 ◦ 主要用于程序处理批量数据，而非与用户的交互或随机读 写 ◦ 数据写主要是“追加写”，“插入写”非常少 需要存储大尺寸的文件 ◦ 存储的文件尺寸可能是GB或TB量级，而且应当能支持存 储成千上万的大尺寸文件 27 将文件划分为若干块（Chunk）存储 ◦ 每个块固定大小（64M） 通过冗余来提高可靠性 ◦ 每个数据块至少在3个数据块服务器上冗余 ◦ 数据块损坏概率？ 通过单个master来协调数据访问、元数据存储 ◦ 结构简单，容易保持元数据一致性 无缓存 ◦ Why? 28 单一Master, 若干ChunkServer GFS的架构有什么问题吗？ 1、文件存储方式 2、数据读写流程 29 分布式系统设计告诉我们： ◦ 这是单点故障 ◦ 这是性能瓶颈 GFS的解决办法 ◦ 单点故障问题 采用多个（如3个）影子Master节点进行热备，一 旦主节点损坏，立刻选举一个新的主节点服务 30 GFS的解决办法 ◦ 性能瓶颈问题 尽可能减少数据存取中Master的参与程度 不使用Master读取数据，仅用于保存元数据 Simple, and good enough! 客户端缓存元数据 采用大尺寸的数据块（64M） 数据修改顺序交由Primary Chunk Server完成 31 存储元数据 文件系统目录管理与加锁 与ChunkServer进行周期性通信 ◦ 发送指令，搜集状态，跟踪数据块的完好性 数据块创建、复制及负载均衡 ◦ 对ChunkServer的空间使用和访问速度进行负载均衡，平 滑数据存储和访问请求的负载 ◦ 对数据块进行复制、分散到ChunkServer上 ◦ 一旦数据块冗余数小于最低数，就发起复制操作 32 垃圾回收 ◦ 在日志中记录删除操作，并将文件改名隐藏 ◦ 缓慢地回收隐藏文件 ◦ 与传统文件删除相比更简单、更安全 陈旧数据块删除 ◦ 探测陈旧的数据块，并删除 33 采用中心服务器模式 ◦ 可以方便地增加Chunk Server ◦ Master掌握系统内所有Chunk Server的情况，方便进行 负载均衡 ◦ 不存在元数据的一致性问题 34 不缓存数据 ◦ GFS的文件操作大部分是流式读写，不存在大量的重复读 写，使用Cache对性能提高不大 ◦ Chunk Server上的数据存取使用本地文件系统，如果某 个Chunk读取频繁，文件系统具有Cache ◦ 从可行性看，Cache与实际数据的一致性维护也极其复杂 ? 35 在用户态下实现 ◦ 直接利用Chunk Server的文件系统存取Chunk，实现简 单 ◦ 用户态应用调试较为简单，利于开发 ◦ 用户态的GFS不会影响Chunk Server的稳定性 提供专用的访问接口 ◦ 未提供标准的POSIX访问接口 ◦ 降低GFS的实现复杂度 36 GFS的容错机制 ◦ Chunk Server容错 每个Chunk有多个存储副本（通常是3个），分别存储于不通 的服务器上 每个Chunk又划分为若干Block（64KB），每个Block对应一 个32bit的校验码，保证数据正确（若某个Block错误，则转 移至其他Chunk副本） 37 GFS的容错机制 ◦ Master容错 三类元数据：命名空间（目录结构）、Chunk与文件名的映 射以及Chunk副本的位置信息 前两类通过日志提供容错，Chunk副本信息存储于Chunk Server，Master出现故障时可恢复 38 超过50个GFS集群 每个集群包含数千个存储节点 管理着PB(1015Byte)级的数据 巨型、廉价、稳定的数据中心 39 简单的，就是最好的！ 40