HDFS/Hadoop的默认数据块大小为64MB。磁盘中的块大小通常为4KB。
64MB块大小是什么意思？ ->这是否意味着从磁盘读取的最小单位为64MB？
如果是，这有什么优点？ ->易于在HDFS中连续访问大文件？
我们能否使用磁盘原始的4KB块大小来做同样的事情？
8个回答
82
64MB块大小是什么意思？
块大小是文件系统可以存储的最小数据单元。如果您存储的文件大小为1k或60Mb，则将占用一个块。一旦超过64Mb的边界，您需要第二个块。
如果使用64MB块大小，有什么好处？
HDFS旨在处理大文件。假设您有一个1000Mb的文件。使用4k块大小，您需要进行256,000个请求才能获取该文件（每个块1个请求）。在HDFS中，这些请求经过网络并伴随着大量开销。每个请求必须由Name Node处理，以确定可以找到该块的位置。这是很多流量！如果使用64MB块，则请求数量减少到16，从而显着降低了开销和对Name Node的负载。
- bstempi
18
4谢谢您的提问。假设块大小为4KB，文件在磁盘上连续存储，那么为什么我们不能使用一个请求检索1000MB的文件？我知道目前HDFS可能不支持这种访问方法，但是这种访问方法存在什么问题呢？ - dykw
1对于小文件而言，假设你有一堆1k的文件，而你的块大小是4k。这意味着每个文件浪费了3k的空间，这并不好。但在HDFS中并非如此。比如说，如果文件大小为100MB，则块大小为64MM和36BM。通常情况下，最后一个块的大小会小于64MB的倍数。 - Praveen Sripati
4这个回答完全错误。"块"或"块大小"的意思取决于文件系统，在HDFS的情况下，它不是可以存储的最小单位，而是namenode引用的最小单位。块通常按顺序存储在物理磁盘上，这使得读写块变得更快。对于小文件，块大小并不重要，因为它们将比块大小小并作为一个更小的块存储。因此，较大的块大小通常更好，但必须权衡所需的数据量和映射器分布。 - David Ongaro
1@DavidOngaro说块大小是namenode引用的最小单位是正确的...我的解释有点过于简化了。但我不确定为什么这会使答案“完全错误”。 - bstempi
1使用更大的块大小的目标是减少对名称节点的请求次数。 因此，有人会说，“我在哪里可以找到这个文件？”名称节点会说：“您可以在这里找到这个64Mb块，以及这个块等。”请求者将前往存储每个块的每个位置，并说：“嘿，请给我一份那个块的副本。” HDFS识别为块的内容与底层FS不同。 如果底层FS使用4k块，则该64Gb块将占用约6700万个块。 这没关系，因为它们的延迟很低，不像对名称节点的延迟。 - bstempi
显示剩余13条评论
25
HDFS的设计最初受到Google文件系统（GFS）设计的启发。以下是原始GFS论文中关于大块大小的两个原因（注1：GFS术语与HDFS术语不同，chunk = block，chunkserver = datanode，master = namenode；注2：粗体格式为我的）：
大块大小具有几个重要优点。首先，它减少了客户端与主服务器的交互，因为在相同块上的读写仅需要一次初始请求以获取块位置信息。这种减少对我们的工作负载特别重要，因为应用程序主要按顺序读写大文件。[...]其次，由于在大块上，客户端更有可能对给定块执行多个操作，因此可以通过在较长时间内保持与块服务器的持久TCP连接来减少网络开销。第三，它减小了存储在主节点上的元数据的大小。这使我们能够将元数据保存在内存中，从而带来其他优点，我们将在第2.6.1节中讨论。
最后，我应该指出Apache Hadoop中当前默认大小为128 MB（请参见dfs.blocksize）。
大块大小具有几个重要优点。首先，它减少了客户端与主服务器的交互，因为在相同块上的读写仅需要一次初始请求以获取块位置信息。这种减少对我们的工作负载特别重要，因为应用程序主要按顺序读写大文件。[...]其次，由于在大块上，客户端更有可能对给定块执行多个操作，因此可以通过在较长时间内保持与块服务器的持久TCP连接来减少网络开销。第三，它减小了存储在主节点上的元数据的大小。这使我们能够将元数据保存在内存中，从而带来其他优点，我们将在第2.6.1节中讨论。
最后，我应该指出Apache Hadoop中当前默认大小为128 MB（请参见dfs.blocksize）。
- cabad
4
在HDFS中，块大小控制着复制分散的级别。块大小越小，数据块就更均匀地分布在DataNode上。块大小越大，您的数据在集群中的分布可能就不那么平均了。
那么相比低值而言，选择更高的块大小有什么意义呢？理论上，数据的平均分布是一件好事，但是块大小过小会有一些明显的缺点。NameNode的容量有限，因此如果块大小为4KB而不是128MB，则需要存储的信息量也会增加32768倍。MapReduce也可以通过在更多的NodeManager和CPU核心上启动更多的map任务来受益于均匀分布的数据，但是在实践中，由于无法执行顺序，缓冲读取以及每个map任务的延迟，理论上的优势将会丧失。
那么相比低值而言，选择更高的块大小有什么意义呢？理论上，数据的平均分布是一件好事，但是块大小过小会有一些明显的缺点。NameNode的容量有限，因此如果块大小为4KB而不是128MB，则需要存储的信息量也会增加32768倍。MapReduce也可以通过在更多的NodeManager和CPU核心上启动更多的map任务来受益于均匀分布的数据，但是在实践中，由于无法执行顺序，缓冲读取以及每个map任务的延迟，理论上的优势将会丧失。
- mutantacule
2
“MapReduce也可以通过在更多的NodeManager和更多的CPU核心上启动更多的map任务来从均匀分布的数据中获益” - 这意味着MapReduce任务适用于大量数据？ - Tom Taylor
我不太明白你的意思，但实际上，由于不能执行顺序缓冲读取以及每个映射任务的延迟，理论上的好处将会丧失。你能否详细说明一下？ - Tom Taylor
3
在普通操作系统中，块大小为4K，在Hadoop中为64MB。这是为了方便Namenode维护元数据。
假设我们在Hadoop中只有4K的块大小，而我们正在尝试将100MB的数据加载到这个4K中，那么我们需要更多的4K块。并且Namenode需要维护所有这些4K块的元数据。
如果我们使用64MB的块大小，则数据将仅加载到两个块（64MB和36MB）中。因此，元数据的大小减小了。
结论： 为了减轻Namenode的负担，HDFS首选64MB或128MB的块大小。 Hadoop 1.0的默认块大小为64MB，而Hadoop 2.0的默认块大小为128MB。
假设我们在Hadoop中只有4K的块大小，而我们正在尝试将100MB的数据加载到这个4K中，那么我们需要更多的4K块。并且Namenode需要维护所有这些4K块的元数据。
如果我们使用64MB的块大小，则数据将仅加载到两个块（64MB和36MB）中。因此，元数据的大小减小了。
结论： 为了减轻Namenode的负担，HDFS首选64MB或128MB的块大小。 Hadoop 1.0的默认块大小为64MB，而Hadoop 2.0的默认块大小为128MB。
- Shivakumar
1
Hadoop选择64MB的原因是因为Google选择了64MB。
Google选择64MB的原因是由于一个Goldilocks（小熊维尼）论点：
如果块大小要小得多，将导致查找开销增加。
将块大小适度缩小可以使映射任务运行得足够快，以至于调度它们的成本与运行它们的成本相当。
块大小显着增大开始减少可用的读并行性，并最终可能使本地任务调度变得困难。
参见Google研究发表: MapReduce http://research.google.com/archive/mapreduce.html
- steven
1
这已经在我的答案中提到了。最好是在我的答案中添加评论，而不是发布一个几乎没有增加任何内容的答案。 - cabad
1
- 如果块大小设置小于64，则整个集群中会有大量的块，这将导致NameNode管理大量的元数据。
- 由于我们需要为每个块提供一个Mapper，因此会有很多Mapper，每个Mapper处理一小部分数据，并不高效。
- dpaluy
2
我同意(1)，但不同意(2)。框架可以（默认情况下）让每个映射器处理多个数据块。 - cabad
1每个映射器处理的是一个分片，而不是一个块。此外，即使将一个映射器分配给N个块的分片，分片的结尾可能是部分记录，导致记录读取器（这对于每个记录读取器都是特定的，但通常适用于Hadoop附带的读取器）从下一个块中读取剩余的记录。重点是，映射器经常跨越块边界。 - bstempi
1
这与硬盘驱动器（HDD）的磁盘寻道有更多关系。随着时间的推移，与磁盘吞吐量相比，磁盘寻道时间并没有取得很大的进展。因此，当块大小较小时（导致太多块），会有太多磁盘寻道，效率不高。随着我们从HDD向SDD发展，磁盘寻道时间变得没有太多意义，因为SSD中有运动部件。
另外，如果块太多，将会给Name Node带来压力。请注意，Name Node必须在内存中存储整个元数据（关于块的数据）。在Apache Hadoop中，默认块大小为64 MB，在Cloudera Hadoop中默认为128 MB。
- Praveen Sripati
12
2如果将64MB的HDFS块分割成多个4KB的块，那么使用64MB的HDFS块有什么意义呢？ - dykw
2减少节点服务器的负载。跟踪较少的块=较少的请求和较少的内存跟踪块。 - bstempi
Apache Hadoop的当前默认大小为128 MB。 - cabad
1那么对于顺序访问来说，块大小为64或128没有任何优势吗？因为每个块可能会被分成多个本地文件系统块？ - sab
2@Basil Paul，这是一个非常好的问题。意图是从底层文件系统获取连续的块。在生产环境中，HDFS有自己的卷，因此获取连续的块不是问题。如果您将其与其他存储（如mapreduce临时数据等）混合使用，则会出现问题。我不确定它是如何管理的。您可能需要打开代码并查看它是如何管理的。 - Rags
显示剩余7条评论
1
以下是《Hadoop权威指南》第三版（第45页）的解释：
HDFS块为什么这么大？
HDFS块与磁盘块相比较大，原因在于最小化寻道成本。通过使块足够大，从磁盘传输数据的时间可以显著长于寻找块的起始位置所需的时间。因此，由多个块组成的大文件的传输时间以磁盘传输速率运行。
快速计算表明，如果寻道时间约为10毫秒，传输速率为100 MB/s，则要使寻道时间占传输时间的1％，我们需要将块大小设置为约100 MB。默认值实际上为64 MB，尽管许多HDFS安装使用128 MB块。随着新一代磁盘驱动器的传输速度增加，这个数字将继续向上修订。
然而，这个论点不应被过分强调。MapReduce中的Map任务通常一次处理一个块，因此，如果您的任务数量太少（少于集群中的节点数），则作业的运行速度将比其本来可以达到的速度慢。
- deepSleep
1
能否将多个小文件（比如1KB大小的文件）存储在一个64MB的块中？如果我们可以在一个块中存储多个小文件，那么如何读取块中第n个文件呢？文件指针会被定位到特定的“第n个文件”偏移位置吗？还是在读取第n个文件内容之前会跳过前面的n-1个文件？ - Tom Taylor
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接