HDFS理论分析

1.1设计前提和目标：
１）硬件错误是常态而不是异常。错误检测并快速自动恢复是HDFS的最核心设计目标
２）流式数据访问。运行在HDFS上的应用主要是以流式读为主，做批量处理；更注重数据访问的高吞吐量。
３）超大规模数据集。HDFS的一般企业级的文件大小可能都在TB级别或者PB级别，支持大文件存储，而且提供整体上高的数据传输带宽，一个单一的HDFS实例应该能支撑数以千万计的文件，并且能在一个集群里扩展到数百个节点。
４）简单一致性模型。HDFS的应用程序一般对文件实行一次性读写、多次读的访问模式。
５）移动计算比移动数据更简单。对于大文件来说，移动数据比移动计算的代价要高。操作海量数据时效果越加明显，这样可以提高系统的吞吐量和减少网络的拥塞。
６）异构软硬平台间的可移植性。这种特性便于HDFS作为大规模数据应用平台的推广。

1.2体系结构

HDFS是一个主从结构的体系，HDFS集群有一个NameNode（Master)和很多个DataNode (Slaves)组成。NameNode管理文件系统的元数据，DataNode存储实际的数据。客户端联系NameNode以获取文件的元数据，而真正的文件I/O操作是直接和DataNode进行交互的。
NameNode就是主控制服务器，负责 维护文件系统的命令空间并 协调客户端对文件的访问， 记录命名空间内的任何改动或命名空间本身的属性改动。

DataNode负责他们所在的物理节点上的存储管理，HDFS开放文件系统的命名空间以便让用户以文件形式存储数据。HDFS的数据都是“一次写入，多次读取”，典型的大小是64M，HDFS的文件通常是按照64M分成不同的数据块（Block)，每个数据块尽可能地分散存储于不同的DataNode中。

NameNode执行文件系统的命名空间操作，比如打开、关闭、重命名文件或目录，还决定数据块到DataNode的映射。DataNode负责处理客户的读写请求，依照NameNode的命令，执行数据块的创建、复制、删除等工作。例如客户端要访问一个文件，首先，客户端从NameNode获得组成文件的数据块的位置列表，也就是知道数据块被存储在哪些DataNode上然后客户端直接从DataNode上读取文件数据。NameNode不参与文件的传输。
HDFS典型的部署是在一个专门的机器上运行NameNode，集群中的其他机器各运行一个DataNode；也可以在运行NameNode的机器上同时运行DataNode,或者一台机器上运行多个DataNode。这种一个集群只有一个NameNode的设计大大简化了系统架构。

1.3日志和fsimage工作原理

NameNode使用事务日志（EditLog)记录HDFS元数据的变化，使用映像文件（FsImage)存储文件系统的命名空间，包含文件的映射、文件的属性信息等。事务日志和映像文件都存储在NameNode的本地文件系统。

secondaryNameNode负责,从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，同时重置NameNode的edits.

NameNode启动时，从磁盘中读取映像文件和事务日志，把事务日志的事务都应用到内存的映像上，然后将新的元数据刷新到本地磁盘的新的应先该文件中，这样可以截取旧的事务日志，这个过程称为检查点（CheckPoint)。HDFS还有Secondary NameNode节点，它辅助NameNode处理映像文件和事务日志。NameNode启动的时候合并映像文件和事务日志，而Secondary NameNode会有周期地从NameNode上复制映像文件和事务日志到临时目录，合并生成新的映像文件后再重新上传到NameNode，NameNode更新映像文件并清理事务日志，使得事务日志的大小始终控制在可配置的限度下。

1.4hdfs的数据流操作

读文件

写文件

1.5保障可靠性的措施
HDFS的主要设计目标之一就是在故障情况下也能保证数据存储的可靠性。HDFS具备了较为完善的冗余备份和故障恢复机制[http://cn.hadoop.org/doc/hdfs_design.html]，可以实现在集群中可靠地存储海量文件。
1.5.1冗余备份
HDFS将每个文件存储成一系列数据块，默认块大小为64M（可配置）。为了容错，文件的所有数据块都会有副本（副本数量即复制因子也可配置）。 HDFS的文件都是一次性写入的，并且严格限制为任何时候都只有一个写用户。DataNode使用本地文件系统存储HDFS的数据，但是它对HDFS的文件一无所知，只是用一个个文件存储HDFS的每个数据块。当DataNode启动时，它会遍历本地文件系统，产生一份HDFS数据块和本地文件对应关系的列表，并把这个报告发给NameNode,这就是快报告（Blockreport)。快报告包括了DataNode上所有块的列表。

1.5.2机架感知
HDFS集群一般运行在多个机架上，不同机架上的通信需要通过交换机。通常情况下，副本的存放策略很关键，机架内节点之间的带宽比跨机架节点之间的带宽要大，他能映像HDFS的可靠性和性能。HDFS采用机架感知（Rack-aware)的策略来改进数据的可靠性、可用性和网络带宽的利用率。通过机架感知，NameNode可以确定每个DataNode所属的机架ＩＤ。一般情况下，当复制因子是３的时候，HDFS的部署策略是将一个副本放在同一机架上的另一个节点，一个副本存放在本地机架上的节点，最后一个副本放在不同机架上的节点。机架的错误远比节点的错误少，这个策略可以防止整个机架失效时数据丢失，不会映像倒数据的可靠性和可用性，又能保证性能。

1.5.3心跳检测
NameNode周期性地从集群中的每个DataNode接受心跳包和块报告，收到心跳包说明该DataNode工作正常。NameNode会标记最近没有心跳的DataNode为死机，不会发给他们任何新的I/O请求。任何存储在死机的DataNode的数据将不再有效，DataNode的死机会造成一些数据块的副本数下降并低于指定值。NameNode会不断检测这些需要复制的数据块，并在需要的时候重新复制。重新复制的引发可能有多种原因，比如DataNode不可用、数据副本的损坏、DataNode上的磁盘错误或复制因子增大等。

1.3.4安全模式
系统启动时，NameNode会进入一个安全模式。此时不会出现数据块的写操作。NameNode会收到各个DataNode拥有的数据块列表对的数据块报告，因此NameNode获得所有的数据块信息。数据块达到最小副本数时，该数据块就被认为是安全的。在一定比例(可配置）的数据块被NameNode检测确认是安全之后，再等待若干时间，NameNode自动推出安全模式状态。当检测到副本数不足的数据块时，该块会被复制到其他数据节点，以达到最小副本数。

1.5.5数据完整性检测
多种原因会造成从DataNode获取的数据块有可能是损坏的。HDFS客户端软件实现了对HDFS文件内容的校验和(Checksum)检查，在HDFS文件创建时，计算每个数据块的校验和，并将校验和作为一个单独的隐藏文件保存在命名空间下。当客户端获取文件后，它会检查从DataNode获得的数据块对应的校验和是否和隐藏文件中的相同，如果不同，客户端就会认为数据块有损坏，将从其他DataNode获取该数据块的副本。

1.5.6空间回收
文件被用户或应用程序删除时，并不是立即就从HDFS中移走，而是先把它移动到/trash目录里。只要还在这个目录里，文件就可以被迅速恢复。 文件在这个目录里的时间是可以配置的，超过了这个时间，系统就会把它从命名空间中删除。文件的删除操作会引起相应数据块的释放，但是从用户执行删除操作到从系统中看到剩余空间的增加可能会有一个时间延迟。只要文件还在/trash目录里，用户可以取消删除操作。当用户想取消时，可以浏览这个目录并取回文件，这个目录只保存被删除文件的最后一个副本。这个目录还有一个特性，就是HDFS会使用特殊策略自动删除文件。当前默认的策略是：文件超过6个小时后自动删除，在未来版本里，这个策略可以通过定义良好的接口来配置。

1.5.7映像文件和事务日志多副本
映像文件和事务日志是HDFS的核心数据结构。如果这些文件损坏，将会导致HDFS不可用。NameNode可以配置为支持维护映像文件和事务日志的多个副本，任何对映像文件或事务日志的修改，都将同步到他们的副本上。这样会降低NameNode处理命名空间事务的速度，然而这个代价是可以接受的，因为HDFS是数据密集，而非元数据密集的。当NameNode重新启动时，总是选择最新的一致的映像文件和事务日志。在HDFS集群中NameNode是单点存在的，如果它出现故障，必须手动干预。目前，还不支持自动重启或切换到另外的NameNode。

1.5.8快照
快照支持存储在某个时间的数据复制，当HDFS数据损坏时，可以回滚到过去一个已知正确的时间点。HDFS目前还不支持快照功能。

1.4提升性能的措施
HDFS被设计为支持非常大的文件，他的应用都是处理大数据集的。高效的数据存储也是Hadoop的优点之一。
1.4.1副本选择
HDFS会尽量使用离程序最近的副本来满足用户请求，这样可以减少总带宽消耗和读延时。如果在读取程序的同一个机架有一个副本，那么就使用这个副本;如果HDFS集群跨了多个数据中心，那么读取程序将有限考虑本地数据中心的副本。
1.4.2负载均衡
HDFS的架构支持数据均衡策略。如果某个DataNode的剩余磁盘空间下降到一定程度，按照均衡策略，系统会自动把数据从这个DataNode移动到其他节点。当出现对某文件有很高的需求是，系统可能会启动一个计划创建该文件的副本，并重新平衡集群中的其他数据。目前这些均衡策略还没有实现。
1.4.3客户端缓存
客户端创建文件的请求不是立即到达NameNode，HDFS客户端先把数据缓存到本地的一个临时文件，程序的写操作透明地重定向到这个临时文件。当这个临时文件累积的数据超过一个块的大小时，客户端才会联系NameNode。NameNode在文件系统中插入文件名，给他分配一个数据块，告诉客户端DataNode的ID和目标数据块ID，这样客户端就把数据从本地的缓存刷新到指定的数据块中。当文件关闭后，临时文件中剩余的未刷新数据也会被传输到DataNode中，然后客户端告诉NameNode文件已关闭，此时NameNode才将文件创建操作写入日志进行存储。如果NameNode在文件关闭之前死机，那么文件将会丢失。如果不采用客户端缓存，网络速度和拥塞都会对输出产生很大的影响。
1.4.4流水线复制
当客户端要写数据到HDFS的文件中时，就像前面介绍的那样，数据一开始会写入本地临时文件。假设该文件的复制因子是3,当本地临时文件累积到一个数据块的大小时，客户端会从NameNode获取一个副本存放的DataNode列表，列表中的DataNode都将保存那个数据块的一个副本。客户端首先向第一个DataNode传输数据，第一个DataNode一小块一小块（4KB）地接受数据，写入本地哭的同时，把接受到的数据传输给列表中的第二个DataNode;第二个DataNode以同样的方式边收边传，把数据传输给第三个DataNode;第三个DataNode把数据写入本地库。DataNode从前一个节点接受数据的同时，即时把数据传给后面的节点，这就是流水线复制。 dfs.replication=3,dfs.replication.min=1，只要写入了一个成功了就认为成功，其他的副本会在集群中异步复制完成。

1.5hadoop IO

1.5.1 数据完整性 采用crc-32(循环冗余校验)数据校验

1.5.2 压缩 

压缩两大好处：1、减少空间存储2、减少网络传输。在hadoop中这两点很重要，所以要仔细衡量压缩。

压缩格式	工具	算法	文件扩展名	多文件	可分割性	Java 实现	本地实现
DEFLATE	无	DEFLATE	.deflate	不	不	是	是
gzip	gzip	DEFLATE	.gz	不	不	是	是
bzip2	bzip2	bzip2	.bz2	不	是	是	否
LZO	lzop	LZO	.lzo	不	不	否	是

1.5.3 序列化

Hadoop Writable接口是基于DataInput和DataOutput实现的序列化协议，紧凑（高效使用存储空间），快速（读写数据、序列化与反序列化的开销小）。Hadoop中的键（key）和值（value）必须是实现了Writable接口的对象（键还必须实现WritableComparable，以便进行排序）。

Java对序列化提供了非常方便的支持，在定义类的时候，如果想让对象可以被序列化，只要在类的定义上加上了”implements Serializable”即可，比如说，可以这么定义”public class Building implements Serializable”，其他什么都不要做，Java会自动的处理相关一切。Java的序列化机制相当复杂，能处理各种对象关系。

Java的序列化机制的缺点就是计算量开销大，且序列化的结果体积大太，有时能达到对象大小的数倍乃至十倍。它的引用机制也会导致大文件不能分割的问题。这些缺点使得Java的序列化机制对Hadoop来说是不合适的。于是Hadoop设计了自己的序列化机制。