分布式文件系统-HDFS

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个部分组成：

       一、Client

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

       二、NameNode

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

      三、Secondary NameNode

          Secondary NameNode负责按期合并NameNode的fsimage和editlog。这里特别注意，它不是NameNode的热备，因此NameNode依然是Single Point of Failure。它存在的主要目的是为了分担一部分             NameNode的工做（特别是消耗内存的工做，由于内存资源对NameNode来讲很是珍贵）。

      四、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设定的数量。