HDFS的特点

优点：
1）处理超大文件
　　这里的超大文件通常是指百MB、数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。

2）流式的访问数据

*　　HDFS的设计建立在更多地响应”一次写入、多次读取”任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

3）运行于廉价的商用机器集群上

　　Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性，安全性及高可用性。

缺点：
1）不适合低延迟数据访问
如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。

2）无法高效存储大量小文件

　　因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。

1280M 1个文件 10block*150字节 = 1500 字节 =1.5KB
1280M 12.8M 100个 100个block*150字节 = 15000字节 = 15KB

3）不支持多用户写入及任意修改文件
　　在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。

二、HDFS的读写流程
在hdfs中，将数据存入hdfs的时候，会把数据分成一个一个的block，在hadoop2.x中，一个block默认是128M

rack1   rack2   rack3NN      DN3     DN6DN1     DN4     DN7DN2     DN5     DN8File:200M2个blockblock1:128Mblock2:72M流式写入:1.将block1分成一个一个的package,将package1发送给DN12.DN1接受完package1，自己存一份，再将package1发送给DN2    同时，接收client发送来的package23.DN2接收完package1，自己存一份，再将package1发送给DN4...4.当block1接收完毕，DN1，DN2，DN4向NN汇报消息(接收完毕),DN1再向client汇报block1接收完毕，于是，client开始发送block2.5....hdfs读取1.client会想NameNode发送读取请求，NameNode会将元数据查出来，每一个数据存在的位置发给client2.client会优先从本地去读取数据，如果本地不存在数据，会从元数据记录的第一个存储位置DN开始读取，读取完毕再开始按照block的顺序读取最近的DN上的数据3.将文件的各个block按照顺序读取完毕，形成了整个文件4.关闭输入输出流