我试图了解纠删码可能对文件读取性能产生的影响。
在此之前，简要总结一下使用Reed-Solomon方法的Hadoop 3.0擦除编码。如果拆分为 k 个块的文件被编码为 p 奇偶校验块，则至少 k+p 块中必须有任何 k 个块可用于重新创建该文件。在 Hadoop 2.0 中，默认复制为 3，因此 10 块文件在集群上需要 30 块空间。Hadoop 3.0 声明它提供了 50% 的空间减少，因此当存储在 3.0 上时，相同的 10 个块应该只需要 15 个块，即额外的 5 个块可以用作奇偶校验块。
在Hadoop 3.0中- 具有10个块的文件(file1)将导致5个奇偶校验块(在3.0中使用EC的数据改进为50%)。假设最初的 10 个数据块存储在从 n0 到 n9 的节点上，5 个奇偶校验块存储在节点 n10 到 n14 上。 现在，对此文件的读取操作肯定应该从前 10 个节点(即 n0 到 n9)获取数据，因为从具有奇偶校验块的节点获取数据可能需要更多时间，因为它涉及解码(对吗？？
接下来，此文件的可接受节点故障数为 5。
如果节点 n10 - n14 发生故障(这些是具有奇偶校验块的节点)。读取操作的性能(由于节点故障)不会受到影响，性能与上述场景相同。
但是如果节点 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
一旦出现坏块，EC 将比复制慢。 EC 会在写入路径上对 CPU 施加更大的压力，但对 IO 的压力较小。 不太清楚的是，EC 如何影响现实生活中的读取性能，其中您的 Spark 或 Hadoop 作业不会跨越整个集群，并且不会受到数据局部性的影响。与EC相比，我希望复制3在非理想配置中提供更多空间来优化数据局部性，但我无法收集有关此的反馈。