accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3602) BatchScanner optimization for AccumuloInputFormat
Date Fri, 10 Apr 2015 19:19:12 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490180#comment-14490180
] 

ASF GitHub Bot commented on ACCUMULO-3602:
------------------------------------------

Github user keith-turner commented on the pull request:

    https://github.com/apache/accumulo/pull/25#issuecomment-91656749
  
    > To clarify, what is the underlying concern, that the Configuration object gets too
large and the (de)serialization becomes too expensive or not even possible?
    
    Yeah that was my concern.  I am also making the assumption that the Configuration has
to be able to fit into memory on the client submitting the M/R job and on the jobtracker.
    
    > My particular use case is reflection on the fact that small ranges introduce too
much overhead when they translate to mappers (in MR) and partitions (in spark). So it would
be nice if there is some kind of minimum batch, tablet maps nicely to that.
    
    I think what you are doing to make AIF handle this case well is useful.   I have had multiple
users ask about this type of thing before.   Your changes make it possible for a map reduce
job to handle a large number of ranges in an efficient manner, but a user can only pass a
set of ranges that fits in memory.  I don't think that problem has to be solved in this PR,
but I think its useful to think ahead w.r.t to the API.  After this change it would be cool
if we were not limited by the number of ranges that could fit into memory.


> BatchScanner optimization for AccumuloInputFormat
> -------------------------------------------------
>
>                 Key: ACCUMULO-3602
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3602
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 1.6.1, 1.6.2
>            Reporter: Eugene Cheipesh
>            Assignee: Eugene Cheipesh
>              Labels: performance
>             Fix For: 1.7.0
>
>
> Currently {{AccumuloInputFormat}} produces a split for reach {{Range}} specified in the
configuration. Some table indexing schemes, for instance z-order geospacial index, produce
large number of small ranges resulting in large number of splits. This is specifically a concern
when using {{AccumuloInputFormat}} as a source for Spark RDD where each Split is mapped to
an RDD partition.
> Large number of small RDD partitions leads to poor parallism on read and high overhead
on processing. A desirable alternative is to group ranges by tablet into a single split and
use {{BatchScanner}} to produce the records. Grouping by tablets is useful because it represents
Accumulos attempt to distributed stored records and can be influance by the user through table
splits.
> The grouping functionality already exists in the internal {{TabletLocator}} class. 
> Current proposal is to modify {{AbstractInputFormat}} such that it generates either {{RangeInputSplit}}
or {{MultiRangeInputSplit}} based on a new setting in {{InputConfigurator}}.  {{AccumuloInputFormat}}
would then be able to inspect the type of the split and instantiate an appropriate reader.
> The functinality of {{TabletLocator}} should be exposed as a public API in 1.7 as it
is useful for optimizations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message