HDFS常见问题

在HDFS里面，data node上的块大小默认是64MB(或者是128MB或256MB)

问题: 为何64MB(或128MB或256MB)是最优选择？

为何不能远少于64MB(或128MB或256MB) （普通文件系统的数据块大小通常为4KB）

1)减小硬盘寻道时间(disk seek time)

HDFS设计前提是支持大容量的流式数据操做，因此即便是通常的数据读写操做，涉及到的数据量都是比较大的。假如数据块设置过少，那须要读取的数据块就比较多，因为数据块在硬盘上非连续存储，普通硬盘由于须要移动磁头，因此随机寻址较慢，读越多的数据块就增大了总的硬盘寻道时间。当硬盘寻道时间比io时间还要长的多时，那么硬盘寻道时间就成了系统的一个瓶颈。合适的块大小有助于减小硬盘寻道时间，提升系统吞吐量。

2)减小Namenode内存消耗

对于HDFS，他只有一个Namenode节点，他的内存相对于Datanode来讲，是极其有限的。然而，namenode须要在其内存FSImage文件中中记录在Datanode中的数据块信息，假如数据块大小设置过少，而须要维护的数据块信息就会过多，那Namenode的内存可能就会伤不起了。

为何不能远大于64MB(或128MB或256MB)

这里主要从上层的MapReduce框架来讨论

1)Map崩溃问题：

系统须要从新启动，启动过程须要从新加载数据，数据块越大，数据加载时间越长，系统恢复过程越长。

2)监管时间问题：

主节点监管其余节点的状况，每一个节点会周期性的把完成的工做和状态的更新报告回来。若是一个节点保持沉默超过一个预设的时间间隔，主节点记录下这个节点状态为死亡，并把分配给这个节点的数据发到别的节点。对于这个“预设的时间间隔”，这是从数据块的角度大概估算的。假如是对于64MB的数据块，我能够假设你10分钟以内不管如何也能解决了吧，超过10分钟也没反应，那就是死了。可对于640MB或是1G以上的数据，我应该要估算个多长的时间内？估算的时间短了，那就误判死亡了，分分钟更坏的状况是全部节点都会被判死亡。估算的时间长了，那等待的时间就过长了。因此对于过大的数据块，这个“预设的时间间隔”很差估算。

3)问题分解问题：

数据量大小是问题解决的复杂度是成线性关系的。对于同个算法，处理的数据量越大，它的时间复杂度也就越大。

4)约束Map输出：

在Map Reduce框架里，Map以后的数据是要通过排序才执行Reduce操做的。想一想归并排序算法的思想，对小文件进行排序，而后将小文件归并成大文件的思想，而后就会懂这点了....

HDFS默认三个备份

因为hadoop的HDFS对数据文件的分布式存放是按照分块block存储，每一个block会有多个副本(默认为3)，而且为了数据的安全和高效，因此hadoop默认对3个副本的存放策略为：

第一个block副本放在和client所在的node里（若是client不在集群范围内，则这第一个node是随机选取的）。

第二个副本放置在与第一个节点不一样的机架中的node中（随机选择）。

第三个副本彷佛放置在与第一个副本所在节点同一机架的另外一个节点上

若是还有更多的副本就随机放在集群的node里。

这样的策略能够保证对该block所属文件的访问可以优先在本rack下找到，若是整个rack发生了异常，也能够在另外的rack上找到该block的副本。这样足够的高效，而且同时作到了数据的容错。

可是，hadoop对机架的感知并不是是自适应的，亦即，hadoop集群分辨某台slave机器是属于哪一个rack并不是是只能的感知的，而是须要hadoop的管理者人为的告知hadoop哪台机器属于哪一个rack，这样在hadoop的namenode启动初始化时，会将这些机器与rack的对应信息保存在内存中，用来做为对接下来全部的HDFS的写块操做分配datanode列表时（好比3个block对应三台datanode）的选择datanode策略，作到hadoop allocate block的策略：尽可能将三个副本分布到不一样的rack。