Google云计算原理与应用（二） 云计算 （第三版） 第 2 章 CLOUD COMPUTING Third Edition

Presentation on theme: "Google云计算原理与应用（二） 云计算 （第三版） 第 2 章 CLOUD COMPUTING Third Edition"— Presentation transcript:

1 Google云计算原理与应用（二） 云计算 （第三版） 第 2 章 CLOUD COMPUTING Third Edition
电子工业出版社《云计算(第三版)》配套课件 云计算 （第三版） CLOUD COMPUTING Third Edition 第 2 章 Google云计算原理与应用（二） 主编：刘鹏 教授

2 云计算的红宝书 微信扫描二维码 关注云计算头条 电子工业出版社《云计算(第三版)》配套课件
本套PPT下载地址： 云计算的红宝书 书籍购买地址： （包邮且有刘鹏教授亲笔签名） 微信扫描二维码 关注云计算头条

3 刘 鹏 教授、博导、学科带头人，清华大学博士。现任中国云计算专家咨询委员会秘书长、中国信息协会大数据分会副会长、工业与信息化部云计算研究中心专家。 主持完成科研项目25项，发表论文80余篇，出版专业书籍15本。获部级科技进步二等奖4项、三等奖4项。主编了国内第一本云计算教材《云计算》和第一本云计算编程书籍《实战Hadoop》。创办了知名的中国云计算（chinacloud.cn）和中国大数据（thebigdata.cn）网站。 曾率队夺得2002 PennySort国际计算机排序比赛冠军，两次夺得全国高校科技比赛最高奖，并三次夺得清华大学科技比赛最高奖。 荣获“全军十大学习成才标兵”（排名第一）、南京“十大杰出青年”、江苏省“333高层次人才培养工程”中青年科学技术带头人、清华大学“学术新秀”等称号。

4 目 录 2.1 Google文件系统GFS 2.2 分布式数据处理MapReduce 2.3 分布式锁服务Chubby
2.4 分布式结构化数据表Bigtable 2.5 分布式存储系统Megastore 2.6 大规模分布式系统的监控基础架构Dapper 2.7 海量数据的交互式分析工具Dremel 2.8 内存大数据分析系统PowerDrill 2.9 Google应用程序引擎

5 2.3 分布式锁服务Chubby 初步了解Chubby
Chubby是Google设计的提供粗粒度锁服务的一个文件系统，它基于松耦合分布式系统，解决了分布的一致性问题。 通过使用Chubby的锁服务，用户可以确保数据操作过程中的一致性 Chubby作为一个稳定的存储系统存储包括元数据在内的小数据 Google内部还使用Chubby进行名字服务（Name Server）

6 2.3 分布式锁服务Chubby 2.3.1 Paxos算法 2.3.2 Chubby系统设计 2.3.3 Chubby中的Paxos
通信协议 正确性与性能

7 2.3 分布式锁服务Chubby Paxos算法 三个节点 三个条件 proposers 提出决议 acceptors 批准决议
learners 获取并使用已经通过的决议 决议只有在被proposers提出后才能批准 三个条件 每次只批准一个决议 只有决议确定被批准后learners才能获取这个决议

8 2.3 分布式锁服务Chubby 系统的约束条件 p1：每个acceptor只接受它得到的第一个决议。
p2a：一旦某个决议v得到通过，之后任何acceptor再批准的决议必须是v。 p2b：一旦某个决议v得到通过，之后任何proposer再提出的决议必须是v。 p2c：如果一个编号为n的提案具有值v，那么存在一个“多数派”，要么它们中没有谁批准过编号小于n的任何提案，要么它们进行的最近一次批准具有值v。 为了保证决议的唯一性，acceptors也要满足一个约束条件：当且仅当 acceptors 没有收到编号大于n的请求时，acceptors 才批准编号为n的提案。

9 1 2 2.3 分布式锁服务Chubby 一个决议分为两个阶段 准备阶段 批准阶段 proposers选择一个提案并将它的编号设为n
将它发送给acceptors中的一个“多数派” acceptors 收到后，如果提案的编号大于它已经回复的所有消息，则acceptors将自己上次的批准回复给proposers，并不再批准小于n的提案。 准备阶段 当proposers接收到acceptors 中的这个“多数派”的回复后，就向回复请求的acceptors发送accept请求，在符合acceptors一方的约束条件下，acceptors收到accept请求后即批准这个请求。 2 批准阶段

10 2.3 分布式锁服务Chubby 2.3.1 Paxos算法 2.3.2 Chubby系统设计 2.3.3 Chubby中的Paxos
通信协议 正确性与性能

11 1 4 2 5 3 6 2.3 分布式锁服务Chubby Chubby的设计目标主要有以下几点 高可用性和高可靠性 服务信息的直接存储
高扩展性 支持缓存机制 支持粗粒度的建议性锁服务 3 6 支持通报机制

12 2.3 分布式锁服务Chubby Chubby的基本架构 … 客户端 服务器端
应用程序 Chubby程序率 … 远程过程调用 Chubby单元的 五个服务器 主服务器 客户端进程 在客户这一端每个客户应用程序都有一个Chubby程序库（Chubby Library），客户端的所有应用都是通过调用这个库中的相关函数来完成的。 服务器端 服务器一端称为Chubby单元，一般是由五个称为副本（Replica）的服务器组成的，这五个副本在配置上完全一致，并且在系统刚开始时处于对等地位。

13 2.3 分布式锁服务Chubby 2.3.1 Paxos算法 2.3.2 Chubby系统设计 2.3.3 Chubby中的Paxos
通信协议 正确性与性能

14 2.3 分布式锁服务Chubby 单个Chubby副本结构 Chubby协议 Chubby客户端网络 RPC 副本网络 Chubby 文件
传输 快照互换 （Sanpshot exchange） 容错的数据库 （Fault-tolerant DB） 容错的日志 （Fault-tolerant Log） Paxos协议 本地文件系统 文件I/O 日志 快照

15 2.3 分布式锁服务Chubby 容错日志的API 副本1 副本2 副本3 值 响应 提交 客户端 应用程序 Paxos 构架 协议

16 2.3 分布式锁服务Chubby 2.3.1 Paxos算法 2.3.2 Chubby系统设计 2.3.3 Chubby中的Paxos
通信协议 正确性与性能

17 2.3 分布式锁服务Chubby 单调递增的64位编号 实例号 新节点实例号必定大于旧节点的实例号。 内容生成号 文件内容修改时该号增加。
1 实例号 新节点实例号必定大于旧节点的实例号。 Instance Number 2 内容生成号 文件内容修改时该号增加。 Content Generation Number 3 锁生成号 锁被用户持有时该号增加。 Lock Generation Number 4 ACL生成号 ACL名被覆写时该号增加。 ACL Generation Number

18 2.3 分布式锁服务Chubby 常用的句柄函数及作用 函 数 名 称 作 用 Open() 打开某个文件或者目录来创建句柄 Close()
作 用 Open() 打开某个文件或者目录来创建句柄 Close() 关闭打开的句柄，后续的任何操作都将中止 Poison() 中止当前未完成及后续的操作，但不关闭句柄 GetContentsAndStat() 返回文件内容及元数据 GetStat() 只返回文件元数据 ReadDir() 返回子目录名称及其元数据 SetContents() 向文件中写入内容 SetACL() 设置ACL名称 Delete() 如果该节点没有子节点的话则执行删除操作 Acquire() 获取锁 Release() 释放锁 GetSequencer() 返回一个sequencer SetSequencer() 将sequencer和某个句柄进行关联 CheckSequencer() 检查某个sequencer是否有效

19 2.3 分布式锁服务Chubby 2.3.1 Paxos算法 2.3.2 Chubby系统设计 2.3.3 Chubby中的Paxos
通信协议 正确性与性能

20 2.3 分布式锁服务Chubby Chubby客户端与服务器端的通信过程

21 2.3 分布式锁服务Chubby 可能出现的两种故障 1 2 客户端租约过期 主服务器出错

22 2.3 分布式锁服务Chubby 2.3.1 Paxos算法 2.3.2 Chubby系统设计 2.3.3 Chubby中的Paxos
通信协议 正确性与性能

23 2.3 分布式锁服务Chubby 正确性与性能 一致性 安全性 性能优化
采用的是ACL形式的安全保障措施。只要不被覆写，子节点都是直接继承父节点的ACL名 提高主服务器默认的租约期、使用协议转换服务将Chubby协议转换成较简单的协议、客户端一致性缓存等

24 2.3 分布式锁服务Chubby Chubby 的 ACL 机制
用户chinacloud提出向文件CLOUD中写入内容的请求。CLOUD首先读取自身的写ACL名fun，接着在fun中查到了chinacloud这一行记录，于是返回信息允许chinacloud对文件进行写操作，此时chinacloud才被允许向CLOUD写入内容。其他的操作和写操作类似。

25 目 录 2.1 Google文件系统GFS 2.2 分布式数据处理MapReduce 2.3 分布式锁服务Chubby
2.4 分布式结构化数据表Bigtable 2.5 分布式存储系统Megastore 2.6 大规模分布式系统的监控基础架构Dapper 2.7 海量数据的交互式分析工具Dremel 2.8 内存大数据分析系统PowerDrill 2.9 Google应用程序引擎

26 2.4 分布式结构化数据表Bigtable 2.4.1 设计动机与目标 2.4.2 数据模型 2.4.3 系统架构 2.4.4 主服务器
设计动机与目标 数据模型 系统架构 主服务器 子表服务器 性能优化

27 2 1 3 2.4 分布式结构化数据表Bigtable Bigtable 的设计动机 需要存储 的数据种类繁多 海量的 服务请求 商用数据库
Google运行着目前世界上最繁忙的系统，它每时每刻处理的客户服务请求数量是普通的系统根本无法承受的 2 一方面现有商用数据库的设计着眼点在于其通用性。 另一方面对于底层系统的完全掌控会给后期的系统维护、升级带来极大的便利 1 包括URL、网页内容、用户的个性化设置在内的数据都是Google需要经常处理的 3 需要存储 的数据种类繁多 海量的 服务请求 商用数据库 无法满足需求

28 2.4 分布式结构化数据表Bigtable Bigtable 应达到的基本目标 广泛的适用性 很强的可扩展性 高可用性 简单性
Bigtable是为了满足一系列Google产品而并非特定产品的存储要求。 广泛的适用性 很强的可扩展性 根据需要随时可以加入或撤销服务器 高可用性 确保几乎所有的情况下系统都可用 底层系统的简单性既可以减少系统出错的概率，也为上层应用的开发带来便利 简单性

29 2.4 分布式结构化数据表Bigtable 2.4.1 设计动机与目标 2.4.2 数据模型 2.4.3 系统架构 2.4.4 主服务器
设计动机与目标 数据模型 系统架构 主服务器 子表服务器 性能优化

30 2.4 分布式结构化数据表Bigtable Bigtable数据的存储格式
Bigtable是一个分布式多维映射表，表中的数据通过一个行关键字（Row Key）、一个列关键字（Column Key）以及一个时间戳（Time Stamp）进行索引 Bigtable的存储逻辑可以表示为： (row:string, column:string, time:int64)→string

31 行 列 2.4 分布式结构化数据表Bigtable 时间戳 Bigtable的行关键字可以是任意的字符串，但是大小不能够超过64KB
将其组织成所谓的列族（Column Family） Google的很多服务比如网页检索和用户的个性化设置等都需要保存不同时间的数据，这些不同的数据版本必须通过时间戳来区分。 族名必须有意义，限定词则可以任意选定 表中数据都是根据行关键字进行排序的，排序使用的是词典序 组织的数据结构清晰明了，含义也很清楚 Bigtable中的时间戳是64位整型数，具体的赋值方式可以用户自行定义 同一地址域的网页会被存储在表中的连续位置 族同时也是Bigtable中访问控制（Access Control）的基本单元 倒排便于数据压缩，可以大幅提高压缩率

32 2.4 分布式结构化数据表Bigtable 2.4.1 设计动机与目标 2.4.2 数据模型 2.4.3 系统架构 2.4.4 主服务器
设计动机与目标 数据模型 系统架构 主服务器 子表服务器 性能优化

33 2.4 分布式结构化数据表Bigtable Bigtable 基本架构

34 Bigtable 中 Chubby 的主要作用
选取并保证同一时间内只有一个主服务器（Master Server）。 作用一 获取子表的位置信息。 作用二 作用三 保存Bigtable的模式信息及访问控制列表。

35 2.4 分布式结构化数据表Bigtable 2.4.1 设计动机与目标 2.4.2 数据模型 2.4.3 系统架构 2.4.4 主服务器
设计动机与目标 数据模型 系统架构 主服务器 子表服务器 性能优化

36 2.4 分布式结构化数据表Bigtable 主服务器 新子表分配 子表服务器状态监控 子服务器之间的负载均衡
当一个新的子表产生时，主服务器通过一个加载命令将其分配给一个空间足够的子表服务器。 创建新表、表合并以及较大子表的分裂都会产生一个或多个新子表。 分割完成之后子服务器需要向主服务发出一个通知。 主服务器必须对子表服务器的状态进行监控，以便及时检测到服务器的加入或撤销

37 Bigtable 中 Chubby 的主要作用
与所有的活跃子表服务器取得联系以便了解所有子表的分配情况 步骤 2 步骤 4 扫描服务器目录，发现目前活跃的子表服务器 通过扫描元数据表（Metadata Table），发现未分配的子表并将其分配到合适的子表服务器 步骤 1 步骤 3

38 2.4 分布式结构化数据表Bigtable 2.4.1 设计动机与目标 2.4.2 数据模型 2.4.3 系统架构 2.4.4 主服务器
设计动机与目标 数据模型 系统架构 主服务器 子表服务器 性能优化

39 2.4 分布式结构化数据表Bigtable SSTable 格式的基本示意
SSTable是Google为Bigtable设计的内部数据存储格式。所有的SSTable文件都存储在GFS上，用户可以通过键来查询相应的值。 64KB 块 … SSTable 索引

40 2.4 分布式结构化数据表Bigtable 子表实际组成 日志 不同子表的SSTable可以共享 每个子表服务器上仅保存一个日志文件
每个子表服务器上保存的子表数量可以从几十到上千不等，通常情况下是100个左右 日志 64KB 块 … SSTable 索引

41 2.4 分布式结构化数据表Bigtable 子表地址组成 … … … … … … … …
Bigtable系统的内部采用的是一种类似B+树的三层查询体系 用户表1 … 其他元数据子表 … 根子表 （元数据表中第一条记录） … Chubby文件 … … 用户表N … … …

42 2.4 分布式结构化数据表Bigtable Bigtable 数据存储及读/写操作
较新的数据存储在内存中一个称为内存表（Memtable）的有序缓冲里，较早的数据则以SSTable格式保存在GFS中。 读和写操作有很大的差异性

43 2.4 分布式结构化数据表Bigtable 三种形式压缩之间的关系 SSTable 次压缩 内存表 SSTable SSTable ……
合并压缩 主压缩

44 2.4 分布式结构化数据表Bigtable 2.4.1 设计动机与目标 2.4.2 数据模型 2.4.3 系统架构 2.4.4 主服务器
设计动机与目标 数据模型 系统架构 主服务器 子表服务器 性能优化

45 2.4 分布式结构化数据表Bigtable 局部性群组
Bigtable允许用户将原本并不存储在一起的数据以列族为单位，根据需要组织在一个单独的SSTable中，以构成一个局部性群组。 用户可以只看自己感兴趣的内容。 对于一些较小的且会被经常读取的局部性群组，明显地改善读取效率。

46 2.4 分布式结构化数据表Bigtable 压缩 压缩可以有效地节省空间，Bigtable中的压缩被应用于很多场合。首先压缩可以被用在构成局部性群组的SSTable中，可以选择是否对个人的局部性群组的SSTable进行压缩。 1 利用Bentley & McIlroy方式（BMDiff）在大的扫描窗口将常见的长串进行压缩 2 采取Zippy技术进行快速压缩，它在一个16KB大小的扫描窗口内寻找重复数据，这个过程非常快

47 2.4 分布式结构化数据表Bigtable 布隆过滤器 优点 缺点
在某些情况下它会将不存在的子表判断为存在 布隆过滤器的速度快，省空间 不会将一个存在的子表判定为不存在

48 本章未完待续

49 百度排名首位的大数据资料和交流中心

50 百度排名首位的云计算资料和交流中心

51 终生免费的智能硬件大数据托管平台

52 终生免费的环境大数据共享平台

53 知名微信公众号推荐 学习云计算必须关注的公众号 刘鹏看未来 云计算头条 中国大数据 云创大数据 眼光决定成败，与刘鹏教授看未来。
微信号：lpoutlook 微信号： chinacloudnj 眼光决定成败，与刘鹏教授看未来。 刘鹏，清华博士，《云计算》作者。 资源丰富、分析深入、更新及时的云计算知识共享平台。 中国大数据 云创大数据 微信号： cStor_cn 微信号： cstorbigdata 国内大数据龙头企业。提供领先的云存储、云数据库、云视频、云传输产品和解决方案。 分享大数据技术，剖析大数据案例，讨论大数据话题。

54 运用云计算，精彩你生活 优秀免费云计算应用推荐 支持安卓和苹果 支持安卓和苹果 暂时仅有安卓版本

55 谢谢观看 云计算 （第三版） 第 2 章 CLOUD COMPUTING Third Edition 主编：刘鹏 教授
电子工业出版社《云计算(第三版)》配套课件 云计算 （第三版） CLOUD COMPUTING Third Edition 第 2 章 谢谢观看 主编：刘鹏 教授