《课件04多结构化数据管理google GFS1.》由会员分享，可在线阅读，更多相关《课件04多结构化数据管理google GFS1.（74页珍藏版）》请在金锄头文库上搜索。
1、多结构化数据管理 潘鹏 数据存储与组织方法 现有技术（Google GFS） 2 GFS+BigTable+MapReduce 2 3 GFS基本理念 GFS几百甚至几千台普通的廉价设备组装的存储机群 ， 同时被相当数量的客户机访问。 文件可能非常巨大（数GB的文件非常普遍），每个文件通 常都包含许多应用程序对象（例如web文档、微博）。 经常需要处理快速增长的、并且由数亿个对象构成的、数 以TB的数据集。 绝大部分的修改是在文件尾部追加数据，而不是覆盖原有 数据。一旦写完之后，对文件的操作就只有读，而且通常 是按顺序读。 3 GFS基本理念 组件失效 是常态而不是意外事件（任何给定时间内都有
2、可 能发生某些组件无法工作、无法从它们目前的失效 状态中恢复）。 放松了对一致性模型的要求，引入了原子性的记 录追加操作，从而保证多个客户端能同时进行追加 操作，不需要额外的同步操作来保证数据的一致 性。 4 5 GFS基本概念 Chunk：文件都被分割成固定大小的Chunk。 Chunk创建时，Master服务器会给每个Chunk分配一个 不变的、全球唯一的64位的Chunk标识。 Namespace：GFS提供了一套类似传统文件系统的API接 口函数（没有严格按照POSIX等标准API的形式实现），文 件以分层目录的形式组织，用路径名来标识。 在逻辑上，GFS的名称空间就是一个全路径和元数
3、据映 射关系的查找表。 5 大块 GFS基本概念 1）利用前缀压缩，namespace表高效的存储在内 存中。 2）在存储名称空间的树型结构上，每个节点（绝 对路径的文件名或绝对路径的目录名）都有一个关 联的读写锁。 不同于许多传统文件系统，GFS没有针对每个目录 实现能够列出目录下所有文件的数据结构，GFS也 不支持文件或者目录的链接（即Unix术语中的硬链 接或者符号链接）。 6元数据的存储与访问机制 7 GFS基本概念 Chunkserver：Chunk服务器把Chunk以linux文 件的形式保存在本地硬盘上，并且根据指定的 Chunk标识和字节范围来读写块数据。 可靠性 每个块都会复
4、制到多个chunkserver 上（缺省3个存储复制节点）。 用户可以为不同的文件命名空间区域设定不同 的复制级别。 7 8 GFS基本概念 Master：GFS分布式文件系统中的总控节点。 u执行所有的namespace操作。 u管理整个系统里所有Chunk的副本 决定Chunk的存储位置 创建新Chunk和它的副本 协调各种系统活动以保证Chunk被完全复制 在所有的Chunk服务器之间进行负载均衡 回收不再使用的存储空间 8 GFS基本概念 Master管理所有的文件系统元数据： Namespace 访问控制信息 文件和Chunk的映射信息 Chunk当前的位置信息 Master节点还管
5、理着系统范围内的活动： Chunk租约管理 孤儿Chunk(orphaned chunks)的回收 Chunk在Chunk服务器之间的迁移。 9 10 GFS基本概念 一个GFS集群包含一个逻辑上单独的Master节点（ Master组件）。 物理上有Master节点复制机制，为便于理解，可 认为一个逻辑的Master节点包括两台物理主机，即两 台Master服务器。 与Chunk服务器通讯？ Master节点使用心跳信息周期地和每个Chunk服务 器通讯，发送指令到各个Chunk服务器并接收Chunk 服务器的状态信息。 10 11 GFS基本概念 Client：GFS客户端实现了GFS文件
6、系统的API接口函数， 代码以库的形式被链接到客户程序里。 应用程序与Master节点和Chunk服务器通讯，对数据进行 读写操作。 客户端和Master节点的通信只获取元数据，所有的数据 操作都是由客户端直接和Chunk服务器进行交互的。 11 Data message Control message 12 GFS架构（容错，可伸缩性，数据存储，集群存储） 12 DHT? MEMCACHE? 13 Master保存的内容元数据 Master存储3种主要类型的元数据： 文件和Chunk的命名空间 文件和Chunk的对应关系 每个Chunk副本的存放地点 Master不持久保存Chunk位置信息
7、 在启动或者有新的Chunk服务器加入时，向各个 Chunk服务器轮询它们所存储的Chunk信息，并通过 周期性的心跳信息监控Chunk服务器的状态。 13 内存中 14 Chunk的位置信息 Master在启动和之后定期轮询Chunk服务器及其更 新的设计简化了Master和Chunk服务器数据同步的问 题（在一个有数百台服务器的集群中，这类事件会频 繁的发生：有Chunk服务器加入/离开集群、更名、失 效、重启）。 14 只有Chunk服务器才能最终确定一个Chunk是否在它的硬 盘上，Chunk服务器的错误可能会导致Chunk自动消失(如 硬盘损坏或无法访问)，或者操作人员会重命名一个C
8、hunk 服务器。 不在Master上持久化维护这些信息的全局视 图。 15 Master保存的内容变更日志 两种类型的元数据（命名空间、文件和Chunk 的对应关系）同时也会以变更日志的方式记录在操 作系统的系统日志文件（存储在本地磁盘）中，该 日志同时被复制到其它的远程Master服务器上。 系统能简单可靠的更新Master服务器的状态， 不用担心Master服务器崩溃导致数据不一致的风 险。 15 有什么数据？数据的逻辑组成？ 16 Master的容量、系统的容量 Chunk的数量以及整个系统的承载能力都受限于 Master的内存大小，实际应用中的容量很大。 1）Master只需不到64
9、个字节的元数据就能管理一个 64MB的Chunk。 2）大多数文件都包含多个Chunk，因此绝大多数 Chunk都是满的（除了文件的最后一个Chunk）。 3）同样，一个文件在命名空间中的数据大小通常在64 字节以下（文件名保存使用前缀压缩算法）。 即便要支持更大的文件系统，为Master服务器增加 额外内存的费用也是值得的。 16 17 关于缓存 Master和客户端都会缓存元数据。 客户端和Chunk服务器都不缓存文件数据，简化了 客户端和整个系统的设计和实现。 大部分程序要么以流的方式读取一个巨大文件，要 么工作集太大根本无法被缓存 客户端缓存文件数据 意义不大。 Chunk以本地文件的
10、方式保存， Linux操作系统的 文件系统缓存会把经常访问的数据缓存在内存中 Chunk服务器不缓存文件数据。 17 18 简单读取的流程 1）客户端将文件名和程序指定的字节偏移根据固 定的Chunk大小转换成文件的Chunk索引，进而把 文件名和Chunk索引发送给Master节点。 2）Master节点将相应的Chunk标识和副本的位置 信息发还给客户端。客户端用文件名和Chunk索引 作为key缓存这些信息，之后客户端发送请求（包 含Chunk的标识和字节范围）到其中的一个副本处 （一般会选择最近的）。 3）Chunkserver读取chunk数据返回客户端。 18 简单读取的流程 在开
11、始了对Chunk的数据读取操作后，客户端不 必再和Master节点通讯，除非缓存的元数据信息 过期或者文件被重新打开。 实际过程中，客户端通常会在一次请求中查询多 个Chunk信息，Master节点的回应也可能包含了 被请求的Chunk的后续Chunk的信息。 同样代价额外元数据，避免客户端和Master节 点未来可能会发生的几次通讯。 19 20 关于Master节点 Master节点可通过全局的信息精确定位Chunk 的位置并制定复制决策。单一Master节点的策略 简化了设计。 必须减少对Master节点的读写（避免Master节 点成为系统的瓶颈）： 1）客户端不通过Master节点读
12、写文件数据，仅向 Master节点询问它应该联系的Chunk服务器； 2）客户端将这些元数据信息缓存一段时间； 3）后续的数据读写操作直接对Chunk服务器进 行。 20 21 Chunk尺寸 惰性分配策略：每个Chunk（副本）都以普通Linux文件的 形式保存在Chunk服务器上，只在需要的时候才扩大。 避免因内部碎片造成的空间浪费。 Chunk的大小是关键的设计参数之一，设置为64MB这 个远远大于一般文件系统的Block尺寸存在着争议。 21 22 Chunk尺寸 优点： 1）选用较大的Chunk尺寸减少了Master节点需要保存 的元数据的数量，有利于元数据全部放在内存中。 2）采用
13、较大的Chunk尺寸，客户端能对一个块进行多 次操作，从而通过与Chunk服务器保持较长时间的TCP 连接来减少网络负载。 3）减少了客户端和Master节点通讯的需求（应用程序 通常连续读写大文件），客户端可以轻松缓存一个数TB 的工作数据集所拥有的Chunk位置信息。 22 23 Chunk尺寸 缺点： 小文件包含较少的Chunk(甚至只有一个Chunk)。当有 许多的客户端对同一个小文件进行多次的访问时，存储这 些Chunk的Chunk服务器就会变成热点。 实例： 当GFS用于批处理队列系统 热点问题。 例：一个可执行文件在GFS上保存单一chunk文件，之后这 个可执行文件在数百台机器
14、上同时启动。 存放这个可执行文件的几个Chunk服务器被数百个客户端 并发请求访问，导致系统局部过载。 23 24 Chunk尺寸 存放某个可执行文件的几个Chunk服务器被数 百个客户端的并发请求访问导致系统局部过载。 解决方法： 1）使用更大的复制参数来保存可执行文件； 2）错开批处理队列系统程序的启动时间； 3）允许客户端从其它客户端读取数据。 24 25 操作日志 操作日志包含元数据变更历史记录： 1）是元数据唯一的持久化存储记录； 2）是作为判断同步操作顺序的逻辑时间基线（逻 辑日志序号作为操作发生的逻辑时间，类似于事务 系统中的LSN）。 文件和Chunk（连同它们的版本）都由它们
15、创 建的逻辑时间唯一的、永久的标识。 25 26 写日志机制 1）确保日志文件是完整的且元数据的变化被持久化后 ，日志才对客户端是可见的。否则，即使Chunk本身 没有出现问题，仍有可能丢失整个文件系统（或者客 户端最近的操作）。 2）日志会复制到多台远程机器，只有相应的日志记录 写入到本地以及远程机器的硬盘后，才会响应客户端 的操作请求。 3）Master服务器会收集多个日志记录后批量处理， 以减少写入磁盘和复制对系统整体性能的影响。 26 27 灾难恢复 灾难恢复时，Master通过重演操作日志把文件系 统恢复到最近的状态。 带来的问题：从日志头开始恢复（日志过长）? 解决方法：checkpoint，减少重演操作的日志 量。 27 28 checkpoint 日志增长到一定量 Master对系统状态做一次 Checkpoint，将所有的状态数据写入一个Checkpoint文件 （并删除之前的日志文件）。 恢复：Master从磁盘上读取最新的Checkpoint文件，重演 Checkpoint之后的有限个日志文件便可恢复系统。 Checkpoint文件存储：压缩B-树形式。可以直接映射到内存 ，在用于命名空间查询时无需额外的解析，从而大大提高恢 复速度，增强可用性。 28 29 checkpoint checkpoint过程不阻塞正在进行的修改操作
