《云计算与数据挖掘81819.ppt》由会员分享，可在线阅读，更多相关《云计算与数据挖掘81819.ppt（116页珍藏版）》请在金锄头文库上搜索。
1、云计算与数据挖掘 刘鹏gloud 中国云计算 中国网格 内容提纲 云计算概念与现状 云计算的起源 云计算发展的驱动因素 云计算的定义 云计算是一种商业计算模型 它将计算任务分布在大量计算机构成的资源池上 使各种应用系统能够根据需要获取计算力 存储空间和信息服务 云计算技术体系结构 Google云计算关键技术 Google文件系统GFS GoogleFileSystem 并行数据处理MapReduce结构化数据表BigTable分布式锁管理Chubby 微软的节能措施 Google云计算原理 分布式文件系统GFSGoogleFileSystem 12 Google需要一个支持海量存储的文件系统购
2、置昂贵的分布式文件系统与硬件 Google设计GFS的动机 是否可以在一堆廉价且不可靠的硬件上构建可靠的分布式文件系统 13 为什么不使用当时现存的文件系统 Google所面临的问题与众不同不同的工作负载 不同的设计优先级 廉价 不可靠的硬件 需要设计与Google应用和负载相符的文件系统 Google设计GFS的动机 14 GFS的假设与目标 硬件出错是正常而非异常系统应当由大量廉价 易损的硬件组成必须保持文件系统整体的可靠性主要负载是流数据读写主要用于程序处理批量数据 而非与用户的交互或随机读写数据写主要是 追加写 插入写 非常少需要存储大尺寸的文件存储的文件尺寸可能是GB或TB量级 而且
3、应当能支持存储成千上万的大尺寸文件 15 将文件划分为若干块 Chunk 存储每个块固定大小 64M 通过冗余来提高可靠性每个数据块至少在3个数据块服务器上冗余数据块损坏概率 通过单个master来协调数据访问 元数据存储结构简单 容易保持元数据一致性无缓存Why GFS的设计思路 16 单一Master 若干ChunkServer GFS的架构 GFS的架构有什么问题吗 17 18 分布式系统设计告诉我们 这是单点故障这是性能瓶颈GFS的解决办法单点故障问题 单一Master问题 采用多个 如3个 影子Master节点进行热备 一旦主节点损坏 立刻选举一个新的主节点服务 19 GFS的解决办
4、法性能瓶颈问题 单一Master问题 尽可能减少数据存取中Master的参与程度 不使用Master读取数据 仅用于保存元数据 客户端缓存元数据 采用大尺寸的数据块 64M 数据修改顺序交由PrimaryChunkServer完成 Simple andgoodenough 20 存储元数据文件系统目录管理与加锁与ChunkServer进行周期性通信发送指令 搜集状态 跟踪数据块的完好性数据块创建 复制及负载均衡对ChunkServer的空间使用和访问速度进行负载均衡 平滑数据存储和访问请求的负载对数据块进行复制 分散到ChunkServer上一旦数据块冗余数小于最低数 就发起复制操作 Mast
5、er节点的任务 21 垃圾回收在日志中记录删除操作 并将文件改名隐藏缓慢地回收隐藏文件与传统文件删除相比更简单 更安全陈旧数据块删除探测陈旧的数据块 并删除 Master节点的任务 22 采用中心服务器模式可以方便地增加ChunkServerMaster掌握系统内所有ChunkServer的情况 方便进行负载均衡不存在元数据的一致性问题 GFS架构的特点 23 不缓存数据GFS的文件操作大部分是流式读写 不存在大量的重复读写 使用Cache对性能提高不大ChunkServer上的数据存取使用本地文件系统 如果某个Chunk读取频繁 文件系统具有Cache从可行性看 Cache与实际数据的一致性
6、维护也极其复杂 GFS架构的特点 24 在用户态下实现直接利用ChunkServer的文件系统存取Chunk 实现简单用户态应用调试较为简单 利于开发用户态的GFS不会影响ChunkServer的稳定性提供专用的访问接口未提供标准的POSIX访问接口降低GFS的实现复杂度 GFS架构的特点 25 GFS的容错方法 GFS的容错机制ChunkServer容错每个Chunk有多个存储副本 通常是3个 分别存储于不通的服务器上每个Chunk又划分为若干Block 64KB 每个Block对应一个32bit的校验码 保证数据正确 若某个Block错误 则转移至其他Chunk副本 26 GFS的性能 2
7、7 Google云计算原理 并行数据处理模型MapReduce 摩尔定律集成电路芯片上所集成的电路的数目 每隔18个月就翻一番 同时性能也提升一倍 并行计算基础 GordonMoore 免费的性能大餐 Andygiven andBilltakenaway软件算法 数据结构似乎不再重要 因为处理器性能不断提升 并行计算基础 免费的午餐已经结束 Intel Microsoft 摩尔定律正在走向终结 单芯片容纳晶体管的增加 对制造工艺提出要求CPU制造18nm技术 电子泄漏问题CPU主频已达3GHz时代 难以继续提高散热问题 发热太大 且难以驱散 功耗太高 并行计算基础 未来的发展 多核 在多核时代
8、生存 必须考虑并发问题不存在解决多核编程问题的银弹 不存在可以简单地将并发编程问题化解掉的工具 开发高性能的并行程序必须要求开发者从根本上改变其编程方法从某种意义上来说 这不仅仅是要改变50年来顺序程序设计的工艺传统 而且是要改变数百万年来人类顺序化思考问题的习惯 并行计算基础 HerbSutter 串行编程早期的计算里 程序一般是被串行执行的程序是指令的序列 在单处理器的机器里 程序从开始到结束 这些指令一条接一条的执行并行编程一道处理可以被划分为几部分 然后它们可以并发地执行各部分的指令分别在不同的CPU上同时运行 这些CPU可以存在于单台机器中 也可以存在于多台机器上 它们通过连接起来共
9、同运作 并行计算基础 什么样的问题适合并行计算 斐波那契序列 Fibonacci 的计算 并行计算基础 什么样的问题适合并行计算 如果有大量结构一致的数据要处理 且数据可以分解成相同大小的部分 那我们就可以设法使这道处理变成并行 并行计算基础 计算问题简单 但求解困难待处理数据量巨大 PB级 只有分布在成百上千个节点上并行计算才能在可接受的时间内完成如何进行并行分布式计算 如何分发待处理数据 如何处理分布式计算中的错误 为什么需要MapReduce 简单的问题 计算并不简单 为什么需要MapReduce GoogleMapReduce架构设计师JeffreyDean JefferyDean设计
10、一个新的抽象模型 使我们只要执行的简单计算 而将并行化 容错 数据分布 负载均衡的等杂乱细节放在一个库里 使并行编程时不必关心它们这就是MapReduce 一个软件架构 是一种处理海量数据的并行编程模式用于大规模数据集 通常大于1TB 的并行运算MapReduce实现了Map和Reduce两个功能Map把一个函数应用于集合中的所有成员 然后返回一个基于这个处理的结果集Reduce对结果集进行分类和归纳Map 和Reduce 两个函数可能会并行运行 即使不是在同一的系统的同一时刻 MapReduce MapReduce示例 单词计数 案例 单词记数问题 WordCount 给定一个巨大的文本 如
11、1TB 如何计算单词出现的数目 MapReduce示例 单词计数 使用MapReduce求解该问题定义Map和Reduce函数 MapReduce示例 单词计数 使用MapReduce求解该问题Step1 自动对文本进行分割 形成初始的对 MapReduce示例 单词计数 使用MapReduce求解该问题Step2 在分割之后的每一对进行用户定义的Map进行处理 再生成新的对 MapReduce示例 单词计数 使用MapReduce求解该问题Step3 对输出的结果集归拢 排序 系统自动完成 MapReduce示例 单词计数 使用MapReduce求解该问题Step4 通过Reduce操作生成
12、最后结果 GoogleMapReduce执行流程 源文件 GFSMap处理结果 本地存储Reduce处理结果 GFS日志 GFS 文件存储位置 思考 GoogleMapReduce计算架构有什么问题 Worker故障Master周期性的ping每个worker 如果master在一个确定的时间段内没有收到worker返回的信息 那么它将把这个worker标记成失效重新执行该节点上已经执行或尚未执行的Map任务重新执行该节点上未完成的Reduce任务 已完成的不再执行Master故障定期写入检查点数据从检查点恢复 MapReduce的容错 WHY 任务备份机制慢的workers会严重地拖延整个执
13、行完成的时间由于其他的任务占用了资源磁盘损坏解决方案 在临近结束的时候 启动多个进程来执行尚未完成的任务谁先完成 就算谁可以十分显著地提高执行效率 MapReduce的优化 本地处理Master调度策略 向GFS询问获得输入文件blocks副本的位置信息Maptasks的输入数据通常按64MB来划分 GFSblock大小 按照blocks所在的机器或机器所在机架的范围进行调度效果绝大部分机器从本地读取文件作为输入 节省大量带宽 MapReduce的优化 跳过有问题的记录一些特定的输入数据常导致Map Reduce无法运行最好的解决方法是调试或者修改不一定可行 可能需要第三方库或源码在每个wor
14、ker里运行一个信号处理程序 捕获map或reduce任务崩溃时发出的信号 一旦捕获 就会向master报告 同时报告输入记录的编号信息 如果master看到一条记录有两次崩溃信息 那么就会对该记录进行标记 下次运行的时候 跳过该记录 MapReduce的优化 实践是检验真理的唯一标准 实践证明 MapReduce是出色的分布式计算模型Google宣布 其对分布于1000台计算机上的1TB数据进行排序仅仅需要68s对4000台计算机上的1PB数据进行排序处理仅需要6小时2分钟 每次测试至少会损坏1块硬盘 在08年1月份 GoogleMapReduce平均每天的数据处理量是20PB 相当于美国国
15、会图书馆当年5月份存档网络数据的240倍 Goolge的云计算 分布式数据表BigTable 53 BigTable 为什么需要设计BigTable Google需要存储的数据种类繁多网页 地图数据 邮件 如何使用统一的方式存储各类数据 海量的服务请求如何快速地从海量信息中寻找需要的数据 BigTable 基于GFS和Chubby的分布式存储系统对数据进行结构化存储和管理与GFS的联系 54 数据存储可靠性高速数据检索与读取存储海量的记录 若干TB 可以保存记录的多个版本 Google的需求 55 与写操作相比 数据记录读操作占绝大多数工作负载单个节点故障损坏是常见的磁盘是廉价的可以不提供标准
16、接口Google既能控制数据库设计 又能进行应用系统设计 假设 56 具有广泛的适应性支持Google系列产品的存储需求具有很强的可扩展性根据需要随时加入或撤销服务器应对不断增多的访问请求高可用性单个节点易损 但要确保几乎所有的情况下系统都可用简单性简单的底层系统可减少系统出错概率 为上层开发带来便利 设计目标 57 总体上 与关系数据库中的表类似 逻辑视图 58 关系数据库中的表是什么样的 有什么特征 关系数据库中的表设计需要遵循什么原则 行每行数据有一个可排序的关键字和任意列项字符串 整数 二进制串甚至可串行化的结构都可以作为行键表按照行键的 逐字节排序 顺序对行进行有序化处理表内数据非常 稀疏 不同的行的列的数完全目可以大不相同URL是较为常见的行键 存储时需要倒排统一地址域的网页连续存储 便于查找 分析和压缩 数据模型 59 列特定含义的数据的集合 如图片 链接等可将多个列归并为一组 称为族 family 采用族 限定词的语法规则进行定义fileattr owning group fileattr owning user etc同一个族的数据被压缩在一起保存族是必须的 是Big
