[
https://issues.apache.org/jira/browse/ACCUMULO-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380481#comment-14380481
]
Josh Elser commented on ACCUMULO-3602:
--------------------------------------
bq. Alright, 1.7 target it is then. I'll rebase on master.
Cool. Thank you, and again, sorry for the pain semver is causing.
bq. Should it be the default approach when possible? I'm not sure, probably
yes. Locality would be tied to a tablet, which is hosted on one machine, you
still can reap the benefits of several IO threads. The effort on querying the
TabletLocator is spent in either case, so why not use it.
As long as the Split generation is still binning the ranges together on
locality, I think this would be fine for most cases. There's still the
possibility that tablets move the mappers read them, but that's nothing new.
One case I thought of is that a Mapper could have special logic based on the
fact that it will receive sorted Key-Value pairs which a
BatchScanner-by-default would break. I'm not sure how common this is nor if
it's a big concern.
My cautious nature would be to say that it's safest to have 1.7 introduce
configuration that allow use of BatchScanners and then 2.0 could switch that to
the default? A nice enum could help make a setter which ensure API compat
between 1.7 and 2.0 and let the default configuration change underneath.
Haven't thought it through completely, just a first reaction. [~kturner] is
really good at this stuff. Maybe he can weigh :)
> 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)
