[
https://issues.apache.org/jira/browse/HADOOP-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632752#action_12632752
]
Pete Wyckoff commented on HADOOP-4065:
--------------------------------------
bq. I'm still not convinced about the utility of this class outside of Hive.
What is the advantage of storing the data this way?
1. You don't need a loader.
2. Tools outside of hadoop can use the data - python, perl, c++, ...
3. There are other file formats that are splittable and self or non
self-describing. Hadoop is generally pretty pluggable, but not at the file
level. Would be nice to have generic file interfaces that one can implement to
get *First Class* hadoop treatment for any file format.
To be clear, Hive writes and reads binary data to sequence files only now. We
load all binary data into sequence files.
bq. i really don't care - we can put this into Hive.
-1
This is a general FlatFileRecordReader - HADOOP-3566 seems to be a non-general
version of this? (with the issue of that being <String, Void>)
And note my intention is to put this in contrib/serialization
> support for reading binary data from flat files
> -----------------------------------------------
>
> Key: HADOOP-4065
> URL: https://issues.apache.org/jira/browse/HADOOP-4065
> Project: Hadoop Core
> Issue Type: Bug
> Components: mapred
> Reporter: Joydeep Sen Sarma
> Attachments: FlatFileReader.java, HADOOP-4065.0.txt,
> HADOOP-4065.1.txt, HADOOP-4065.1.txt, ThriftFlatFile.java
>
>
> like textinputformat - looking for a concrete implementation to read binary
> records from a flat file (that may be compressed).
> it's assumed that hadoop can't split such a file. so the inputformat can set
> splittable to false.
> tricky aspects are:
> - how to know what class the file contains (has to be in a configuration
> somewhere).
> - how to determine EOF (would be nice if hadoop can determine EOF and not
> have the deserializer throw an exception (which is hard to distinguish from
> a exception due to corruptions?)). this is easy for non-compressed streams -
> for compressed streams - DecompressorStream has a useful looking
> getAvailable() call - except the class is marked package private.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
