hadoop不支持传统文件系统的挂载，使得流式数据装进hadoop变得复杂。
hadoo中，文件只是目录项存在；在文件关闭前，其长度一直显示为0：如果在一段时间内将数据写到文件却没有将其关闭，则若网络中断后，则我们得到的仅仅是一个空白文件；故：最好编写小文件，这样能尽快将其关闭-----错误。
【mapper 单个文件块 1:1】
由于hdfs的元数据保存在NameNode的内存中，因此创建的文件越多，所需的RAM就越多。从MapReduce角度看，小文件会导致效率低下。通常情况下，，每个Mapper都会被分配单个文件块作为
输入（除非使用了某些压缩编码）。如果过多的小文件，那么与待处理的数据相比，与待处理的数据相比，启动工作进程的代价就过高。这种碎片会导致更多的Mapper任务，使得总的Job运行时间增加。
【内存的容量严重制约了集群的扩展】
0-在HDFS中，任何Block、文件或者目录在内存中均以对象的形式存储，每个对象约占150Byte。若有1千万小文件，每个小文件占用1个Block，则NameNode约需要2GB空间：内存的容量严重制约了集群的扩展；
1-HDFS最初是为流式访问大文件而开发的，如果访问大量小文件，则需要不断从一个DataNode跳到另一个DataNode，严重影响了性能，导致最后处理大量小文件的速度远远小于处理同等大小的大文件的速度；每个文件要占用一个Solt，而Task启动将消耗大量的时间，从而导致大部分时间都耗费在启动和释放Task上。
【客户端 自身机制】
用户程序合并：
0-HadoopArchive SequenceFile CombineFileInputFormat
Q1、HDFS可以存储比单个磁盘空间还要大的文件吗？如果可以，什么原理？
Q2、HDFS是怎么实现数据的高可用（High Availability，HA）？
Q3、HDFS中让块分布在同一机架还是多个机架？
参考资料
(1)
HDFS特点：
1、大文件
大，huge，以兆字节为单位，100+MB；
小文件影响HDFS的性能的原因：元数据会消耗主节点NameNode的大量内存；
2、顺序访问
HDFS上的读和写操作都应该按照顺序处理。
只要文件的读取时有序的，MapReduce和其他执行引擎就可以高效地、任意次数地读取HDFS上的文件。
(2)
块抽象
块，block，由于存储文件的块抽象，你可以存储任意大小的文件。
块大小，blocksize，默认128MB。一个100MB的文件仅会占用一个HDFS块上的100MB。块会分布在多个节点上，可以存储比单个磁盘空间还要大的文件。
(3)
大多数系统通过（通常2个节点之间）复制整个数据结构来支持数据的高可用HA：这确保了如果其中一个节点或数据源失效了，另一个节点或数据的副本仍然可用的。
HDFS通过数据块的抽象在此基础上做了扩展，实现了2次改进：
i、默认情况下，HDFS想数据复制2次（而非1次），使得每个块共有3个副本；
ii、HDFS并不是把节点A上的所有块复制到节点B，而是吧这些块分布到多个节点之上；
示例：
HDFS把块默认复制2次至3个不同节点。
(4)
Hadoop components are rack-aware.
机架感知、Rack Awareness。
数据中心的机器通常放在机架或者某些用于承载服务器的容器中。一个机架上可以放置很多台机器。这些机器通宵场距离很近而且网络上下文中也很近。
相同机架上机器之间的连接通常比跨机器之间的连接更高效。通过向HDFS提供这种无理架构，分布式系统的性能和弹性都会得到改善。
可以让块分布在同一机架的多个节点上，这样连通性不收网络带宽的限制。
但让块分布在多个机架张，这样即使整个机架上的服务器全部失效，也可以保证块的数据不丢失。