一：hadoop为什么不适合处理大量的小文件，怎么解决？
原因：
1：文件的元数据（包括文件被分成了哪些blocks，每个block存储在哪些服务器的哪个block块上），都是存储在namenode上的内存，会对namenode的内存造成压力；
2： 文件过多会造成文件的定位时间（又称寻址时间）增大；
3：监管时间问题：
dataNode会向NameNode发送两种类型的报告：增量报告和全量报告。
增量报告是当dataNode接收到block或者删除block时，会向nameNode报告。
全量报告是周期性的，NN处理100万的block报告需要1s左右，这1s左右NN会被锁住，其它的请求会被阻塞。
解决方法：合并大量小文件。
公司的解决方法是在每天凌晨一点的时候，对前一天的所有小文件进行合并。通过mr进行实现。
二：怎么修改块的大小
hdfs-site.xml的参数dfs.block.size
三：块太大的问题：
1：mapreduce中的map任务通常一次只处理一个块中的数据，因此如果任务数太少（少于集群中节点的数量），运行速度会很慢。
2：Map崩溃问题（不太明白，希望明白之人指出）
系统需要重新启动，启动过程需要重新加载数据，数据块越大，数据加载时间越长，系统恢复过程越长。
3：监管时间问题。主节点监管其他节点的情况，每个节点会周期性的与主节点进行汇报通信。倘若某一个节点保持沉默的时间超过一个预设的时间间隔，主节点会记录这个节点状态为死亡，并将该节点的数据转发给别的节点。而这个“预设时间间隔”是从数据块的角度大致估算的。（加入对64MB的数据块，我可以假设你10分钟之内无论如何也能解决完了吧，超过10分钟还没反应，那我就认为你出故障或已经死了。）64MB大小的数据块，其时间尚可较为精准地估计，如果我将数据块大小设为640MB甚至上G，那这个“预设的时间间隔”便不好估算，估长估短对系统都会造成不必要的损失和资源浪费。
:4：问题分解问题。数据量的大小与问题解决的复杂度呈线性关系。对于同一个算法，处理的数据量越大，时间复杂度越高。
四：HDFS分块抽象的好处
1 文件大小可以大于任意一个磁盘的容量，块并不需要存储在同一个磁盘上
2 抽象块作为存储单元，简化存储子系统的设计
1) datanode将块作为处理对象，能存储多少块也能计算出
2) namenode管理元数据
3 数据备份提高容错能力和可用性
五：namenode和datanode（管理者-工作者模式）
namenode作用：
1-管理文件系统的命名空间。维护这文件系统树和整棵树的所有文件和目录；
保存在磁盘上；
2-块的元数据信息，保存在内存中。
datanode的作用：
1：根据需要存储并检索数据块（需求来自客户端 或 namenode调度）；
2：定期向namenode发送他们所存储的块的列表。
secondDatanode的作用：
1：合并fsimage和fsedits然后再发给namenode。
因为namenode，文件系统无法使用，并且会有丢失文件信息，所以需要对namenode进行容错机制，方法：
1-冗余备份，把文件系统元数据以为持久化的方式进行备份。
2-secondNameNode冷备份；但状态总滞后于namenode，难免会丢失数据。namenode死后，secondNameNode会转化为datanode
六：单点故障