对于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之类的存档器;该程序本身不具有用于多个文件,加密或存档分割的功能,但在UNIX传统中,它依赖于在单独的外部实用程序(例如tar和GnuPG)上执行这些任务。”

q.v.,http://en.wikipedia.org/wiki/Bzip2

我认为这两个语句的组合意味着BZip2是“可拆分的”,但这样做是基于文件的。 。 。 。

这是相关的,因为我们的工作将通过S3-接收单个〜800MiB文件(如果我的解释是正确的话),这意味着EC2 / Hadoop将为该工作分配一个Mapper(对于一个文件),这将是-至少可以说是最佳的。

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

谁能确定这是否是AWS / EMR Hadoop作业内部运作的方式?

干杯!

最佳答案

由于.bz2文件没有任何文件概念,因此可以在文件边界上进行拆分实际上没有任何意义。



压缩块是这里的关键。可以在块边界上分割.bz2文件。因此,您可以创建的分割数将取决于压缩块的大小。

编辑(根据您的评论):

Hadoop中的分割边界通常可能发生在记录的一半,而不管数据是否被压缩。 TextInputFormat将在HDFS块边界上分割。诀窍在RecordReader中。

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

仅当给定记录中的任意字节偏移量时,您才能可靠地找到记录的末尾,这才有效。

07-24 09:39
查看更多