The use of PEventStore.aggregateProperties as shown below causes errors when a
large cluster is making the query. It seems to cause a full DB scan, which
results in timeouts. This may be because nearly 400 (parallelism of the
cluster) threads are making requests. But should this result in a full scan? Is
there a better want to get all "item" properties? Is it possible to index a
column that would make this mor efficient? Any ideas would be appreciated. This
makes frequent or fast training on near Tb data impossible.
val fieldsRDD: RDD[(ItemID, PropertyMap)] = PEventStore.aggregateProperties(
appName = dsp.appName,
entityType = "item")(sc)
BTW: If I reduce parallelism in Spark it slows other parts of the algorithm
unacceptably. I have also experimented with very large RPC/Scanner timeouts of
many minutes—to no avail.
Job aborted due to stage failure: Task 44 in stage 147.0 failed 4 times, most
recent failure: Lost task 44.3 in stage 147.0 (TID 24833,
ip-172-16-3-9.eu-central-1.compute.internal):
org.apache.hadoop.hbase.DoNotRetryIOException: Failed after retry of
OutOfOrderScannerNextException: was there a rpc timeout?+details
Job aborted due to stage failure: Task 44 in stage 147.0 failed 4 times, most
recent failure: Lost task 44.3 in stage 147.0 (TID 24833,
ip-172-16-3-9.eu-central-1.compute.internal):
org.apache.hadoop.hbase.DoNotRetryIOException: Failed after retry of
OutOfOrderScannerNextException: was there a rpc timeout? at
org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:403) at
org.apache.hadoop.hbase.mapreduce.TableRecordReaderImpl.nextKeyValue(TableRecordReaderImpl.java:232)
at
org.apache.hadoop.hbase.mapreduce.TableRecordReader.nextKeyValue(TableRecordReader.java:138)
at
