hadoop之HDFS

	统一管理分布在集群上的文件系统称为分布式文件系统，特点：存储非常大的文件（文件的元数据存储在NameNode中，文件太多存不了），流式的数据访问方式，普通商用机器上。
	
	HDFS采用追加的方式写入数据，不支持文件任意offset的修改。
	
	物理磁盘中有块的概念，磁盘的物理Block是磁盘操作最小的单元一般为512 Byte。文件系统在物理Block之上抽象了另一层概念，文件系统Block物理磁盘Block的整数倍。通常为几KB。
	
	HDFS的Block块比一般单机文件系统大得多，默认为128M。比Block小的文件不会占用整个Block，只会占据实际大小。如果一文件大小为1M，则在HDFS中只会占用1M的空间，而不是128M。
	
	Block这么大是为了最小化查找时间。如果Block设置过大，在MapReduce任务中，Map或者Reduce任务的个数如果小于集群机器数量，会使得作业运行效率很低。
	
	Block作为容错和高可用机制中的副本单元，即以Block为单位进行复制。
	
	整个HDFS集群由Namenode和Datanode构成。Namenode复杂构建命名空间，管理文件的元数据等，而Datanode负责实际存储数据，负责读写工作。

	Namenode（在内存上） 持久化： namespcae image，edit log。
	但持久化数据中不包括Block所在的节点列表，及文件的Block分布在集群中的哪些节点上，这些信息是在系统重启的时候重新构建（通过Datanode汇报的Block信息）Namenode不可用时，整个文件系统是不可用的。
	
	1）备份持久化元数据
	将文件系统的元数据同时写到多个文件系统，例如同时将元数据写到本地文件系统及NFS。

	2）Secondary Namenode
	Secondary节点定期合并主Namenode的namespace image和edit log， 避免edit log过大，通过创建检查点checkpoint来合并。它会维护一个合并后的namespace image副本，可用于在Namenode完全崩溃时恢复数据。
	
	Secondary Namenode通常运行在另一台机器，因为合并操作需要耗费大量的CPU和内存。其数据落后于Namenode，因此当Namenode完全崩溃时，会出现数据丢失。 通常做法是拷贝NFS中的备份元数据到Second，将其作为新的主Namenode。

	在HA中可以运行一个Hot Standby，作为热备份，在Active Namenode故障之后，替代原有Namenode成为Active Namenode。
	
	数据节点负责存储和提取Block，读写请求可能来自namenode，也可能直接来自客户端。数据节点周期性向Namenode汇报自己节点上所存储的Block相关信息。
	DataNode通常直接从磁盘读取数据，但是频繁使用的Block可以在内存中缓存。默认情况下，一个Block只有一个数据节点会缓存。作业调度器可以利用缓存提升性能，例如MapReduce可以把任务运行在有Block缓存的节点上。

	NameNode的内存会制约文件数量，HDFS Federation提供了一种横向扩展NameNode的方式。在Federation模式中，每个NameNode管理命名空间的一部分，例如一个NameNode管理/user目录下的文件， 另一个NameNode管理/share目录下的文件。是独立的，一个节点的失败不会导致其他节点管理的文件不可用。

	NameNode是单点故障。元数据同时写到多个文件系统以及Second NameNode定期checkpoint有利于保护数据丢失，但是并不能提高可用性。
	这是因为NameNode是唯一一个对文件元数据和file-block映射负责的地方，当它挂了之后，包括MapReduce在内的作业都无法进行读写。当NameNode故障时，常规的做法是使用元数据备份重新启动一个NameNode。元数据备份可能来源于：多文件系统写入中的备份、Second NameNode的检查点文件，启动新的Namenode之后，需要重新配置客户端和DataNode的NameNode信息。另外重启耗时一般比较久，稍具规模的集群重启经常需要几十分钟甚至数小时，造成重启耗时的原因大致有：
	1） 元数据镜像文件载入到内存耗时较长。
	2） 需要重放edit log
	3） 需要收到来自DataNode的状态报告并且满足条件后才能离开安全模式提供写服务。
	
	HA方案：
	采用HA的HDFS集群配置两个NameNode，分别处于Active和Standby状态。当Active NameNode故障之后，
	Standby接过责任继续提供服务，用户没有明显的中断感觉。一般耗时在几十秒到数分钟。
	HA涉及到的主要实现逻辑有
	1）主备需共享edit log存储。
	主NameNode和待命的NameNode共享一份edit log，当主备切换时，Standby通过回放edit log同步数据。
	共享存储通常有2种选择：
	NFS：传统的网络文件系统。
	QJM：quorum journal manager。
	QJM是专门为HDFS的HA实现而设计的，用来提供高可用的edit log。QJM运行一组journal node，edit log必须写到大部分的journal nodes。通常使用3个节点，因此允许一个节点失败。

	DataNode需要同时往主备发送Block Report，因为Block映射数据存储在内存中（不是在磁盘上），为了在Active NameNode挂掉之后，新的NameNode能够快速启动，不需要等待来自Datanode的Block Report，DataNode需要同时向主备两个NameNode发送Block Report。

	Namenode的切换对客户端来说是无感知的，通过客户端库来实现。客户端在配置文件中使用的HDFS URI是逻辑路径，映射到一对Namenode地址。客户端会不断尝试每一个Namenode地址直到成功。
	如果没有启用HA，HDFS独立运行一个守护进程作为Secondary Namenode。定期checkpoint，合并镜像文件和edit日志。

	HDFS提供了各种交互方式，例如通过Java API、HTTP、shell命令行的。命令行的交互主要通过hadoop fs来操作。例如：

	hadoop fs -copyFromLocal // 从本地复制文件到HDFS
	hadoop fs mkdir // 创建目录
	hadoop fs -ls  // 列出文件列表

	大致读文件的流程如下：
	1）客户端传递一个文件Path给FileSystem的open方法
	2）DFS采用RPC远程获取文件最开始的几个block的datanode地址。Namenode会根据网络拓扑结构决定返回哪些节点（前提是节点有block副本），如果客户端本身是Datanode并且节点上刚好有block副本，直接从本地读取。
	3）客户端使用open方法返回的FSDataInputStream对象读取数据（调用read方法）
	4）DFSInputStream（FSDataInputStream实现了改类）连接持有第一个block的、最近的节点，反复调用read方法读取数据
	5）第一个block读取完毕之后，寻找下一个block的最佳datanode，读取数据。如果有必要，DFSInputStream会联系Namenode获取下一批Block 的节点信息(存放于内存，不持久化），这些寻址过程对客户端都是不可见的。
	6）数据读取完毕，客户端调用close方法关闭流对象
	在读数据过程中，如果与Datanode的通信发生错误，DFSInputStream对象会尝试从下一个最佳节点读取数据，并且记住该失败节点， 后续Block的读取不会再连接该节点
	读取一个Block之后，DFSInputStram会进行检验和验证，如果Block损坏，尝试从其他节点读取数据，并且将损坏的block汇报给Namenode。
	客户端连接哪个datanode获取数据，是由namenode来指导的，这样可以支持大量并发的客户端请求，namenode尽可能将流量均匀分布到整个集群。
	Block的位置信息是存储在namenode的内存中，因此响应位置请求非常高效，不会成为瓶颈。

	写文件流程：
	1）客户端调用DistributedFileSystem的create方法
	2）DistributedFileSystem远程RPC调用Namenode在文件系统的命名空间中创建一个新文件，此时该文件没有关联到任何block。 这个过程中，Namenode会做很多校验工作，例如是否已经存在同名文件，是否有权限，如果验证通过，返回一个FSDataOutputStream对象。如果验证不通过，抛出异常到客户端。
	3）客户端写入数据的时候，DFSOutputStream分解为packets，并写入到一个数据队列中，该队列由DataStreamer消费。
	4）DateStreamer负责请求Namenode分配新的block存放的数据节点。这些节点存放同一个Block的副本，构成一个管道。 DataStreamer将packer写入到管道的第一个节点，第一个节点存放好packer之后，转发给下一个节点，下一个节点存放，之后继续往下传递。
	5）DFSOutputStream同时维护一个ack queue队列，等待来自datanode确认消息。当管道上的所有datanode都确认之后，packer从ack队列中移除。
	6）数据写入完毕，客户端close输出流。将所有的packet刷新到管道中，然后安心等待来自datanode的确认消息。全部得到确认之后告知Namenode文件是完整的。 Namenode此时已经知道文件的所有Block信息（因为DataStreamer是请求Namenode分配block的），只需等待达到最小副本数要求，然后返回成功信息给客户端。

	Namenode如何决定副本存在哪个Datanode？
	HDFS的副本的存放策略是可靠性、写带宽、读带宽之间的权衡。默认策略如下：
	第一个副本放在客户端相同的机器上，如果机器在集群之外，随机选择一个。
	第二个副本随机放在不同于第一个副本的机架上。
	第三个副本放在跟第二个副本同一机架上，但是不同的节点上。
	更多的副本在整个集群上随机选择，虽然会尽量避免太多副本在同一机架上。
	副本的位置确定之后，在建立写入管道的时候，会考虑网络拓扑结构。下面是可能的一个存放策略：平衡了可靠性、读写性能。

	可靠性：Block分布在两个机架上。
	写带宽：写入管道的过程只需要跨越一个交换机。
	读带宽：可以从两个机架中任选一个读取。

	但是任何被写入到文件的内容不保证可见，即使对象流已经被刷新。如果需要强制刷新数据到Datanode，使用FSDataOutputStream的hflush方法强制将缓冲刷到datanode hflush之后，HDFS保证到这个时间点为止写入到文件的数据都到达所有的数据节点。关闭对象流时，内部会调用hflush方法，但是hflush不保证datanode数据已经写入到磁盘，
	只是保证写入到datanode的内存， 因此在机器断电的时候可能导致数据丢失，如果要保证写入磁盘，使用hsync方法。使用hflush或hsync会导致吞吐量下降，因此设计应用时，需要在吞吐量以及数据的健壮性之间做权衡。

	在读取和写入的过程中，namenode在分配Datanode的时候，会考虑节点之间的距离。HDFS中，距离没有采用带宽来衡量，因为实际中很难准确度量两台机器之间的带宽。Hadoop把机器之间的拓扑结构组织成树结构，并且用到达公共父节点所需跳转数之和作为距离。

	在distcp工具中，如果我们指定map数量为1，不仅速度很慢，每个Block第一个副本将全部落到运行这个唯一map的节点上，直到磁盘溢出。因此使用distcp的时候，最好使用默认的map数量，即20，HDFS在Block均匀分布在各个节点上的时候工作得最好。