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 Thu, 02 Apr 2015 02:48:53 GMT

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

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

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

    https://github.com/apache/accumulo/pull/25#discussion_r27629523
  
    --- Diff: core/src/main/java/org/apache/accumulo/core/client/mapreduce/BatchInputSplit.java
---
    @@ -0,0 +1,151 @@
    +/*
    + * Licensed to the Apache Software Foundation (ASF) under one or more
    + * contributor license agreements.  See the NOTICE file distributed with
    + * this work for additional information regarding copyright ownership.
    + * The ASF licenses this file to You under the Apache License, Version 2.0
    + * (the "License"); you may not use this file except in compliance with
    + * the License.  You may obtain a copy of the License at
    + *
    + *     http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +package org.apache.accumulo.core.client.mapreduce;
    +
    +import java.io.DataInput;
    +import java.io.DataOutput;
    +import java.io.IOException;
    +import java.util.ArrayList;
    +import java.util.Arrays;
    +import java.util.Collection;
    +import java.util.Collections;
    +
    +import org.apache.accumulo.core.data.Key;
    +import org.apache.accumulo.core.data.PartialKey;
    +import org.apache.accumulo.core.data.Range;
    +
    +/**
    + * The Class BatchInputSplit. Encapsulates a set of Accumulo ranges on a single tablet
for use in Map Reduce jobs.
    + * Can contain several Ranges per split.
    + */
    +public class BatchInputSplit extends AccumuloInputSplit {
    +  private Collection<Range> ranges;
    +  private int scanThreads;
    +
    +  public BatchInputSplit() {
    +    ranges = Collections.emptyList();
    +  }
    +
    +  public BatchInputSplit(BatchInputSplit split) throws IOException {
    +    super(split);
    +    this.setRanges(split.getRanges());
    +  }
    +
    +  protected BatchInputSplit(String table, String tableId, Collection<Range> ranges,
String[] locations) {
    +    super(table, tableId, locations);
    +    this.ranges = ranges;
    +  }
    +
    +  public float getProgress(Key currentKey) {
    +    if (currentKey == null)
    +      return 0f;
    +    for (Range range : ranges) {
    --- End diff --
    
    Sadly, this isn't really representative like it was for a single Range per InputSplit.
There will be a semblance of ordering (as Accumulo is going to be doing batches under the
hood), but there's no real progress you can identify out of keys from a BatchScanner. The
only realistic approximation I can think of is based off of some stats we store in the metadata
table, but I don't think that's realistic in this changeset.
    I can't think of a reliable way to do this computation. If that's the case, I'd be apt
to just `return 0` and mark it as a TODO


> 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