Hadoop 3.0擦除编码：对文件读取性能的影响？

Question

我试图了解擦除编码可能对读取文件性能产生的影响。

在此之前使用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中读取性能的因素集

Answer 1

您看过这些演示文稿吗？

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相比，Replication 3在非理想配置中将提供更多的空间来优化数据局部性，但是我无法收集有关此问题的反馈。