Amazon/EMR上的BZip2本机拆分

Question

我们有一个关于Amazon EMR Hadoop作业的压缩输入的具体问题。

根据AWS：

Hadoop检查文件扩展名以检测压缩文件。Hadoop支持的压缩类型有：gzip、bzip2和LZO。使用这些类型的压缩来提取文件不需要采取任何额外的操作；Hadoop会为您处理

Q. V.http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/HowtoProcessGzippedFiles.html

这似乎很好——然而，研究BZip2，“拆分”边界似乎是基于文件的：

   .magic:16                       = 'BZ' signature/magic number
   .version:8                      = 'h' for Bzip2 ('H'uffman coding), '0' for Bzip1 (deprecated)
   .hundred_k_blocksize:8          = '1'..'9' block-size 100 kB-900 kB (uncompressed)
**-->.compressed_magic:48            = 0x314159265359 (BCD (pi))**
   .crc:32                         = checksum for this block
   .randomised:1                   = 0=>normal, 1=>randomised (deprecated)
   .origPtr:24                     = starting pointer into BWT for after untransform
   .huffman_used_map:16            = bitmap, of ranges of 16 bytes, present/not present
   .huffman_used_bitmaps:0..256    = bitmap, of symbols used, present/not present (multiples of 16)
   .huffman_groups:3               = 2..6 number of different Huffman tables in use
   .selectors_used:15              = number of times that the Huffman tables are swapped (each 50 bytes)
   *.selector_list:1..6            = zero-terminated bit runs (0..62) of MTF'ed Huffman table (*selectors_used)
   .start_huffman_length:5         = 0..20 starting bit length for Huffman deltas
   *.delta_bit_length:1..40        = 0=>next symbol; 1=>alter length 
   .contents:2..8                  = Huffman encoded data stream until end of block
**-->.eos_magic:48                   = 0x177245385090 (BCD sqrt(pi))**
   .crc:32                         = checksum for whole stream
   .padding:0..7                   = align to whole byte

声明中说：“与gzip一样，bzip2只是一个数据压缩器。它不像tar或ZIP那样是一个archiver；程序本身没有用于多个文件、加密或归档拆分的设施，但在UNIX传统中，这些任务依赖于单独的外部实用程序，如tar和GnuPG。”

q、 五、。，http://en.wikipedia.org/wiki/Bzip2

我将这两个语句的组合解释为意味着BZip2是“可拆分的”，但它是基于文件的 . . . .

这是相关的，因为我们的工作将通过S3接收一个~800MiB文件——这（如果我的解释是正确的）意味着EC2/Hadoop会为工作分配一个映射器（对于一个文件），这将是次优的，至少可以这么说。

（在这种情况下，我们显然需要找到一种方法，在将BZip2作为解决方案应用之前，将输入划分为一组400个文件）。

有人确切知道这是否是AWS/EMR Hadoop作业内部的功能吗？

干杯

Answer 1

据我目前所知，bzip2文件可能是可拆分的，您可以在Hadoop中实现，但在AWS EMR中仍然没有明确支持，至少不是“立即”支持。因此，如果您只是使用一个大的bzip2文件运行一个作业，那么您将在第一步得到一个映射器。我最近刚刚试过。显然，索引LZO文件也会发生这种情况，除非你使用一些黑魔法。我不确定在EMR中拆分bzip2文件是否也有相应的黑魔法。

Answer 2

在文件边界上可拆分实际上并不意味着什么，因为一个<代码>。bz2文件没有任何文件概念。

bz2流由一个4字节的报头组成，后面是零个或多个压缩块

压缩块是这里的关键。A<代码>。bz2文件可以在块边界上拆分。因此，可以创建的分割数将取决于压缩块的大小。

编辑（根据您的评论）：

Hadoop中的分割边界通常会在记录的一半发生，无论数据是否压缩<代码>文本输入格式将在HDFS块边界上拆分。诀窍在于RecordReader。

假设我们在一个文件的第10条记录中间分割了边界。读取第一个分割的映射器将读取到第10条记录的末尾，即使该记录在分配的映射器分割之外。然后，第二个映射器忽略其拆分中的第一个部分记录，因为它已经被第一个映射器读取。

只有当您在记录中获得任意字节偏移量时，您才能可靠地找到记录的结尾。