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

Question

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

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

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

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

Answer 1

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

简答

HDFS 块是 hadoop 中数据并行的基本单位。即一个 HDFS 块由一个 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 在每个文件的基础上覆盖。

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

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

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