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

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

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 *** 作的。想想归并排序算法的思想，对小文件进行排序，然后将小文件归并成大文件的思想

小文件是指文件大小明显小于HDFS上块（block）迟慧大小（默认64MB）的文件。如果存储小文件，必定会有大量这样的小文件，否则你也不会带旦祥使用Hadoop（If you’re storing small files, then you probably have lots of them

(otherwise you wouldn’t turn to Hadoop)），这样的文件给hadoop的扩展性和性能带来严重问题。当一个文件的大小小于HDFS的块大小（默认64MB），就将认定为小文件否则就是大文件。为了检测输入文件的大小，可以浏览Hadoop DFS 主页 http://machinename:50070/dfshealth.jsp ，并点击Browse filesystem（浏览文件系统）。

首先，在HDFS中，任何一个文件，目录或者block在NameNode节点的内存中均以一个对象表示（元数据）（Every file, directory and block in HDFS is represented as an object in the namenode’s memory），而这受到NameNode物理内存蠢搏容量的限制。每个元数据对象约占150byte，所以如果有1千万个小文件，每个文件占用一个block，则NameNode大约需要15G空间。如果存储1亿个文件，则NameNode需要150G空间，这毫无疑问1亿个小文件是不可取的。

其次，处理小文件并非Hadoop的设计目标，HDFS的设计目标是流式访问大数据集（TB级别）。因而，在HDFS中存储大量小文件是很低效的。访问大量小文件经常会导致大量的寻找，以及不断的从一个DatanNde跳到另一个DataNode去检索小文件（Reading through small files normally causes lots of seeks and lots of hopping from datanode to datanode to retrieve each small file），这都不是一个很有效的访问模式，严重影响性能。

最后，处理大量小文件速度远远小于处理同等大小的大文件的速度。每一个小文件要占用一个slot，而task启动将耗费大量时间甚至大部分时间都耗费在启动task和释放task上。

Hadoop存档文件系统通常将HDFS中的多个文件打包成一个存档文件，减少namenode内存的使用

hadoop archive命令创建HAR文件

from：https://blog.csdn.net/sunnyyoona/article/details/53870077

        大数据技术主要是要解决大规模数据的计算处理问题，但是我们要想对数据进行计算，首先要解决的其实是大规模数据的存储问题。

         如果一个文件的大小超过了一张磁盘的大小，你该如何存储？ 单机时代，主要的解决方案是 RAID ；分布式时代，主要解决方案是 分布式文件系统 。

           其实不论是在 RAID 还是 分布式文件系统 ，大规模数据存储都需要解决几个核心问题，这些问题都是什么呢？总结一下，主要有以下三个方面。       

     模薯   1. 数据存储容量的问题。 既然大数据要解决的是数以 PB 计的数据计算问题，而一般的服务器磁盘容量通常 1～2TB，那么如何存储这么大规模的数据呢？

        2. 数据读写速度的问题。 一般磁盘的连续读写速度为几十 MB，以这样的速度，几十 PB 的数据恐怕要读写到天荒地老。

        3. 数据可靠性的问题。 磁盘大约是计算机设备中最易损坏的硬件了，通常情况一块磁盘使用寿命大概是一年，如果磁盘损坏了，数据怎么办？

        RAID（独立磁盘冗余阵列）技术是将多块普通磁盘组成一个阵列，共同对外提供服务。主要是为了改善磁盘的存储容量、读写速度，增强磁盘的可用性和容错能搏码纤力。目前服务器级别的计算机都支持插入多块磁盘，通过使用 RAID 技术，实现数据在多块磁盘上的并发读写和数据备份。

        常用 RAID 技术有图中下面这几种，RAID0，RAID1，RAID10，RAID5， RAID6。

           首先，我们先假设服务器有 N 块磁盘。

            RAID 0  是数据在从内存缓冲区写入磁盘时，根据磁盘数量将数据分成 N 份，这些数据同时并发写入 N 块磁盘，使得数据整体写入速度是一块磁盘的 N 倍；读取的时候也一样，因此 RAID 0 具有极快的数据读写速度。但是 RAID 0 不做数据备份，N 块磁盘中只要有一块损坏，数据完整性就被破坏，其他磁盘的数据也都无法使用了。

            RAID 1 是数据在写入磁盘时，将一份数据同时写入两块磁盘，这样任何一块磁盘损坏都不会导致数据基仿丢失，插入一块新磁盘就可以通过复制数据的方式自动修复，具有极高的可靠性。

           结合 RAID 0 和 RAID 1 两种方案构成了 RAID 10 ，它是将所有磁盘 N 平均分成两份，数据同时在两份磁盘写入，相当于 RAID 1；但是平分成两份，在每一份磁盘（也就是 N/2 块磁盘）里面，利用 RAID 0 技术并发读写，这样既提高可靠性又改善性能。不过 RAID 10 的磁盘利用率较低，有一半的磁盘用来写备份数据。

           一般情况下，一台服务器上很少出现同时损坏两块磁盘的情况，在只损坏一块磁盘的情况下，如果能利用其他磁盘的数据恢复损坏磁盘的数据，这样在保证可靠性和性能的同时，磁盘利用率也得到大幅提升。

           顺着这个思路， RAID 3  可以在数据写入磁盘的时候，将数据分成 N-1 份，并发写入 N-1 块磁盘，并在第 N 块磁盘记录校验数据，这样任何一块磁盘损坏（包括校验数据磁盘），都可以利用其他 N-1 块磁盘的数据修复。但是在数据修改较多的场景中，任何磁盘数据的修改，都会导致第 N 块磁盘重写校验数据。频繁写入的后果是第 N 块磁盘比其他磁盘更容易损坏，需要频繁更换，所以 RAID 3 很少在实践中使用，因此在上面图中也就没有单独列出。

           相比 RAID 3， RAID 5 是使用更多的方案。RAID 5 和 RAID 3 很相似，但是校验数据不是写入第 N 块磁盘，而是螺旋式地写入所有磁盘中。这样校验数据的修改也被平均到所有磁盘上，避免 RAID 3 频繁写坏一块磁盘的情况。

            如果数据需要很高的可靠性，在出现同时损坏两块磁盘的情况下，仍然需要修复数据，这时候可以使用 RAID 6。

             RAID 6 和 RAID 5 类似 ， 但是数据只写入 N-2 块磁盘，并螺旋式地在两块磁盘中写入校验信息（使用不同算法生成）。

            从下面表格中你可以看到在相同磁盘数目（N）的情况下，各种 RAID 技术的比较。

        现在我来总结一下，看看 RAID 是如何解决我一开始提出的，关于存储的三个关键问题。

         1. 数据存储容量的问题。 RAID 使用了 N 块磁盘构成一个存储阵列，如果使用 RAID 5，数据就可以存储在 N-1 块磁盘上，这样将存储空间扩大了 N-1 倍。

         2. 数据读写速度的问题。 RAID 根据可以使用的磁盘数量，将待写入的数据分成多片，并发同时向多块磁盘进行写入，显然写入的速度可以得到明显提高；同理，读取速度也可以得到明显提高。不过，需要注意的是，由于传统机械磁盘的访问延迟主要来自于寻址时间，数据真正进行读写的时间可能只占据整个数据访问时间的一小部分，所以数据分片后对 N 块磁盘进行并发读写 *** 作并不能将访问速度提高 N 倍。

         3. 数据可靠性的问题。 使用 RAID 10、RAID 5 或者 RAID 6 方案的时候，由于数据有冗余存储，或者存储校验信息，所以当某块磁盘损坏的时候，可以通过其他磁盘上的数据和校验数据将丢失磁盘上的数据还原。

        RAID 可以看作是一种垂直伸缩，一台计算机集成更多的磁盘实现数据更大规模、更安全可靠的存储以及更快的访问速度。而 HDFS 则是水平伸缩，通过添加更多的服务器实现数据更大、更快、更安全存储与访问。

        RAID 技术只是在单台服务器的多块磁盘上组成阵列，大数据需要更大规模的存储空间和更快的访问速度。将 RAID 思想原理应用到分布式服务器集群上，就形成了 Hadoop 分布式文件系统 HDFS 的架构思想。

---