0

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

在此之前,简要总结了使用 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 中读取性能的因素集中

4

1 回答 1

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 就会比 Replication 慢。EC 会在写入路径上对 CPU 施加更大的压力,但对 IO 的压力会更小。不太清楚的是,EC 如何影响现实生活中的读取性能,其中您的 Spark 或 Hadoop 作业不跨越整个集群并且受到非数据局部性的影响。与 EC 相比,我希望 Replication 3 将提供更多空间来优化非理想配置中的数据局部性,但我无法收集对此的反馈。

于 2019-05-14T15:20:11.740 回答