In order to allow GeoWave users to deploy on HBase without dealing w/ custom classes, I've added some store options that allow queries to run without coprocessors or custom filters (basically just using client-only filters):

enableCoprocessors (boolean): if true, will use a coprocessor for aggregations. This will require deployment of the geowave-hbase.jar (see previous comment), and registration of the aggregation coprocessor in one of three ways:

Register globally in the hbase-site.xml properties, like this:

hbase.coprocessor.region.classes
mil.nga.giat.geowave.datastore.hbase.query.AggregationEndpoint
Register on each table that will use it via the HBase shell:

hbase shell
alter 'SPATIAL_IDX', METHOD => 'table_att', 'coprocessor'=>'hdfs://ip-10-0-0-81:8020/user/hbase/lib/geowave-hbase.jar|mil.nga.giat.geowave.datastore.hbase.query.AggregationEndpoint|1001'
Let GeoWave verify and register (if necessary), whenever a coprocessor is called. In this case, we must use two more geowave store options:
- verifyCoprocessors = true. When an aggregation query is called, this will check the table for coprocessor registration. If not, it will use the HBase API to register it on the table. In order for this to work, we need to know where the custom jar is located in HDFS, using this option:
- coprocessorJar=hdfs://ip-10-0-0-81:8020/user/hbase/lib/geowave-hbase.jar

Also, for custom filters, we can enable their use by setting the store option:

enableCustomFilters=true. This simply requires the presence of the custom jar, using the means described in the previous comment (there is no 'registration' of custom filters).

Investigate the performance implication in use of coprocessors for DistributableQueryFilter #862

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions