bzip2本机拆分

gcuhipw9  于 2021-06-03  发布在  Hadoop
关注(0)|答案(2)|浏览(377)

我们有一个关于amazonemrhadoop作业的压缩输入的问题。
根据aws:
“hadoop检查文件扩展名以检测压缩文件。hadoop支持的压缩类型有:gzip、bzip2和lzo。您不需要采取任何额外的行动来提取文件使用这些类型的压缩;hadoop为您处理它。”
q、 五、。,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只是一个数据压缩器。它不是一个像焦油或拉链档案;该程序本身没有用于多个文件、加密或存档拆分的功能,但在unix传统中,这些任务依赖于单独的外部实用程序,如tar和gnupg。”
q、 五、。,http://en.wikipedia.org/wiki/bzip2
我认为这两个语句的组合意味着bzip2是“可拆分的”,但它是以文件为基础的。
这是相关的,因为我们的作业将通过s3接收一个~800mib文件——这(如果我的解释是正确的)意味着ec2/hadoop将为作业分配一个Map器(对于一个文件),这至少是次优的。
(在这种情况下,在将bzip2作为解决方案应用之前,我们显然需要找到一种将输入划分为一组400个文件的方法)。
有人知道这是否是aws/emr hadoop作业内部的工作方式吗?
干杯!

13z8s7eq

13z8s7eq1#

据我目前所知,bzip2文件可能是可拆分的,您可以在hadoop中实现,但在aws emr中仍然不支持它,至少“现在”不支持。因此,如果您只是用一个大的bzip2文件运行一个作业,那么您将在第一步得到一个Map器。我最近刚试过。显然,索引的lzo文件也会发生这种情况,除非你使用黑魔法。我不确定是否有相应的黑魔术分裂bzip2文件在电子病历了。

r6l8ljro

r6l8ljro2#

自从 .bz2 文件没有任何文件的概念。
一个.bz2流包含一个4字节的头,后跟零个或多个压缩块
压缩块是这里的关键。一 .bz2 可以在块边界上拆分文件。因此,可以创建的拆分数目将取决于压缩块的大小。
编辑(根据您的评论):
hadoop中的分裂边界经常会出现在记录的中间,不管数据是否被压缩。 TextInputFormat 将在hdfs块边界上拆分。诀窍在于 RecordReader .
假设我们在一个文件的第10条记录中间有一个分割边界。读取第一个分割的Map器将读取到第10条记录的结尾,即使该记录的结尾超出了Map器分配的分割。然后,第二个Map器忽略其拆分中的第一个部分记录,因为它已经被第一个Map器读取。
只有在给定记录的任意字节偏移量的情况下,才能可靠地找到记录的结尾。

相关问题