hadoop分布式文件系统HDFS学习
hdfs解决物理计算机存储能力不能满足数据集的要求时遇到的问题，这个系统架构于网络之上，会引入网络编程的复杂性，因此分布式文件系统比普通完成磁盘文件系统更为复杂。
hdfs基于流数据模式访问和处理超大文件的需求而开发的，它可以运行于廉价的商用服务器上，总的来说，可以将 hdfs的主要特点概括为以下几点：
（1）处理超大文件
这里指的超大文件通常指数百GB，甚至是数百TB大小的文件。目前在实际应用中，hdfs已经能用来存储管理PB级的数据了。
（2）流式的访问数据
hdfs的设计建立在更多的响应“一次写入，多次读取”任务的基础之上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说对hdfs来说，请求读取整个数据集要比读取一个记录更加高效。
（3）运行在廉价的商用机器集群上
hadoop设计对硬件需求比较低，只需运行在廉价的商用硬件集群上，但廉价商用机也意味着大型集群出现节点故障情况概率高，这就要求在设计hdfs时要充分考虑数据的可靠性，安全性及高可用性。
hdfs在一些方面有一定的局限性，主要在以下几个方面。
（1）不适合低延迟数据访问
如果要处理一些用户要求时间比较短的低延迟应用请求，则hdfs不适合。hdfs是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价，目前有一些补充的方案，比如使用Hbase，通过上层数据管理项目来尽可能的弥补这个不足。
（2）无法搞笑存储大量小文件
在Hadoop中需要使用namenode来管理文件系统的元数据，以响应客户端请求返回位置等，因此文件数量大小的限制要由namenode来决定。
（3）不支持多用户写入及任意修改文件
在hdfs的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能追加操作。
HDFS的相关概念：
1.数据块（block）
这里的数据块与通常讲的磁盘中的数据块有些不同，hdfs的块是一个抽象的概念，它比磁盘中的要大得多，在配置hadoop系统时，它的默认块为64MB。和单机上的文件系统相同，hdfs分布式文件系统中的文件也被分成块尽心存储，它是文件存储处理的逻辑单元。
设置这么大的块，目的是最小化寻址开销，块设置的足够大磁盘传输时间可以明显大于定位这个块开始位置所需的时间。
hdfs作为一个分布式文件系统，是设计用来处理大文件的，使用抽象的块会带来很多好处，一个好处是可以存储任意大的文件，而且不会受到网络中任一单一节点磁盘大小的限制。另一个好处是可以简化存储子系统。特别是元数据信息可以和文件块内容分开存储。不仅如此，块更有利于分布式文件系统中复制容错的实现。在 HDFS中为了处理节点故障，默认将文件块副本数设定为 3份，分别存储在集群的不同节点上。当一个块损坏时，系统会通过 NameNode获取元数据信息，在另外的机器上读取一个副本并进行存储。
2.Namenode和DataNode
hdfs采用master/slave架构对文件系统进行管理。一个hdfs集群是由一个namenode和一定数据的datanode组成的。这两类节点分别承担master和worker的任务。namenode就是master管理集群中的执行调度，是一个中心服务器，datanode就是worker具体任务的执行节点。namenode管理文件系统的命名空间，维护整个文件系统的文件目录树及这些文件的所有目录。这些信息以两种形式存储在本地文件系统中，一种是命名空间镜像，一种是编辑日志。从namenode中你可以获得每个文件的每个块所在 datanode，有一点需要注意的是，这些信息不是永久保存的，namenode会在每次启动系统时动态的重建这些信息。当运行任务时客户端通过namenode获取元数据信息，和datanode进行交互以访问整个文件系统。
DataNode是文件系统 Worker中的节点，用来执行具体的任务：存储文件块，被客户端和 NameNode调用。同时，它会通过心跳（ heartbeat）定时向NameNode 发送所存储的文件块信息。
客户端通过调用FileSystem对象中的 open()方法来打开希望读取的文件。 FileSystem是HDFS 中的DistributedFileSystem的一个实例（ 步骤1:open）。 DistributedFileSystem会通过RPC 协议调用 NameNode来确定请求文件起始块所在的位置（ 步骤2:get block locations）。这里需要注意的是， NameNode只会返回所调用文件中开始的几个块而不是全部返回。对于每个返回的块，都包含块所在的 DataNode地址。随后，这些返回的DatanNode会按照Hadoop 定义的集群拓扑结构得出客户端的距离，然后再进行排序。如果客户端本身就是一个DataNode，那么它将从本地读取文件。
DistributedFileSystem会向客户端返回一个支持文件定位的输入流对象 FSDataInputStream，用于给客户端读取数据。 FSDataInputStream包含一个DFSInputStream 对象，这个对象用来管理 DataNode和NameNode 之间的I/O。
当以上步骤完成时，客户端便会在这个输入流之上调用 read()函数（步骤3:read）。DFSInputStream 对象中包含文件开始部分的数据块所在的 DataNode地址，首先它会连接包含文件第一个块最近的 DataNode。随后，在数据流中重复调用 read()函数，直到这个块全部读完为止（ 步骤4:read）。当最后一个块读取完毕时， DFSInputStream会关闭连接，并查找存储下一个数据块距离客户端最近的 DataNode（步骤5:read）。以上这些步骤对客户端来说都是透明的。
客户端按照DFSInputStream 打开和DataNode连接返回的数据流的顺序读取该块，它也会调用 NameNode来检索下一组块所在的DataNode的位置信息。当客户端完成所有文件的读取时，则会在 FSDataInputStream中调用close()函数（步骤6:close）。
如果客户端和所连接的DataNode在读取时出现故障，那么它就会去尝试连接存储这个块的下一个最近的DataNode，同时它会记录这个节点的故障，这样它就不会再去尝试连接和读取块。客户端还会验证从 DataNode传送过来的数据校验和。如果发现一个损坏的块，那么客户端将会再尝试从别的 DataNode读取数据块，向NameNode报告这个信息， NameNode也会更新保存的文件信息。
这里要关注的一个设计要点是，客户端通过 NameNode引导获取最合适的DataNode地址，然后直接连接 DataNode读取数据。这种设计的好处是，可以使 HDFS扩展到更大规模的客户端并行处理，这是因为数据的流动是在所有DataNode之间分散进行的。同时NameNode的压力也变小了，使得 NameNode只用提供请求块所在的位置信息就可以了，而不用通过它提供数据，这样就避免了 NameNode随着客户端数据量的增长而成为系统瓶颈。
客户端创建文件夹是通过命令行执行的，例如： bin/hadoop dfs -mkdir input
客户端写入文件也是通过命令行执行的，例如 ：
bin/hadoop dfs -copyFromLocal conf/* input。上传的同时通过FileInputFormat类来对大文件进行分割。
客户端通过调用DistributedFileSystem对象中的 create()方法来创建一个文件（步骤1:create）。DistributedFileSystem通过RPC 调用在NameNode的文件系统命名空间中创建一个新文件，此时还没有相关的DataNode与之关联（步骤2:create）。 NameNode会通过多种验证保证新的文件不存在于文件系统中，并且确保请求客户端拥有创建文件的权限。当所有验证通过时， NameNode会创建一个新文件的记录，如果创建失败，则抛出一个 IOException异常；如果创建成功，则 DistributedFileSystem返回一个FSDataOutputStream 给客户端用来写入数据（ 步骤3:write）。这里 FSDataOutputStream和读取数据时的FSDataInputStream一样都包含一个数据流对象DFSOutputStream，客户端将使用它来处理与 DataNode和NameNode 之间的通信。
当客户端写入数据时，DFSOutputStream会将文件分割成包（这里利用 FileInputFormat类来分割大文件，FileInputFormat是所有使用文件作为其数据源的 InputFormat实现的基类。它提供了两个功能：一个定义哪些文件包含在一个作业的输入中；一个为输入文件生成分片的实现），然后放入一个内部队列，我们称为“数据队列”。DataStreamer会将这些小的文件包放入数据流中， DataStreamer的作用是请求NameNode 为新的文件包分配合适的DataNode存放副本。返回的DataNode列表形成一个“管道”，假设这里的副本数是 3，那么这个管道中就会有3个DataNode 。DataStreamer将文件包以流的方式传送给管道中的第一个 DataNode，第一个DataNode 会存储这个包，然后将它推送到第二个 DataNode中，随后照这样进行，直到管道中的最后一个 DataNode（步骤4:write packet ）文件的元数据存储在 NameNode的内存中。
DFSOutputStream同时也会保存一个包的内部队列，用来等待管道中的 DataNode返回确认信息，这个队列被称为确认队列（ ack queue）。只有当所有管道中的 DataNode都返回了写入成功的返回信息文件包，才会从确认队列中删除（ 步骤5:ack packet）。
当数据写入节点失败时， HDFS会做出以下反应：首先管道会被关闭，任何在确认通知队列中的文件包都会被添加到数据队列的前端，这样管道中故障节点下游的 DataNode都不会丢失任何一个数据包。当前这个文件中的其他存放在正常工作的 DataNode之上的文件块会被赋予一个新的身份，并且和 NameNode进行关联，这样，如果失败的DataNode过段时间后会从故障中恢复出来，其中的部分数据块就会被删除。然后，管道会把失败的 DataNode删除，文件会继续被写到管道中的另外两个 DataNode中。最后，NameNode 会注意到现在的文件块副本数没有达到配置属性要求，会在另外的 DataNode上重新安排创建一个副本，随后的文件会正常执行写入操作。
客户端成功完成数据写入的操作后，会对数据流调用 close()方法（步骤6:close ）。该操作将剩余的所有数据包写入 DataNode管线中，并在联系NameNode且发送文件写入完成信号之前，等待确认（ 步骤7:complete）。NameNode已经知道文件由哪些块组成（通过 DataStreamer询问数据块的分配），所以它在返回成功前只需要等待数据块进行最小量的复制。
