Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1557014675.1226536424359.JavaMail.jira@brutus>
Date: Wed, 12 Nov 2008 16:33:44 -0800 (PST)
From: "Chris Douglas (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-4640) Add ability to split text files
 compressed with lzo
In-Reply-To: <1143552581.1226498264396.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647139#action_12647139 ] 

Chris Douglas commented on HADOOP-4640:
---------------------------------------

Good idea
* On LzopCodec: Removing the unused bufferSize field is clearly useful. The condition protected against by decompressedWholeBlock is best left to close() and not verifyChecksum, though... right? It might be better if this were to finish reading the block and verify the checksum rather than ignoring it.
* LzopCodec was removed from the default list of codecs, per HADOOP-4030
* +1 for an OutputFormat
* The size of each block (including checksums) depends on the codecs specified in the header; LzoTextInputFormat::index assumes only one checksum per block, which may not be the case:
{noformat}
+        is.seek(pos + compressedBlockSize + 4); // crc int?
{noformat}
* Each RecordReader doesn't need to slurp and sort the full index. If each FileSplit were guaranteed to point to the beginning of a block, all the splits could be generated by the client using the index.

> Add ability to split text files compressed with lzo
> ---------------------------------------------------
>
>                 Key: HADOOP-4640
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4640
>             Project: Hadoop Core
>          Issue Type: Improvement
>          Components: io, mapred
>            Reporter: Johan Oskarsson
>            Assignee: Johan Oskarsson
>            Priority: Trivial
>             Fix For: 0.20.0
>
>         Attachments: HADOOP-4640.patch
>
>
> Right now any file compressed with lzop will be processed by one mapper. This is a shame since the lzo algorithm would be very suitable for large log files and similar common hadoop data sets. The compression rate is not the best out there but the decompression speed is amazing.  Since lzo writes compressed data in blocks it would be possible to make an input format that can split the files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.