[
https://issues.apache.org/jira/browse/ACCUMULO-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327767#comment-14327767
]
Christopher Tubbs commented on ACCUMULO-3602:
---------------------------------------------
By default, the {{AccumuloInputFormat}} does not produce a split for each range
specified. Rather, it merges overlapping ranges and splits them on tablet
boundaries, and then assigns the results 1 per mapper. (see
{{InputFormatBase.setAutoAdjustRanges(...)}})
However, this optimization will not be useful if the ranges are not adjacent /
do not overlap. A {{MultiRangeInputSplit}} may be possible. For the particular
use case described (z-ordered multi-dimensional indexes), I think there's often
a trade-off in querying multiple ranges vs. fine-grained filtering over a
larger range. For example, sometimes it's better to query a larger range and
let an iterator filter out non-matching results, and sometimes it's better to
query multiple ranges. This is a hard-to-generalize optimization problem, but
the fact that you're producing many ranges, sufficient to start causing
problems informs me that there may be room for improvement here (at least for
that use case).
Regarding the other issue mentioned here for the TabletLocator functionality,
that is encapsulated in another issue: ACCUMULO-2883
> 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
>
> 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)
