我试图了解删除编码可能对文件的读取性能产生的影响。
在此之前，简要总结了使用 Reed-Solomon 方法的 Hadoop 3.0 删除编码。如果将分割成 k 个 block 的文件编码为 p 个奇偶校验 block ，则在 k+p 个 block 中，至少任何 k 个 block 必须可用于重新创建文件。在 Hadoop 2.0 中，默认复制是 3，因此 10 个 block 的文件需要集群上 30 个 block 的空间。 Hadoop 3.0 声明它提供了 50% 的空间减少，因此相同的 10 个 block 存储在 3.0 上时应该只需要 15 个 block ，即额外的 5 个 block 可以用作奇偶校验 block 。
在 Hadoop 3.0 - 一个包含 10 个 block 的文件 (file1) 将导致 5 个奇偶校验 block (以 3.0 中的 EC 的数据改进为 50%)。假设原始的 10 个数据 block 存储在从 n0 到 n9 的节点上，而 5 个奇偶校验 block 存储在节点 n10 到 n14 上。
现在对该文件的读取操作肯定应该从前 10 个节点获取数据，即 n0 到 n9 因为从具有奇偶校验 block 的节点获取数据可能需要更多时间，因为它涉及解码(对吗？？)。
接下来，此文件可接受的节点故障数为 5。
如果节点 n10 - n14 失败(这些是具有奇偶校验 block 的节点)。读取操作的性能(由于节点故障)不会受到影响，性能与上述场景相同。
但是如果节点 n5 到 n9 发生故障，那么我会猜测这种情况下的读取性能会低于上述情况下的性能。
但是在 2.0 中，只要节点故障的数量小于 ReplicationFactor-1，无论哪个节点发生故障，您都可以获得相同的性能。
问题是:是否应该将上述因素(删除编码)也添加到可能影响 3.0 中读取性能的因素集中
最佳答案
您看过这些演示文稿了吗？
https://fr.slideshare.net/HadoopSummit/debunking-the-myths-of-hdfs-erasure-coding-performance
https://fr.slideshare.net/HadoopSummit/hdfs-erasure-coding-in-action
只要有坏 block ，EC 就会比 Replication 慢。
EC 会在写入路径上对 CPU 施加更大的压力，但对 IO 的压力会更小。
不太清楚的是，EC 如何影响现实生活中的读取性能，因为您的 Spark 或 Hadoop 作业不跨越整个集群并且不受数据局部性的影响。
与 EC 相比，我希望 Replication 3 将提供更多空间来优化非理想配置中的数据局部性，但我无法收集对此的反馈。
关于Hadoop 3.0 删除编码 : impact on file read performance?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50399215/