基于GFS的Hadoop实现原理分析

１、摘要

一个面向数据密集型应用的可伸宿、分布式文件系统。

使用廉价服务器实现高容错特性，注意是廉价服务器，不是昂贵的普通人一辈子工资买不起、没见过的特制服务器。
同时请注意是容错，不是避免错误的发生。

实现大量客户端并发访问的高性能。

２、介绍

与一般的分布式文件系统在概念上的区别：

1. 集群由成百上千的廉价服务器组成，有成百上千的客户端访问系统，因此，组件失效被认为是常态。持续的监测、错误发现、容错、自动恢复功能被集成到系统中。
2. 文件个数少，但是单个文件巨大，远远超过单机对文件大小的限制。记录被集中保存在单个巨大的文件中，而不是分散保存在多个小文件中，适用于从头到层顺序从文件中读取全部记录的大数据分析，不适用于随机读取文件适时性强的场景。
3. 数据的变更以追加写为主，随机写很少或者最好没有，数据一旦写入不会或者很少发生变更。数据读取以顺序读取为主，也就是说数据的读取是连续的、大批量的。Hadoop并非不支持随机读写，它也支持。但是效率低下，并且存在很多问题需要开发人员在自己的程序解决。总之如果你的项目随机读写的场景很多，那么也就无需使用Hadoop了。
4. 关于一致性，好听点说是放宽一致性模型，这样可以简化整个系统的复杂程序及运行效率。不好听点说就是不保证数据一致性，在某些情况下你不可避免的会读到错误、陈旧的数据。在多数大数据处理场景中，极小部分数据的失效并不会影响到最终结果。如果你的项目要求数据百分百正确、万无一失，那么Hadoop也不适合你。
5. 性能方面高吞吐量大于低延时。说个不恰当的例子，系统可以10秒钟返回给客户端1G的数据，这就是吞吐量大，你让它10毫秒返回512个字节，办不到，因为这是低延时。

3、设计概述

1. 运行在容易出错的廉价服务器上，系统能够持续监测、侦错、容错、自动恢复。
2. 少量大文件而非大量小文件，针对处理全部数据集的大数据处理。
3. 有两种读模式：大的流式读取、小的随机读取。在典型的流式读取中，一次读操作可能需要取出数M的数据，并且一个客户端往往从连续的分区持续的读取，也就是大批量的顺序读取。小批量的随机读取效率低下。
4. 写模式为大批量数据的追加，也是一大块一大块数据的写入，而非很小的一条一条。数据一量写入很少需要修改（似乎是可以改，但不保证一致性），小数据的随机写也支持，但性能很差。
5. 因为单个文件中的数据可能来自于多个数据源，系统必需简单、高效的支持多客户端并发写，也就是并发追加。
6. 性能方面高吞吐量大于低延时。

4、基本架构

整个系统由一个负责管理元数据的name节点及多个负责存储数据的Chunk节点组成。在最新版本的高可用Hadoop实现中，为了避免单点故障，Name节点可以多个，一个主Name节点、一个或者多个Name备节点。但是请注意，无论有多少个Name节点，其中只有一个处于激活状态，也就是说实际干活的还是一个节点，备用Name节点只是在主Name节点挂了以后顶上去。不管怎么样，生效的Name节只有一个。

我们都知道Hadoop将文件分成Chunk块，每个文件由至少一个或者多个Chunk组成，每个Chunk有多份副本，所有Chunk块以普通文件的形式分散保存在系统中的Chunk节点上。单个Chunk块的大小与副本数量是Hadoop文件系统在设置时的重要考虑因素。Name节点通过内存管理每个块的位置信息及块与文件的映射关系，块太小，一个大文件就会被分隔的过于零碎，Name节点的内存可能不够用。另外读数据时，客户端要频繁的向Name节点请求块的位置，Name节点还要周期性的监测块的状态（回收垃圾ÿ