hdfs详解之块、小文件和副本数

1、block：block是物理切块，在文件上传到HDFS文件系统后，对大文件将以每128MB的大小切分若干，存放在不同的DataNode上。例如一个文件130M，那么他会存被切分成2个块，一个块128M，另一个块2M.

1、HDFS 适应场景: 大文件存储，小文件是致命的

2、如果小文件很多的，则有可能将NN(4G=42亿字节)撑爆。例如:1个小文件(阈值<=30M),那么NN节点维护的字节大约250字节。一亿个小文件则是250b * 1亿=250亿.将会把NN节点搜念撑爆。如果世兄困一亿个小文件合并成100万个大文件:250b * 1百万=2亿字节。

3、在生产上一般会:

1）调整小文件阈值

2）合并小文件:

a.数据未落地到hdfs之前合并

b.数据已经落到hdfs，调用spark service服务 。每天调度去合并 （-15天 业务周期）

3）小文件的危害:

a.撑爆NN。

b.影响hive、spark的计算。占用集群计算资源

1、如果是伪分布式，那么副本数只能为一。

2、生成上副本数一般也是官方默认参数尘枝: 3份

如果一个文件130M，副本数为3。那么第一个block128M，有三份。另外一个block2M，也有三份。

题目:

blockSize128M,副本数3份，那么一个文件260M，请问多少块，多少实际存储？

260%128=2....4M 3个块 3个副本=9块

260M 3=780M

打开Ambari看到hdfs报警[alert]: Total Blocks:[*], Missing Blocks:[*] , 发现是烂掘祥有些文件块损坏了. 启动hdfs的时候发现也起不来了, 日志一直循环下散余面的东西.

NameNode一直处于安全模式

打开NameNode UI可以看到如下的描述:

说明我们的损坏的文件比例超过了阈值, 这个阈值配置在hdfs中, 下图是从Ambari的饥搏配置管理, 这里配置的是100%, 也就是说不允许任何一个块损坏掉. 如果我们配置成99%应该就不会触发safemode了.

块的大小设置原则：最小化寻址开销。

HDFS的块比磁盘的块大(磁盘的块一般为512字节)，其目的是为了最小化寻址开销

然而真正实际开发中要把block设置的远大于128MB，比如存储文件是1TB时，一般把Block大小设置成512MB.但是也不能任意设置的太大，比如200GB一个，因为在MapReduce的map任务中通常一次只处理一个块中数据（切片大小默认等于block大小）， 如果设置太大， 因为任务数太少（少于集群中的节点数量），那么作业的运行速度就会慢很多，此外比如故障等原因也会拖慢速度。

如何设置块的大小？

主要由以下考虑：

参考： HDFS块大小默认为什么是64MB(或者是128MB）

主要由以下考虑：

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

HDFS设计前提是支持大容量的流式数据 *** 作，所以即使是一般的数据读写 *** 作，涉及到的数据量都是比较大的孙物。假如数据块设置过少，那需要读取的数据块就比较多，由于数据块在硬盘上非连续存储，普通硬盘因为需要移动磁头，所以随机寻址较慢，读越多的数据块就增大了总的硬盘寻道时间。当硬盘寻道时间比io时间还要长的多时，那么硬盘寻道时间就成了系统的一个瓶颈。合适的块大小有助于减少硬盘寻道时间，提高系统吞吐量。传输一个由多个块的组成的文件取决于磁盘传输速率。如寻址时间约为10ms，传输速率为100MB/S，羡凯差为了使寻址时间仅占传输时间的1%，块的大小设置约为100MB，兄皮默认大小是64MB，现在在实际身缠中都是128MB了，随着新一代磁盘去东区传输速率的提升，块的大小将会被设置的更大。

减少Namenode内存消耗

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

Map崩溃问题：

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

监管时间问题：

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

问题分解问题：

数据量大小是问题解决的复杂度是成线性关系的。对于同个算法，处理的数据量越大，它的时间复杂度也就越大。块的大小太大的话，一个map任务处理一个块，那任务数就变少了，作业运行速度也就变慢了。

约束Map输出：

在Map Reduce框架里，Map之后的数据是要经过排序才执行Reduce *** 作的。想想归并排序算法的思想，对小文件进行排序，然后将小文件归并成大文件的思想

---