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:57: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/
    @@ -384,7 +387,21 @@ public static InputTableConfig getInputTableConfig(JobConf job, String
       protected abstract static class AbstractRecordReader<K,V> implements RecordReader<K,V>
         protected long numKeysRead;
         protected Iterator<Map.Entry<Key,Value>> scannerIterator;
    -    protected RangeInputSplit split;
    +    protected org.apache.accumulo.core.client.mapreduce.impl.AccumuloInputSplit split;
    +    protected ScannerBase scannerBase;
    +    /**
    +     * Configures the iterators on a scanner for the given table name.
    +     *
    +     * @param job
    +     *          the Hadoop job configuration
    +     * @param scanner
    +     *          the scanner for which to configure the iterators
    +     * @param tableName
    +     *          the table name for which the scanner is configured
    +     * @since 1.7.0
    +     */
    +    protected abstract void setupIterators(JobConf job, ScannerBase scanner, String tableName,
AccumuloInputSplit split);
    --- End diff --
    That's a good point. In an effort to avoid mistakes of the past and keep AccumulInputSplit
out of public API how about something like this:
    // InputFormatBase
    List<IteratorSetting> contextIterators(TaskAttemptContext context, String tableName)
      return getIterators(context).getIterators();
    // AccumululoMultiTableInputFormat
    List<IteratorSetting> contextIterators(TaskAttemptContext context, String tableName)
      return getInputTableConfig(context, tableName).getIterators();
    // lift setupIterators to AbstractInputFormat (no longer abstract)
    protected abstract List<IteratorSetting> contextIterators(TaskAttemptContext context,
String tableName);
    private void setupIterators(TaskAttemptContext context, ScannerBase scanner, String tableName,
AccumuloInputSplit split) {
        List<IteratorSetting> iterators = null;
        if (null == split) {
          iterators = contextIterators(context);
        } else {
          iterators = split.getIterators();
          if (null == iterators) {
            iterators = contextIterators(context);
        for (IteratorSetting iterator : iterators)
    Looking at code right now the only part that diverges is pulling out default split if
they're somehow unavailable in the split. This narrows the interface, hopefully in an acceptable

> 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