Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Wed, 8 Apr 2015 20:59:13 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12776000.1424296315000.31587.1428526753661@Atlassian.JIRA>
In-Reply-To: <JIRA.12776000.1424296315000@Atlassian.JIRA>
References: <JIRA.12776000.1424296315000@Atlassian.JIRA>
 <JIRA.12776000.1424296315088@arcas>
Subject: [jira] [Commented] (ACCUMULO-3602) BatchScanner optimization for
 AccumuloInputFormat
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Github user joshelser commented on the pull request:

    https://github.com/apache/accumulo/pull/25#issuecomment-91035731
  
    >  It seems like this change could encourage users to pass many ranges as configuration for the map reduce job. This could cause memory exhaustion for the job tracker. 
    
    Agreed, but is this a new issue? If anything, it this these changes would reduce the total number of objects in memory (as a split could contain multiple ranges whereas previously it was 1:1). I remember hearing about solutions that use HDFS as a mechanism for supporting large numbers of ranges instead of the Configuration. Either way, I think the current changes are a good addition but just not in scope to address the bigger issue you brought up.


> 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)