Return-Path: X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0183E179C4 for ; Fri, 17 Apr 2015 15:04:01 +0000 (UTC) Received: (qmail 20698 invoked by uid 500); 17 Apr 2015 15:04:00 -0000 Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org Received: (qmail 20583 invoked by uid 500); 17 Apr 2015 15:04:00 -0000 Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@apache.org Delivered-To: mailing list notifications@accumulo.apache.org Received: (qmail 20568 invoked by uid 99); 17 Apr 2015 15:04:00 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Apr 2015 15:04:00 +0000 Date: Fri, 17 Apr 2015 15:04:00 +0000 (UTC) From: "ASF GitHub Bot (JIRA)" To: notifications@accumulo.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ACCUMULO-3602) BatchScanner optimization for AccumuloInputFormat MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ACCUMULO-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14499972#comment-14499972 ] 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_r28601704 --- Diff: core/src/main/java/org/apache/accumulo/core/client/mapreduce/InputFormatBase.java --- @@ -325,27 +362,12 @@ protected void setupIterators(TaskAttemptContext context, Scanner scanner, Strin * the Hadoop context for the configured job * @param scanner * the scanner to configure + * @deprecated since 1.7.0; Use {@link #contextIterators} instead. */ @Deprecated protected void setupIterators(TaskAttemptContext context, Scanner scanner) { - setupIterators(context, scanner, null); - } - - /** - * Initialize a scanner over the given input split using this task attempt configuration. - */ - protected void setupIterators(TaskAttemptContext context, Scanner scanner, org.apache.accumulo.core.client.mapreduce.RangeInputSplit split) { --- End diff -- Those are different methods. Note that the one you linked includes a `String tableName` argument where the removed one does not. I think we need both methods. > 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)