Google File System(GFS)
-
为了满足 Google 迅速增长的数据处理需求,便设计并实现了 Google 文件系统。一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。
- 首先，组件失效被认为是常态事件，而不是意外事件。系统由许多廉价的普通组件组成。系统必须持续监控自身的状态，它必须将组件失效作为一种常态，能够迅速地侦测、冗余并恢复失效的组件
- 其次，以通常的标准衡量，我们的文件非常巨大
- 第三，绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。对于这种针对海量文件的访问模式，客户端对数据块缓存是没有意义的，数据的追加操作是性能优化和原子性保证的主要考量因素。
-
GFS设计是由对Google应用程序工作负载和技术环境的四个关键观察驱动的。其观察结果：
- 组件故障是常态，因此持续监控，错误检测，容错和自动恢复是系统不可或缺的
- 巨大的文件（按传统标准）数 GB 的文件非常普遍。多GB文件是常见的I / O操作，必须重新考虑块大小
- 绝大部分文件的修改是采用在文件尾部追加数据，数据的追加操作是性能优化和原子性保证的主要考量因素。
- 共同设计应用程序和API可通过增加灵活性来使整个系统受益
- 其设计思想：群集由一个主服务器和多个块服务器组成，并且可以由多个客户端访问。要点：
- 维护所有文件系统元数据。命名空间，访问控制信息，文件到块的映射，块（包括副本）位置等。
- 定期与HeartBeat消息中的块服务器通信以提供指令和检查状态
- 使用全局知识帮助做出复杂的块放置和复制决策
- 为了进行读写，客户联系Master以获得块的位置，然后直接与块服务器进行交易
- 块服务器
- GFS 存储的文件都被分割成固定大小的 Chunk。在 Chunk 创建的时候，Master 服务器会给每个 Chunk 分配一个不变的、全球唯一的 64 位的 Chunk 标识。出于可靠性的考虑，每个块都会复制到多个块服
务器上。缺省情况下，我们使用 3 个存储复制节点 - Chunk 的大小是关键的设计参数之一。我们选择了 64MB，这个尺寸远远大于一般文件系统的 Block size。
- 有诸多优点：
- 它减少了客户端和 Master 节点通讯的需求，只需要一次和 Mater 节点的通信就可以获取 Chunk 的位置信息，之后就可以对同一个 Chunk 进行多次的读写操作
- 客户端能够对一个块进行多次操作，这样就可以通过与 Chunk 服务器保持较长时间的 TCP 连接来减少网络负载
- 减少了 Master节点需要保存的元数据的数量。这就允许我们把元数据全部放在内存中同时采用较大的Chunk 尺寸也有其缺陷：一个可执行文件在
GFS 上保存为 single-chunk 文件，之后这个可执行文件在数百台机器上同时启动。存放这个可执行文件的几
个 Chunk 服务器被数百个客户端的并发请求访问导致系统局部过载。
客户群
1.与主服务器和块服务器通信以进行读写。仅针对元数据的主交互与数据的块服务交互
2.仅缓存元数据信息数据太大而无法缓存。
Chunk 位置信息
1.主数据库不保留块和副本位置的持久记录。
2.Master 服务器只是在启动的时候轮询 Chunk 服务器以获取这些信息
3.Master 服务器能够保证它持有的信息始终是最新的，因为它控制了所有的 Chunk 位置的分配，而且通过周期性的心跳信息监控 Chunk 服务器的状态。
Google MapReduce
- MapReduce 是一个编程模型，也是一个处理和生成超大数据集的算法模型的相关实现。用户首先创建一个Map 函数处理一个基于 key/value pair 的数据集合，输出中间的基于 key/value pair 的数据集合；然后再创建一个 Reduce 函数用来合并所有的具有相同中间 key 值的中间 value 值。
- MapReduce 编程模型的原理是：利用一个输入 key/value pair 集合来产生一个输出的 key/value pair 集合。
MapReduce 库的用户用两个函数表达这个计算：Map 和 Reduce。
用户自定义的 Map 函数接受一个输入的 key/value pair 值，然后产生一个中间 key/value pair 值的集合。MapReduce 库把所有具有相同中间 key 值 I 的中间 value 值集合在一起后传递给 reduce 函数。
用户自定义的 Reduce 函数接受一个中间 key 的值 I 和相关的一个 value 值的集合。Reduce 函数合并这些value 值，形成一个较小的 value 值的集合。一般的，每次 Reduce 函数调用只产生 0 或 1 个输出 value 值。通常我们通过一个迭代器把中间 value 值提供给 Reduce 函数，这样我们就可以处理无法全部放入内存中的大量的 value 值的集合。 - 这个工作(实现一个 MapReduce 框架模型)的主要贡献是通过简单的接口来实现自动的并行化和大规模
的分布式计算，通过使用 MapReduce 模型接口实现在大量普通的 PC 机上高性能计算。- 到目前为止，MapReduce 最成功的应用就是重写了 Google 网络搜索服务所使用到的 index 系统。索引系统的输入数据是网络爬虫抓取回来的海量的文档，这些文档数据都保存在 GFS 文件系统里。这些文档原始内容4的大小超过了 20TB。索引程序是通过一系列的 MapReduce 操作（大约 5 到 10 次）来建立索引。
- 使用MapReduce（替换上一个特别设计的、分布式处理的索引程序）带来这些好处：
- 实现索引部分的代码简单、小巧、容易理解，因为对于容错、分布式以及并行计算的处理都是 MapReduce库提供的。比如，使用 MapReduce 库，计算的代码行数从原来的 3800 行 C++代码减少到大概 700 行代码。
- MapReduce 库的性能已经足够好了，因此我们可以把在概念上不相关的计算步骤分开处理，而不是混在一起以期减少数据传递的额外消耗。概念上不相关的计算步骤的隔离也使得我们可以很容易改变索引处理方式。比如，对之前的索引系统的一个小更改可能要耗费好几个月的时间，但是在使用 MapReduce 的新系统上，这样的更改只需要花几天时间就可以了。
- 索引系统的操作管理更容易了。因为由机器失效、机器处理速度缓慢、以及网络的瞬间阻塞等引起的绝大部分问题都已经由 MapReduce 库解决了，不再需要操作人员的介入了。另外，我们可以通过在索引系统集群中增加机器的简单方法提高整体处理性能。
Google Bigtable
- Bigtable 是一个分布式的结构化数据存储系统，它被设计用来处理海量数据：通常是分布在数千台普通服
务器上的 PB 级的数据。
Google 的很多项目使用 Bigtable 存储数据，包括 Web 索引、Google Earth、Google Finance。这些应用对Bigtable 提出的要求差异非常大，无论是在数据量上（从 URL 到网页到卫星图像）还是在响应速度上（从后端的批量处理到实时数据服务）。尽管应用需求差异很大，但是，针对 Google 的这些产品，Bigtable 还是成功的提供了一个灵活的、高性能的解决方案。 - Bigtable 已经在超过 60 个 Google 的产品和项目上得到了应用
- 包括Google Analytics、Google Finance、Orkut、Personalized Search、Writely 和 Google Earth。这些产品对 Bigtable 提出了迥异的需求，有的需要高吞吐量的批处理，有的则需要及时响应，快速返回数据给最终用户。它们使用的 Bigtable 集群的配置也有很大的差异，有的集群只有几台服务器，而有的则需要上千台服务器、存储几百 TB 的数据
- Bigtable 的数据模型是一个稀疏的、分布式的、持久化存储的多维度排序 Map5。Map 的索引是行关键字、列关键字以及时间戳；Map 中的每个 value 都是一个未经解析的 byte 数组。
- Bigtable 包括了三个主要的组件：链接到客户程序中的库、一个 Master 服务器和多个 Tablet 服务器。针
对系统工作负载的变化情况，BigTable 可以动态的向集群中添加（或者删除）Tablet 服务器。
以上是Google三篇论文的相关内容。在了解了产生的背景和原因后，也是能得到一些启发的。
- 在说启发之前，首先就我在读完以上内容后对创新一词产生的新认识进行说明：
- 创新，字面意思就是创造出新的事物。而“新的”是一个相对的概念，只有在存在一个参考物时，才有实际意义 。所以我认为创新就是要在现有事物的基础上，进行优化更新，而达到比现阶段更有效的、方便的、可行的新事物。
- 所以，在今后的学习生活中我们也应该持有这种思想，也就是一种类似于温故而知新的思想。
备注：以上专业叙述均来自Google三篇论文中文版及Jiaheng Lu的PDF
Google File System(GFS).
Google MapReduce
Google Bigtable
GFS, Mapreduce and Bigtable Seminar on big data management Lecturer: Jiaheng Lu Spring 2016
扫一扫
1704
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
