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 Wed, 08 Apr 2015 15:57:12 GMT

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

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

Github user echeipesh commented on a diff in the pull request:

    https://github.com/apache/accumulo/pull/25#discussion_r27983742
  
    --- Diff: core/src/main/java/org/apache/accumulo/core/client/mapred/AbstractInputFormat.java
---
    @@ -384,7 +387,21 @@ public static InputTableConfig getInputTableConfig(JobConf job, String
tableName
       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:
    
    ```java
    // 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)
          scanner.addScanIterator(iterator);
    }
    ```
    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
way?
    



> 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