HDFS (分布式文件系统)，默认的最忌本的存储单位是64M（可修改通过修改hdfs-core.xml文件内容来改变hdfs的块大小时，在修改后上传的文件会使用新设置的数据块大小）
顺手找了一下为1.什么 是64M
2.能不能少于64M
3.如果过大呢
《1》.减少硬盘寻道时间
HDFS设计的初衷是支持大容量的流式数据操作，所以即使一般的数据读写操作，涉及的数据量也很大数数据块在硬盘上的存储并未连续存储的。普通硬盘因为需要移动磁头，所以随机寻址比较慢，数据快越多，读取数据块的时间就越久（主要是增加了硬盘的寻道时间）。
《2》.减少Namenode内存消耗
Namenode（元数据节点）用来管理文件系统的命名空间其将所有的文件和文件夹的元数据保存在文件系统树中，还保存了一个文件包括那些数据块，分布在那些数据节点上。对于HDFS来说，只有一个Namenode节点，他的内存对于Datanode来说极其有限，然而namenode需要在其内存FSImage文件中记录在Datanode中的数据块信息，假如数据块大小设置过小，那么需要维护的数据块信息就会过多，那么对Namenode的内存消耗是一个很大的问题。
《3》既然数据块的大小设置的太小不利与Namenode 的内存管理，那么设置的过大呢？
这个要从MapReduce的 框架来考虑
Map崩溃问题 系统需要重启，启动过程需要重新加载数据，数据块越大，数据加载时间越长，系统恢复时间越长。
监管时间问题 主节点监管其他节点的情况，每个节点会周期性的把完成的每个工作个状态更新报告回来，如果一个节点超过预设的时间，主节点就判断该节点为死亡状态，并把该节点的任务分配给其他节点。对于“预设时间间隔” 是从数据块的大小 来估算的，加入对于64Mb的数据块，假设十分钟之内可以解决，超过十分钟即判断位死亡。对于更大的数据块1G 或者更对，这个估算时间不好判断。估算过长，等待的时间就越长，估算过短，最坏的情况可能造成所有的节点都被判断为“死亡”
