accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3602) BatchScanner optimization for AccumuloInputFormat
Date Wed, 08 Apr 2015 15:35:12 GMT


ASF GitHub Bot commented on ACCUMULO-3602:

Github user echeipesh commented on a diff in the pull request:
    --- Diff: core/src/main/java/org/apache/accumulo/core/client/mapred/
    @@ -629,32 +676,37 @@ public float getProgress() throws IOException {
             for (Map.Entry<KeyExtent,List<Range>> extentRanges : tserverBin.getValue().entrySet())
               Range ke = extentRanges.getKey().toDataRange();
    -          for (Range r : extentRanges.getValue()) {
    -            if (autoAdjust) {
    -              // divide ranges into smaller ranges, based on the tablets
    -              RangeInputSplit split = new RangeInputSplit(tableName, tableId, ke.clip(r),
new String[] {location});
    -              split.setOffline(tableConfig.isOfflineScan());
    -              split.setIsolatedScan(tableConfig.shouldUseIsolatedScanners());
    -              split.setUsesLocalIterators(tableConfig.shouldUseLocalIterators());
    -              split.setMockInstance(mockInstance);
    -              split.setFetchedColumns(tableConfig.getFetchedColumns());
    -              split.setPrincipal(principal);
    -              split.setToken(token);
    -              split.setInstanceName(instance.getInstanceName());
    -              split.setZooKeepers(instance.getZooKeepers());
    -              split.setAuths(auths);
    -              split.setIterators(tableConfig.getIterators());
    -              split.setLogLevel(logLevel);
    -              splits.add(split);
    -            } else {
    -              // don't divide ranges
    -              ArrayList<String> locations = splitsToAdd.get(r);
    -              if (locations == null)
    -                locations = new ArrayList<String>(1);
    -              locations.add(location);
    -              splitsToAdd.put(r, locations);
    +          if (batchScan) {
    +            // group ranges by tablet to be read by a BatchScanner
    +            ArrayList<Range> clippedRanges = new ArrayList<Range>();
    +            for(Range r: extentRanges.getValue())
    --- End diff --
    The intent of the change is to keep splits local and batch access to them to reduce overhead.
This implies clipping the ranges. The alternative could be a split with two locations that
has 90%+ of ranges on vs the other location. As I understand the scheduler at that point has
no weight for locality preference.
    On other hand having option to not clip would make the options more logically consistent
and justify having number of threads per batch reader as configuration. 
    I personally think the first option breaks the least eggs, what do you think?

> BatchScanner optimization for AccumuloInputFormat
> -------------------------------------------------
>                 Key: ACCUMULO-3602
>                 URL:
>             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
> 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

View raw message