分布式文件系统-HDFS

标签：des   style   blog   http   使用   io   strong   文件   

HDFS

   Hadoop的核心就是HDFS与MapReduce。那么HDFS又是基于GFS的设计理念搞出来的。

   HDFS全称是Hadoop Distributed System。HDFS是为以流的方式存取大文件而设计的。适用于几百MB，GB以及TB，并写一次读多次的场合。而对于低延时数据访问、大量小文件、同时写和任意的文件修改，则并不是十分适合。

 优点：

      1）适合存储非常大的文件

      2）适合流式数据读取，即适合“只写一次，读多次”的数据处理模式

      3）适合部署在廉价的机器上

缺点：

     1）不适合存储大量的小文件，因为受Namenode内存大小限制

     2）不适合实时数据读取，高吞吐量和实时性是相悖的，HDFS选择前者

     3）不适合需要经常修改数据的场景

   数据块：

     每个磁盘都有默认的数据块大小，一般就是521字节。这是磁盘进行数据读写的最小单位。HDFS同样也有块（block）的概念，但是大得多，有64MB。与单一磁盘上的文件系统一样，HDFS上的文件也被划分为块大小的多个分块。但是还是有所不同，比如HDFS中小于一个块大小的文件不会占据整个块的空间。

    对分布式文件系统中的快进行抽象的好处：

    1）一个文件的大小可能会大于网络中任意一个磁盘的容量，文件的所有块并不需要存储在同一个磁盘上，因此可以利用集群上的任意一个磁盘进行存储，但是对于HDFS来说，它是存储了一个文件。

        （这不就正是我们要的效果吗） 

    2）以抽象块为存储单元，简化了设计。还方便块的备份。

         HDFS的架构如上图所示，总体上采用了Master/Slave的架构，主要有以下4个部分组成：

       1、Client

            客户端，就是我们通过调用接口实现的代码。

       2、NameNode

           整个HDFS集群只有一个NameNode，它存储整个集群文件分别的元数据信息。这些信息以fsimage和editlog两个文件存储在本地磁盘，Client通过这些元数据信息可以找到相应的文件。此外，NameNode还      负责监控DataNode的健康情况，一旦发现DataNode异常，就将其踢出，并拷贝其上数据至其它DataNode。

      3、Secondary NameNode

          Secondary NameNode负责定期合并NameNode的fsimage和editlog。这里特别注意，它不是NameNode的热备，所以NameNode依然是Single Point of Failure。它存在的主要目的是为了分担一部分             NameNode的工作（特别是消耗内存的工作，因为内存资源对NameNode来说非常珍贵）。

      4、DataNode

           DataNode负责数据的实际存储。当一个文件上传至HDFS集群时，它以Block为基本单位分布在各个DataNode中，同时，为了保证数据的可靠性，每个Block会同时写入多个DataNode中（默认为3）   

      那么文件如何存储的呢？

     要存储的文件会分成很多块，存到Datanode里。分块的原则：除了最后一个数据块，其它数据块的大小相同，一般为64MB or 128MB。 每个数据块有副本（一般为3）：副本多了浪费空间。 

    副本存储：在大多数情况下，副本系数是3，HDFS的存放策略是将一个副本存放在本地机架的节点上，一个副本放在同一机架的另一个节点上，。

    HDFS通信协议 

     所有的 HDFS 通讯协议都是构建在 TCP/IP 协议上。客户端通过一个可 配置的端口连接到 Namenode ， 通过 ClientProtocol 与 Namenode 交互。而 Datanode 是使用 DatanodeProtocol 与 Namenode 交互。再设计上， DataNode 通过周期性的向 NameNode 发送心跳和数据块来保持和 NameNode 的通信，数据块报告的信息包括数据块的属性，即数据块属于哪 个文件，数据块 ID ，修改时间等， NameNode 的 DataNode 和数据块的映射 关系就是通过系统启动时 DataNode 的数据块报告建立的。从 ClientProtocol 和 Datanodeprotocol 抽象出一个远程调用 ( RPC ）， 在设计上， Namenode 不会主动发起 RPC ， 而是是响应来自客户端和 Datanode 的 RPC 请求。 
    （这个在我们进行hadoop文件配置的时候就可以感受到，都是通过一个Ip地址加上一个端口号来访问对方的）

      文件读取的过程如下：

1. 使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
2. Namenode会视情况返回文件的部分或者全部block列表，对于每个block，Namenode都会返回有该block拷贝的DataNode地址；
3. 客户端开发库Client会选取离客户端最接近的DataNode来读取block；如果客户端本身就是DataNode,那么将从本地直接获取数据.
4. 读取完当前block的数据后，关闭与当前的DataNode连接，并为读取下一个block寻找最佳的DataNode；
5. 当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向Namenode获取下一批的block列表。
6. 读取完一个block都会进行checksum验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block拷贝的datanode继续读。

     写入文件的过程如下：

1. 使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
2. Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常；
3. 当 客户端开始写入文件的时候，开发库会将文件切分成多个packets，并在内部以数据队列"data queue"的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储replicas的合适的datanodes列表， 列表的大小根据在Namenode中对replication的设置而定。
4. 开始以pipeline（管道）的形式将packet写入所 有的replicas中。开发库把packet以流的方式写入第一个datanode，该datanode把该packet存储之后，再将其传递给在此 pipeline中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。
5. 最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到datanode返回的ack packet后会从"ack queue"移除相应的packet。
6. 如 果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除， 剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持 replicas设定的数量。

分布式文件系统-HDFS,布布扣,bubuko.com

分布式文件系统-HDFS

标签：des   style   blog   http   使用   io   strong   文件   

原文地址：http://www.cnblogs.com/GuoJiaSheng/p/3919075.html