hadoop - 压缩格式和分隔符序列

Question

我的问题是:有没有什么标准的压缩格式可以保证压缩后的数据流中不会出现某个定界符序列？

我们想设计一个二进制文件格式，包含大块的顺序数据(3D 坐标 + 其他数据，对问题来说并不重要)。每个 block 都应使用标准压缩格式进行压缩，例如 GZIP、ZIP、...

因此，文件结构如下:

FileHeader
ChunkDelimiter Chunk1_Header compress(Chunk1_Data)
ChunkDelimiter Chunk2_Header compress(Chunk2_Data)
...

用例如下:文件应该在Hadoop中拆分读取，所以我们希望能够从文件中的任意字节位置开始，并通过查找分隔符序列找到下一个 block 的开始. -> 分隔符序列不应出现在 block 内。

我知道我们可以对压缩数据进行后处理，“转义”分隔符序列，以防它出现在压缩输出中。但我们最好避免这种情况，因为在解码器中需要“反向转义”，增加复杂性。

我们选择这种文件格式的更多事实:

• 应易于第三方阅读 -> 首选标准压缩算法。
• 大文件；流操作:开始写入文件时不知道数据量和 block 数 -> 难以在 header 中写入 block 开始字节位置。

Answer 1

我不会用压缩方案名称来回答您的问题，但会提示您其他人是如何解决相同问题的。

让我们来看看 Avro。基本上，它们有类似的要求:文件必须是可拆分的，每个数据 block 都可以压缩(您甚至可以选择您的压缩方案)。

来自Avro Specification我们了解到可拆分性是在同步标记的帮助下实现的(“对象存储在可以压缩的 block 中。在 block 之间使用同步标记以允许高效地拆分文件以进行 MapReduce 处理。”) .我们还发现同步标记是一个16 字节 随机生成 值(“该文件的 16 字节随机生成的同步标记。").

它如何解决您的问题？好吧，由于 Martin Kleppmann 几年前对这个问题提供了很好的答案，所以我将复制粘贴他的信息

On 23 January 2013 21:09, Josh Spiegel wrote:

As I understand it, Avro container files contain synchronization markers every so often to support splitting the file. See: https://cwiki.apache.org/AVRO/faq.html#FAQ-Whatisthepurposeofthesyncmarkerintheobjectfileformat%3F

(1) Why isn't the synchronization marker the same for every container file? (i.e. what is the point of generating it randomly every time)

(2) Is it possible, at least in theory, for naturally occurring data to contain bytes that match the sync marker? If so, would this break synchronization?

Thanks, Josh

1. 因为如果它是可预测的，它有时会不可避免地出现在实际数据中(例如想象一下 Avro 文档，说明 同步标记是什么，由网络爬虫下载并存储在 Avro 数据文件；然后同步标记将出现在实际 数据)。数据可能来自恶意来源；使标记随机 使其无法被利用。

2. 可能，但极不可能。给定的随机 16 字节字符串出现在拍字节(均匀分布)数据中的概率 大约是 10^-23。您的数据中心更有可能被摧毁 陨石 (http://preshing.com/20110504/hash-collision-probabilities)。

3. 如果同步标记出现在您的数据中，只有当您碰巧也在文件中查找该位置时，它才会中断读取文件。如果你只是 按顺序阅读它，没有任何反应。

马丁

Link to the Avro mailing list archive

如果它适用于 Avro，那么它也适用于您。