HDFS 配置容量高于磁盘容量
HDFS Configured Capacity higher than disk capacity
我在 Centos 上有一个带有 Cloudera Express 5.11 的 11 节点集群。最初它仅由 7 个节点组成；稍后又添加了 4 个节点。每个节点的磁盘容量都相同：5.4 TB.
我遇到的问题是 hdfs dfsadmin -report 命令显示了错误的磁盘使用值，尤其是配置容量。我的值在前 7 个节点中为 6.34 TB，在后 4 个节点中为 21.39 TB。
例如，在一个节点中，我有以下报告：
Decommission Status : Normal
Configured Capacity: 23515321991168 (21.39 TB)
DFS Used: 4362808995840 (3.97 TB)
Non DFS Used: 14117607018496 (12.84 TB)
DFS Remaining: 3838187159552 (3.49 TB)
DFS Used%: 18.55%
DFS Remaining%: 16.32%
Configured Cache Capacity: 2465202176 (2.30 GB)
Cache Used: 0 (0 B)
Cache Remaining: 2465202176 (2.30 GB)
Cache Used%: 0.00%
Cache Remaining%: 100.00%
运行 dfs.data.dir 文件夹上的 df 命令向我显示 DFS Used 值（不是百分比）是正确的，但其他值有偏差。我读到 HDFS 可能显示的值不是最新的，但我几天来一直看到相同的值，即使在重新启动所有服务和所有机器之后也是如此。
最让我烦恼的是：
- 配置容量比真实容量高（我只有 5 TB，它怎么能推断出 21 TB？）
- 我对两组节点分别有两个不同的值
产生这些值的原因可能是什么？有没有办法修复它们？
PS：我问这个的原因是，如果值错误，HDFS 会低估 DFS Used%，因此无法重新平衡节点中的文件。事实上，我为其发布价值的节点有：
DFS Used：~4 TB（正确）DFS Used%：~19%（错误）
其他每个节点都有：
DFS Used：~2 TB（正确）DFS Used%：从11%到28%不等（错误）
这使得受控节点的 DFS Used% 低于平均值，因此 HDFS 的平衡器推断该节点不应重新平衡。
PS2：我注意到的一件事是第一组节点有 Centos 6.9，而第二组节点有 Centos 6.8。这会以某种方式导致问题吗？
更新
一年半后，我找到了问题的真正根源。
原因是我在HDFS的dfs.datanode.data.dir参数中列出了几个目录。显然，HDFS 是通过将每个目录的容量相加来估计 Configured capacity 的。问题是：如果两个目录在同一个分区，那个分区的大小会被认为是两倍！奇怪的是，我在文档中没有发现任何提及。
这给我带来了问题，因为第一组机器有 4 个 HDFS 目录分配给 3 个分区，每个分区大约 1.8T（因此只有一个被考虑两次），而第二组机器有 4 个 HDFS 目录分配到 1 个约 5.4TB 的分区（因此乘以 4！）。
最终，问题是机器的异构分区配置的结果 + HDFS 的一些低级细节没有正确记录。
我最终在 Cloudera 中创建了两组 HDFS 目录配置：一组用于第一组机器（有 3 个目录，每个分区一个）和一组用于第二组（在唯一的分区中有一个目录）。由于涉及数据重新平衡，请谨慎执行此操作。
原回答
What could be the causes for these values?
经过一些研究，这个问题似乎是在集群更新了新资源（即新磁盘或新节点）时发生的，因为 HDFS 使用所有集群的总容量更新了相关数据节点的配置容量涉及Datanodes（即，当我们升级前7个节点的磁盘时，每个节点的容量成为集群的总容量；当我们再增加4个节点时，每个新节点的容量成为新节点的总容量）。这可能是由于 Cloudera Manager 造成的吗？可能（这是我的猜测），但我没有证据。
And is there a way to fix them?
我阅读了 Hadoop 的 Java 代码以了解节点配置容量的值是从哪里获取的，它似乎来自 Namenode 的命名空间映像（这是一个二进制文件，AFAIK , 它是不可编辑的)。
我最后做的是停用不平衡的节点（这会触发其块在其余节点上的复制），删除此类节点上的 HDFS 数据，重新启用它并重新平衡数据。这不是我正在寻找的解决方案，但至少它让我的数据正确地重新平衡了。
我在 Centos 上有一个带有 Cloudera Express 5.11 的 11 节点集群。最初它仅由 7 个节点组成；稍后又添加了 4 个节点。每个节点的磁盘容量都相同：5.4 TB.
我遇到的问题是 hdfs dfsadmin -report 命令显示了错误的磁盘使用值，尤其是配置容量。我的值在前 7 个节点中为 6.34 TB，在后 4 个节点中为 21.39 TB。
例如，在一个节点中，我有以下报告：
Decommission Status : Normal
Configured Capacity: 23515321991168 (21.39 TB)
DFS Used: 4362808995840 (3.97 TB)
Non DFS Used: 14117607018496 (12.84 TB)
DFS Remaining: 3838187159552 (3.49 TB)
DFS Used%: 18.55%
DFS Remaining%: 16.32%
Configured Cache Capacity: 2465202176 (2.30 GB)
Cache Used: 0 (0 B)
Cache Remaining: 2465202176 (2.30 GB)
Cache Used%: 0.00%
Cache Remaining%: 100.00%
运行 dfs.data.dir 文件夹上的 df 命令向我显示 DFS Used 值（不是百分比）是正确的，但其他值有偏差。我读到 HDFS 可能显示的值不是最新的，但我几天来一直看到相同的值，即使在重新启动所有服务和所有机器之后也是如此。
最让我烦恼的是：
- 配置容量比真实容量高（我只有 5 TB，它怎么能推断出 21 TB？）
- 我对两组节点分别有两个不同的值
产生这些值的原因可能是什么？有没有办法修复它们？
PS：我问这个的原因是，如果值错误，HDFS 会低估 DFS Used%，因此无法重新平衡节点中的文件。事实上，我为其发布价值的节点有：
DFS Used：~4 TB（正确）DFS Used%：~19%（错误）
其他每个节点都有：
DFS Used：~2 TB（正确）DFS Used%：从11%到28%不等（错误）
这使得受控节点的 DFS Used% 低于平均值，因此 HDFS 的平衡器推断该节点不应重新平衡。
PS2：我注意到的一件事是第一组节点有 Centos 6.9，而第二组节点有 Centos 6.8。这会以某种方式导致问题吗？
更新
一年半后，我找到了问题的真正根源。
原因是我在HDFS的dfs.datanode.data.dir参数中列出了几个目录。显然，HDFS 是通过将每个目录的容量相加来估计 Configured capacity 的。问题是：如果两个目录在同一个分区，那个分区的大小会被认为是两倍！奇怪的是，我在文档中没有发现任何提及。
这给我带来了问题，因为第一组机器有 4 个 HDFS 目录分配给 3 个分区，每个分区大约 1.8T（因此只有一个被考虑两次），而第二组机器有 4 个 HDFS 目录分配到 1 个约 5.4TB 的分区（因此乘以 4！）。
最终，问题是机器的异构分区配置的结果 + HDFS 的一些低级细节没有正确记录。
我最终在 Cloudera 中创建了两组 HDFS 目录配置：一组用于第一组机器（有 3 个目录，每个分区一个）和一组用于第二组（在唯一的分区中有一个目录）。由于涉及数据重新平衡，请谨慎执行此操作。
原回答
What could be the causes for these values?
经过一些研究，这个问题似乎是在集群更新了新资源（即新磁盘或新节点）时发生的，因为 HDFS 使用所有集群的总容量更新了相关数据节点的配置容量涉及Datanodes（即，当我们升级前7个节点的磁盘时，每个节点的容量成为集群的总容量；当我们再增加4个节点时，每个新节点的容量成为新节点的总容量）。这可能是由于 Cloudera Manager 造成的吗？可能（这是我的猜测），但我没有证据。
And is there a way to fix them?
我阅读了 Hadoop 的 Java 代码以了解节点配置容量的值是从哪里获取的，它似乎来自 Namenode 的命名空间映像（这是一个二进制文件，AFAIK , 它是不可编辑的)。
我最后做的是停用不平衡的节点（这会触发其块在其余节点上的复制），删除此类节点上的 HDFS 数据，重新启用它并重新平衡数据。这不是我正在寻找的解决方案，但至少它让我的数据正确地重新平衡了。