Enhance AggregationFuzzer to verify results against Presto

[mbasmanova]

Description

Currently, Aggregation Fuzzer verifies results against DuckDB. However, not all functions are available in DuckDB and sometimes semantics don't match. It would be better to verify against Presto Java.

We could launch PrestoJava process and talk to it via REST API: https://prestodb.io/docs/current/develop/client-protocol.html

I put together a prototype of a PrestoQueryRunner that can execute Presto queries:

https://github.com/prestodb/presto/compare/master...mbasmanova:presto:native-query-runner?expand=1

There are a few things to figure out still.

(1) By default, Presto returns results in JSON format. This is slow and hard to parse. Hence, I hacked Presto to return results in PrestoPage format (base64-encoded). Perhaps, we could introduce a new HTTP header that a client would specify to request PrestoPage format instead of default JSON format.

(2) The PrestoQueryRunner needs HTTP client. I'm using Proxygen as it is already available in Prestissimo. However, we need this code in Velox, so we can run fuzzer on each PR. Hence, we need to figure out how to add Proxygen dependency to Velox.

(3) PrestoQueryRunner code needs to be hooked into the Aggregation Fuzzer.

CC: @amitkdutta @aditi-pandit @kgpai @laithsakka @pedroerp @spershin

[duanmeng]

add Proxygen dependency to Velox.

Perhaps proxygen is too heavy with lots of dependencies in terms of a simple HTTP client. Can libcurl or its c++ wrapper curlpp or libcpr (supports FetchContent like fmt, xsimd in velox/CMAKE)be an option too?

[pedroerp]

Love this. One nuance is that we might end up with slight parsing discrepancies between the Duck and Presto parsers. Hopefully it won't affect most simple cases.

@majetideepak discussion about moving our parser to follow Presto semantic would be super handy to go around this.

[majetideepak]

@pedroerp I am still contemplating between the Presto parser vs. Postgres parser that Duck uses. Using Postgres parser makes the porting straightforward. My guess is that the PG parser should be compatible for Aggregation Fuzzer's needs.

[mbasmanova]

It seems that using PG parser will be easier. That parser is working well, the other one hasn't been used much and will require quite a bit of hardening.

[pedroerp]

Agreed. Btw, do we need to use it through DuckDB, or could we just use the postgreSQL parser directly? I guess DuckDB should add a only a thin layer on top of that?

[mbasmanova]

@rui-mo Rui, it would be nice to also add support for verifying Spark functions against Spark. Do you think it would be possible to create SparkQueryRunner similar to PrestoQueryRunner above?

[aditi-pandit]

@mbasmanova : This is very useful and would really improve our confidence for Presto functions. Thanks !

[rui-mo]

@mbasmanova We found Spark can also be launched through REST API. Looks it is possible to create a SparkQueryRunner similar with PrestoQueryRunner. Link: https://sparkbyexamples.com/spark/submit-spark-job-via-rest-api/.
cc @PHILO-HE @zhouyuan

[mbasmanova]

@rui-mo

We found Spark can also be launched through REST API

That sounds great. I don't see a way to fetch results via REST API. Do you know if that's possible?