我试图理解擦除编码对文件读取性能的影响。
在此之前简要总结了hadoop3.0中使用reed-solomon方法的擦除编码。如果一个被分割成k个块的文件被编码成p个奇偶校验块，那么k+p块中至少有k个块可用于重新创建文件。在hadoop2.0中，默认的复制是3，因此一个10块的文件在集群上需要30块空间。hadoop3.0声明它提供了50%的空间缩减，因此同样的10个块在3.0上存储时应该只需要15个块，即额外的5个块可以用作奇偶校验块。
在hadoop3.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中，是否应该将上述因素（擦除编码）也添加到可能影响读取性能的因素集中