为什么HDFS中的块大小在所有DataNode中都是一致的？

Question

继续提问：data block size in HDFS, why 64MB?

我知道HDFS中的块大小在分布中的所有数据节点（大小取决于配置）中一致/相同。

我的问题是： 为什么这个块大小在所有NameNode中保持一致？

我问这个问题是因为，我说有10个高端处理机作为DataNode，另有20个低端硬件。如果我们在这10台机器的HDFS中保留更高的块块，它可以更快地处理吗？ NameNode也有元数据来识别DataNode中的块，那么机器之间块大小不一致的问题是什么？

Answer 1

  

假设我有10个高端处理机作为DataNode，另有20个低端硬件。如果我们在这10台机器的HDFS中保留更高的块块，它可以更快地处理吗？

简答

HDFS块是hadoop中数据并行的基本单位。即，一个CPU核处理一个HDFS块。根据DataNode的处理能力，对于同一文件具有不同的块大小64MB，128MB，256MB等将无济于事，因为每个HDFS块将由一个核处理。即使是功能更强大的机器也会拥有更多的CPU内核而不是更快的CPU内核（CPU内核的时钟速度在过去十年中已达到2.5到3.5 GHz左右）。

对于某些文件（或像Parquet这样的文件类型）更加密集，有更大的块大小是有意义的。但是根据DataNode将一个文件拆分为可变大小的HDFS块当然没有意义。这可能就是为什么hadoop设计师决定采用一致的块尺寸。

长答案

您提到了高端处理机。如今，更快的机器意味着CPU具有比具有更高时钟速度（GHz）的CPU更多的内核。从很长一段时间（差不多十年）开始，时钟速度几乎达到了极限。速度达到了2.5到3.5 GHz的峰值。

在HDFS上运行的框架，例如MapReduce，Spark等，一块HDFS由一个CPU核心处理。因此，较大的块仍将由那些较大的机器中的1个核心处理。这将使这些任务运行得慢得多。

即使使用高端处理机，每CPU核心处理能力也会与普通节点相同。在具有更多核心数的节点上存储更大的块将无济于事（这些盒子中的各个核心的处理能力将与较小/正常节点的处理能力相似）。

此外，还有一些其他原因让hadoop设计师决定反对它......

允许指定块大小作为群集范围的设置，如@ cricket_007所述，以及使用dfs.blocksize在每个文件的基础上覆盖。

以下可能是一个驱动因素，为什么一个文件的所有块都具有一致的大小。

1. 简化配置 - 您如何为每个文件指定每个数据节点的块大小？也许具有2x核心而不是普通节点的节点应该具有2x块大小等等。这将使配置非常困难。
2. 避免数据偏斜 - 让一些块大于其他块会引入数据偏斜。这直接影响数据处理框架如何处理这些文件（根据节点具有可变块大小）。
3. 简化复制 - 想象一下hadoop集群复制因子被配置为3.因此，对于每个块 - 需要总共3个副本。如果块大小取决于数据节点大小（计算能力），则必须使至少具有与复制因子具有相似计算能力的节点数量。如果只有3个大节点和10个普通节点，则所有大块都需要位于大节点上。
4. 简化故障转移 - 想象一下大节点之一，hadoop将无法找到另一个大节点，它可以复制那些额外的大块以跟上复制因素。 （我们只有3个大节点，其中一个节点已经关闭）。最终，如果它将这些大块复制到普通节点，它将在处理能力与块大小方面引入偏差并影响数据处理作业的性能。另一种方法是在移动到普通节点时拆分大块，这又是额外的复杂性
5. 获得可预测的性能 - 数据的偏差意味着很难获得可预测的性能。

这可能是引入太多复杂性的一些原因，因此不支持此功能。