You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Ewan Higgs (JIRA)" <ji...@apache.org> on 2018/02/15 11:41:00 UTC
[jira] [Comment Edited] (HADOOP-14943) Add common
getFileBlockLocations() emulation for object stores, including S3A
[ https://issues.apache.org/jira/browse/HADOOP-14943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16365428#comment-16365428 ]
Ewan Higgs edited comment on HADOOP-14943 at 2/15/18 11:40 AM:
---------------------------------------------------------------
[~stevel@apache.org],
{quote}You don't want location affinity in object stores, not really ... though [~ehiggs] and [~Thomas Demoor] might have different data
{quote}
If I understand you correctly, no you don't want location affinity in object stores.
Edit: new Jira setup doesn't like my quote tags.
was (Author: ehiggs):
[~stevel@apache.org],
{quote}You don't want location affinity in object stores, not really ... though [~ehiggs] and [~Thomas Demoor] might have different data\{quote}
If I understand you correctly, no you don't want location affinity in object stores.
> Add common getFileBlockLocations() emulation for object stores, including S3A
> -----------------------------------------------------------------------------
>
> Key: HADOOP-14943
> URL: https://issues.apache.org/jira/browse/HADOOP-14943
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 2.8.1
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Major
> Attachments: HADOOP-14943-001.patch, HADOOP-14943-002.patch, HADOOP-14943-002.patch, HADOOP-14943-003.patch, HADOOP-14943-004.patch
>
>
> It looks suspiciously like S3A isn't providing the partitioning data needed in {{listLocatedStatus}} and {{getFileBlockLocations()}} needed to break up a file by the blocksize. This will stop tools using the MRv1 APIS doing the partitioning properly if the input format isn't doing it own split logic.
> FileInputFormat in MRv2 is a bit more configurable about input split calculation & will split up large files. but otherwise, the partitioning is being done more by the default values of the executing engine, rather than any config data from the filesystem about what its "block size" is,
> NativeAzureFS does a better job; maybe that could be factored out to hadoop-common and reused?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org