hadoop - 为什么HDFS中的 block 大小在所有DataNode中都一致？

Question

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

我知道在分发中的所有数据节点中，HDFS中的块大小为一致/相同(大小取决于配置)。

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

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

Answer 1

let say I have 10 higher end processing machine as DataNode and another 20 lower end hardware. If we keep higher chunks of blocks in HDFS of those 10 machines can it process faster?

简短答案
HDFS块是hadoop中数据并行的基本单位。即1个HDFS块由1个CPU内核处理。取决于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在每个文件的基础上覆盖。
以下可能是一些驱动因素，为什么对于一个文件，所有块都具有一致的大小。

简化配置-如何为每个文件的每个数据节点指定块大小？也许具有比普通节点2x核心的节点应该具有2x块大小。等等。这会使配置非常困难。

避免数据偏斜-具有比其他更大的某些块会引入数据偏斜。这直接影响到数据处理框架如何处理这些文件(这些文件的块大小取决于节点)。

简化复制-假设将hadoop集群方式的复制因子配置为3。因此，对于每个块-总共需要3个副本。如果块大小取决于数据节点的大小(计算能力)，则必须使具有与复制因子相似的计算能力的节点数量最少。如果只有3个大节点和10个普通节点，则所有大块将需要位于大节点上。

简化故障转移-想象一个大节点发生故障，hadoop将无法找到另一个大节点，该节点可以在其中复制这些额外的 big 块以跟上复制因子。 (我们只有3个大节点，其中一个已关闭)。最终，如果将这些大块复制到普通节点，则会在处理能力与块大小方面引入偏斜，并影响数据处理作业的性能。另一种选择是在移至普通节点时将大块拆分，这又是

的额外复杂性

获得可预测的性能-数据偏斜意味着很难获得可预测的性能。

这些可能是导致过多复杂性的某些原因，因此不支持此功能。