[
https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630677#action_12630677
]
Hong Tang commented on HADOOP-3315:
-----------------------------------
bq. If you really want this as a top-level goal, I really think you could
define the TFileHeaders as a struct in something like protocol buffers or
Thrift or even RecordIO (which would at least give you C) and then no C++,
Python, Perl, ... implementor ever has to worry about data format. This is
probably a day or two of work and in the long run should really pay off.
bq. this is also aided greatly by using thrift/protobuffers/record io since
they can parse newer versions of the same struct and just ignore unknown fields
Yes, I agree that using Protocol Buffer or Thrift for headers (rather, tails)
is probably a good way to help achieve language neutrality and compatibility,
and even shrink the # of lines. I will take a closer look at them.
bq. Stupid question, but if I am not really using the key field (ie just
storing an opaque row), does the TFile incur anymore overhead for all the empty
keys then does a SequenceFile?
Each empty key would take one byte (length=0) to represet. So it does have some
overhead.
> New binary file format
> ----------------------
>
> Key: HADOOP-3315
> URL: https://issues.apache.org/jira/browse/HADOOP-3315
> Project: Hadoop Core
> Issue Type: New Feature
> Components: io
> Reporter: Owen O'Malley
> Assignee: Amir Youssefi
> Attachments: HADOOP-3315_TFILE_PREVIEW.patch,
> HADOOP-3315_TFILE_PREVIEW_WITH_LZO_TESTS.patch, TFile Specification Final.pdf
>
>
> SequenceFile's block compression format is too complex and requires 4 codecs
> to compress or decompress. It would be good to have a file format that only
> needs
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
