[
https://issues.apache.org/jira/browse/ACCUMULO-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Cheipesh updated ACCUMULO-3602:
--------------------------------------
Description:
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.
was:
Curently `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`. `InputFormatBase`, extended by `AccumuloInputFormat`,
would then be able to inspect the type of the split in 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.
> 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
> 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)
