一、HDFS就像一位“成熟的男人”，他有故事
在Hadoop2.0的时代，HDFS的默认块Block大小为128MB，原来是有深层原因的。（据说面试题经常问这个）
如果Block块太小，一个大文件被分成了若干个小Block，则需要花费很多时间用于Block文件的寻址，浪费了时间。
而Block块太大，则会降低处理效率。如MapReduce将块作为一个map处理单元，如果只有一个块，则同时只有一台服务器进行计算，剩下的服务器将无事可做，而干活的这台服务器因处理的数据量大也非常累。
那为什么默认是128MB呢？与服务器的磁盘传输速度有关。经过测算，寻址时间/传输时间=1/100为最佳处理状态。一般寻址时间在10ms，数据传输时间在1000ms合适，一般SATA磁盘的传输速率在150MB/s。取近似值，Block Size因此正好设在128MB。简单而言，磁盘的速度越高，Block设置越大，如SSD盘，可以设置为512MB大小。
二、HDFS像“有规则的男人”，也充满原则
HDFS适合处理大数据，上传后的数据不能被灵活修改。
1 因数据是分布在廉价的服务器上存储，扩展能力强。能够处理GB、TB、PB级别的数据。
2 能够处理百万以上规模的文件。因关联表存放在NameNode的内存中，内存越大，能够保存的数据量越大。最小的文件关联数据也在150byte。
3 不适合低延时业务的访问。每次的HDFS数据访问都需要通过NameNode寻址。
4 不支持并发写入、不支持文件随机修改。往HDFS写数据，同时只能有一个线程写，并不能并发写入。最重要的是：写入HDFS后的数据，不能再被任意修改，只能支持append追加操作。
因此HDFS适合数据的长期保存、适合大数据的非实时分析场景，不适合保存需要随时修改数据的应用场景。
三、HDFS像“有顾家的男人”，也有主人翁感
HDFS读、写数据全部需访问NameNode节点，并且是串行读、写数据。（据说面试题经常问这个）
1 HDFS客户端（如web网页、client程序）需向HDFS中写数据时，首先访问NameNode，其向客户端返回三个DataNode节点地址。一般DN1是与客户端最近的节点，DN2是同机架节点，DN3是不同机架节点。
为了减轻HDFS客户端的压力，向DataNode1写数据成功后，由DataNode1向直接向DataNode2写数据。
2 HDFS客户端（如web网页、client程序）需从HDFS中读数据时，首先访问NameNode，其向客户端返回保存了其数据的DataNode节点地址清单。需要注意的是：不是并行从DN节点中读数据，而是串行读数据，除非所有的数据都保存在同一个DN中才是并行读取。
四、一山不能容二虎，HDFS系统家里只有一个男主人
我以前一直认为SecondaryNameNode是NameNode的备份，但完全错误。（据说面试题经常问这个）
实际SecondaryNameNode只做了一件事，帮助NameNode节点计算硬盘中的存量数据+新增数据的和。NameNode基于内存进行元数据的管理，并将数据落盘至硬盘中，为了避免硬盘文件过大，造成处理速度慢。因此NameNode将数据分为定期的存量数据（FSimage）、及时的新增数数据（FSimage）。SecondaryNameNode就帮助定期把存量数据、新增数据加起来形成新的存量数据返回给NameNode。