为什么HDFS中的blocksize在所有DataNode中都是一致的？
Why blocksize in HDFS is consistent in all the DataNode?
继续提问：data block size in HDFS, why 64MB?
我知道 HDFS 中的块大小在分布中的所有数据节点（大小取决于配置）中是 consistent/same。
我的问题是：
为什么这个块大小在所有NameNode中保持一致？
我问这个问题是因为，假设我有 10 台高端处理机作为 DataNode，另外有 20 台低端硬件。如果我们在这 10 台机器的 HDFS 中保留更高的块块，它可以处理得更快吗？ NameNode 也有元数据来识别 DataNode 中的块，那么机器之间块大小不一致的问题是什么？
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中数据并行的基本单位。即一个 HDFS 块由一个 CPU 核心处理。根据 DataNode 的 处理能力 对同一文件使用不同的块大小 64MB、128MB、256MB 等将无济于事，因为每个 HDFS 块将由 一个核心处理。即使是 更强大的 机器也将拥有更多的 CPU 内核而不是更快的 CPU 内核（CPU 内核的时钟速度已达到 2.5 到 3.5 左右的最大值GHz 在过去十年）。
对于某些密集的文件（或像 Parquet 这样的文件类型），具有更大的块大小是有意义的。但是根据 DataNode 将一个文件拆分为可变大小的 HDFS 块肯定没有意义。这可能就是 hadoop 设计者决定使用一致的块大小的原因。
长答案
您提到了更高端的加工机器。如今，更快的机器意味着 CPUs 具有比 CPUs 更高时钟速度 (GHz) 的内核更多。自相当长一段时间（将近十年）以来，时钟速度几乎达到了极限。速度在 2.5 到 3.5 GHz 左右达到峰值。
HDFS 上 运行 的框架，例如MapReduce、Spark 等，HDFS 的一个块由一个 CPU 核心处理。因此，更大的块仍将由那些更大的机器中的 1 个核心处理。这将使这些任务 运行 慢得多。
即使使用更高端的处理机器，每CPU核心的处理能力也将与普通相同节点。在具有更多内核的节点上存储更大的块将无济于事（这些盒子中单个内核的处理能力将与 smaller/normal 节点的处理能力相似）。
此外，还有其他一些原因导致 hadoop 设计者会决定反对它...
允许指定块大小作为@cricket_007 提到的集群范围的设置，并且可以使用 dfs.blocksize.
在每个文件的基础上覆盖
以下可能是一个文件的所有块大小一致的一些驱动因素。
- 简化配置 - 您将如何指定每个数据节点每个文件的块大小？也许比 正常 节点具有 2x 核心的节点应该具有 2x 块大小..等等。这将使配置非常困难。
- 避免数据倾斜 - 某些块大于其他块会引入数据倾斜。这直接影响数据处理框架将如何处理这些文件（根据节点具有可变块大小）。
- 简化复制 - 假设 hadoop 集群复制因子配置为 3。因此，对于每个块 - 总共需要 3 个副本。如果块大小取决于数据节点大小（计算能力），则必须至少拥有与复制因子一样多的具有相似计算能力的节点。如果只有 3 个 big 节点和 10 个 normal 节点，所有 big blocks 都需要打开大节点。
- 简化故障转移——想象一下 大 节点之一发生故障，hadoop 将无法找到另一个大节点，它可以在其中复制那些额外的 big 块以跟上复制因子。 （我们只有 3 个大节点，其中一个已经宕机）。最终，如果它将那些大块复制到 普通 节点，它将在处理能力与块大小方面引入偏差，并影响数据处理作业的性能。另一种选择是在移动到 normal 节点时拆分 big 块，这又是额外的复杂性
- 获得可预测的性能 - 数据偏差意味着很难获得可预测的性能。
这些可能是一些引入太多复杂性的原因，因此不支持此功能。
继续提问：data block size in HDFS, why 64MB?
我知道 HDFS 中的块大小在分布中的所有数据节点（大小取决于配置）中是 consistent/same。
我的问题是： 为什么这个块大小在所有NameNode中保持一致？
我问这个问题是因为，假设我有 10 台高端处理机作为 DataNode，另外有 20 台低端硬件。如果我们在这 10 台机器的 HDFS 中保留更高的块块，它可以处理得更快吗？ NameNode 也有元数据来识别 DataNode 中的块，那么机器之间块大小不一致的问题是什么？
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中数据并行的基本单位。即一个 HDFS 块由一个 CPU 核心处理。根据 DataNode 的 处理能力 对同一文件使用不同的块大小 64MB、128MB、256MB 等将无济于事，因为每个 HDFS 块将由 一个核心处理。即使是 更强大的 机器也将拥有更多的 CPU 内核而不是更快的 CPU 内核（CPU 内核的时钟速度已达到 2.5 到 3.5 左右的最大值GHz 在过去十年）。
对于某些密集的文件（或像 Parquet 这样的文件类型），具有更大的块大小是有意义的。但是根据 DataNode 将一个文件拆分为可变大小的 HDFS 块肯定没有意义。这可能就是 hadoop 设计者决定使用一致的块大小的原因。
长答案
您提到了更高端的加工机器。如今，更快的机器意味着 CPUs 具有比 CPUs 更高时钟速度 (GHz) 的内核更多。自相当长一段时间（将近十年）以来，时钟速度几乎达到了极限。速度在 2.5 到 3.5 GHz 左右达到峰值。
HDFS 上 运行 的框架，例如MapReduce、Spark 等，HDFS 的一个块由一个 CPU 核心处理。因此，更大的块仍将由那些更大的机器中的 1 个核心处理。这将使这些任务 运行 慢得多。
即使使用更高端的处理机器，每CPU核心的处理能力也将与普通相同节点。在具有更多内核的节点上存储更大的块将无济于事（这些盒子中单个内核的处理能力将与 smaller/normal 节点的处理能力相似）。
此外，还有其他一些原因导致 hadoop 设计者会决定反对它...
允许指定块大小作为@cricket_007 提到的集群范围的设置，并且可以使用 dfs.blocksize.
在每个文件的基础上覆盖以下可能是一个文件的所有块大小一致的一些驱动因素。
- 简化配置 - 您将如何指定每个数据节点每个文件的块大小？也许比 正常 节点具有 2x 核心的节点应该具有 2x 块大小..等等。这将使配置非常困难。
- 避免数据倾斜 - 某些块大于其他块会引入数据倾斜。这直接影响数据处理框架将如何处理这些文件（根据节点具有可变块大小）。
- 简化复制 - 假设 hadoop 集群复制因子配置为 3。因此，对于每个块 - 总共需要 3 个副本。如果块大小取决于数据节点大小（计算能力），则必须至少拥有与复制因子一样多的具有相似计算能力的节点。如果只有 3 个 big 节点和 10 个 normal 节点，所有 big blocks 都需要打开大节点。
- 简化故障转移——想象一下 大 节点之一发生故障，hadoop 将无法找到另一个大节点，它可以在其中复制那些额外的 big 块以跟上复制因子。 （我们只有 3 个大节点，其中一个已经宕机）。最终，如果它将那些大块复制到 普通 节点，它将在处理能力与块大小方面引入偏差，并影响数据处理作业的性能。另一种选择是在移动到 normal 节点时拆分 big 块，这又是额外的复杂性
- 获得可预测的性能 - 数据偏差意味着很难获得可预测的性能。
这些可能是一些引入太多复杂性的原因，因此不支持此功能。