问题标签 [erasure-code]

Java - 什么是擦除 - 擦除对泛型施加了哪些 4 个限制？

我正在尝试对可以应用于文件的编码技术进行调查，然后再将其存储在云中。到目前为止，我只在文献中遇到过 Reed Solomon 擦除编码机制。

我想知道是否有人可以指出是否也可以应用其他技术，例如无速率代码，包括 LT 代码或 raptor 代码。

如果有人知道对不同编码机制进行的调查，并且如果您能指出这一点，那就太好了。

谢谢

巴维亚

是否有一个纠删码，可以通过（以某种方式）添加冗余块来应用于多个块（可能是 100 或 200，每个几百 kB）？

我听说过 Reed-Solomon，但它看起来不能用于大型数据集和多个块，我错了吗？

谢谢！

嘿，我对很多擦除编码概念都很陌生。我大多只读过 Reed-solomon，但它不符合我的需要。

我需要找到一种可以在不占用大量系统资源的情况下在大数据上创建奇偶校验分片的技术。

例如：

我想存储一个 32gb 的视频，分割成 8 个 4gb 的碎片。我想为此创建 3 个奇偶校验分片。我最多不能超过几百 MB 的内存，并且我希望增量创建整个奇偶校验分片，以便我可以将它们写入另一个文件系统，而无需将整个内容存储在内存/本地磁盘上。

是否有擦除编码技术，所以我可以：

• 在不使用大量内存的情况下为大型文件创建奇偶校验分片
• 通过在创建字节时发送字节来增量创建奇偶校验分片并将其分发到另一个系统。

我正在寻找一种在 Apache HDFS 中创建文件（例如使用 copyFromLocal）并在此过程中设置擦除编码策略的方法。

根据这个页面，我可以hdfs ec --setPolicy -path <folder> -policy RS-6-3-1024k用来设置目录及其子目录的策略。有没有办法在创建文件时为文件设置策略，而不依赖于父级的策略？

根据 Hadoop 3.x 发行说明，他们引入了擦除编码来克服存储问题。

纠删码是一种持久存储数据的方法，与复制相比可节省大量空间。与标准 HDFS 复制的 3 倍开销相比，像 Reed-Solomon (10,4) 这样的标准编码有 1.4 倍的空间开销。

由于纠删码在重建过程中会产生额外的开销并且主要执行远程读取，因此它传统上用于存储较冷、访问频率较低的数据。用户在部署此功能时应考虑纠删码的网络和 CPU 开销。

我正在寻找相同的示例配置文件。

此外，即使在设置了 ec 策略并使用 启用它之后hdfs ec-enablePolicy，该策略是否仅适用于冷文件，还是默认实现以存储整个 hdfs 文件？

在 hadoop 2.0 中，默认的复制因子是 3。可接受的节点故障数是 3-1=2。
因此，在 100 个节点的集群上，如果一个文件被分成 10 个部分（块），复制因子为 3，则所需的总存储块为 30。如果包含块 X 及其副本的任何 3 个节点失败，则文件为不可恢复。即使集群有 1000 个节点或文件被分成 20 个部分，集群上 3 个节点的故障仍然可能对文件造成灾难性影响。

现在步入hadoop 3.0。
使用纠删码，正如 Hadoop 所说，它提供了相同的持久性和 50% 的存储效率。并且基于 Reed-Solomon 方法的工作原理（即对于 k 个数据块和 n 个奇偶校验块，至少应可访问 (k+n) 个块中的 k 个，以使文件可恢复/可读）
所以对于上面的同一个文件——有10个数据块，为了将数据效率保持在50%，可以添加5个奇偶校验块。因此，从 10+5 个块中，至少有 10 个块应该可供文件访问。而在 100 个节点的集群上，如果 15 个块中的每一个都存储在一个单独的节点上，那么如您所见，总共 5 个节点故障是可以接受的。现在在 1000 个节点的集群上存储相同的文件（即 15 个块）不会对可接受的节点故障的数量产生任何影响 - 它仍然是 5。
但这里有趣的部分是 - 如果相同的文件（或另一个文件）被分割分成 20 个块，然后添加 10 个奇偶校验块，然后在 100 个节点的集群上总共保存 30 个块，可接受的节点故障数为 10。

我想在这里说明的一点是 -
在 hadoop 2 中，可接受的节点故障数是 ReplicationFactor-1，并且显然基于复制因子。这是一个集群范围的属性。

但是在 hadoop 3 中，假设存储效率固定为 50%，那么对于不同的文件来说，可接受的节点故障数似乎是不同的，具体取决于它被分成的块数。

那么，如果上述推论正确，任何人都可以发表评论吗？以及如何确定任何集群可接受的节点故障？

（而且我不想让它在上面变得复杂，所以没有讨论只有一个块的文件的边缘情况。但我猜该算法将足够聪明，可以按原样复制它或使用奇偶校验数据复制它，以便数据持久性设置得到保证。）

编辑： 这个问题是我对 EC 提出的一系列问题的一部分 - 其他问题如下 -
Hadoop 3.0 擦除编码：对 MR 作业性能的影响？

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

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

我正在尝试设置 Hadoop 3 集群。

关于擦除编码功能的两个问题：

1. 如何确保启用纠删码？
2. 我还需要将复制因子设置为 3 吗？

请注明与纠删码/复制相关的相关配置属性，以获得与 Hadoop 2 相同的数据安全性（复制因子 3），但具有 Hadoop 3 纠删码的磁盘空间优势（仅 50% 开销而不是 200%） .

使用https://github.com/klauspost/reedsolomon，将一个大文件擦除编码成更小的块，我想用它io.Pipe()来创建一个相互连接的管道流。例如：一个管道有助于对文件进行分块，另一个管道调用 func Upload 来上传文件

我对使用io.Pipe()