-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-36155: [C++][Go][Java][FlightRPC] Add support for long-running queries #36946
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you! I mostly left comments on wording. I can follow up with Java/Python later.
@@ -57,6 +57,7 @@ enum class FlightMethod : char { | |||
DoAction = 7, | |||
ListActions = 8, | |||
DoExchange = 9, | |||
PollFlightInfo = 10, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll have to update this in Python (I can put up a PR for that later)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll do this in another PR. Issue for this: #36954
Actually, I just realized we didn't add any of the previous proposals to Python, so I filed a separate task for that: #36954 |
Java: kou#14 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM just a style comment
Thanks much for doing the Go side of this!
Thanks for suggesting wordings! They are very helpful for me. I'll update the Go style later. |
9fb0af3
to
5d71b7d
Compare
@github-actions crossbow submit preview-docs |
Revision: 5d71b7d Submitted crossbow builds: ursacomputing/crossbow @ actions-a21b2bffe3
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TLDR is I read this proposal and it makes sense to me. Thank you for working on this. I only reviewed the proto and text, not the implementations
I left some minor suggested wording changes that I believe increase the precision and clarity of language, but I don't think they are necessary
Nice work
format/Flight.proto
Outdated
/* | ||
* The information to process a long-running query. | ||
*/ | ||
message RetryInfo { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor Editorial point is that calling this "RetryInfo" is somewhat misleading in my mind because it implies to me that the query is being retried, when in reality it is that current execution status that is being retried. Maybe something like "PartialFlightInfo" or something might make it clearer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. It's a good point.
RetryInfo
means info to retry polling but I can understand what you thought.
@lidavidm What do you think about this? My suggestion is PollInfo
to align PollFlightInfo()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PollInfo sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I've renamed to PollInfo
.
prior to merging this PR I think we need to do a formal vote on the change to the spec on the mailing list |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some minor suggested wording changes that I believe increase the precision and clarity of language, but I don't think they are necessary
Thanks! It's very helpful! I've merged your suggestions.
prior to merging this PR I think we need to do a formal vote on the change to the spec on the mailing list
Yes. You're right. I'll do it in this week or next:
https://lists.apache.org/thread/qcjpcw6m3p15wqxp6n6rqzlx01v1fl3v
Next:
I'll start a vote for this proposal after we reach a consensus
on this proposal.
format/Flight.proto
Outdated
/* | ||
* The information to process a long-running query. | ||
*/ | ||
message RetryInfo { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. It's a good point.
RetryInfo
means info to retry polling but I can understand what you thought.
@lidavidm What do you think about this? My suggestion is PollInfo
to align PollFlightInfo()
.
b8b1d82
to
419d8cf
Compare
…ries In Flight RPC, FlightInfo includes addresses of workers alongside result partition info. This lets clients fetch data directly from workers, in parallel or even distributed across multiple machines. But this also comes with tradeoffs. Queries generally don't complete instantly (as much as we would like them to). So where can we put the 'query evaluation time'? * In `GetFlightInfo`: block and wait for the query to complete. * Con: this is a long-running blocking call, which may fail or time out. Then when the client retries, the server has to redo all the work. * Con: parts of the result may be ready before others, but the client can't do anything until everything is ready. * In `DoGet`: return a fixed number of partitions * Con: this makes handling worker failures hard. Systems like Trino support fault-tolerant execution by replacing workers at runtime. But GetFlightInfo has already passed, so we can't notify the client of new workers. * Con: we have to know or fix the partitioning up front. Neither solution is optimal. We can address this by adding a retryable version of `GetFlightInfo`: `PollFlightInfo(FlightDescriptor)` `PollFlightInfo` returns `RetryInfo`: ```proto message RetryInfo { // The currently available results so far. FlightInfo info = 1; // The descriptor the client should use on the next try. // If unset, the query is complete. FlightDescriptor flight_descriptor = 2; // Query progress. Must be in [0.0, 1.0] but need not be // monotonic or nondecreasing. If unknown, do not set. optional double progress = 3; // Expiration time for this request. After this passes, the server // might not accept the retry descriptor anymore (and the query may // be cancelled). This may be updated on a call to PollFlightInfo. google.protobuf.Timestamp expiration_time = 4; } ``` See the documentation changes for details of them.
Co-authored-by: David Li <[email protected]>
Co-authored-by: Andrew Lamb <[email protected]>
419d8cf
to
ccbda9d
Compare
The discussion thread: https://lists.apache.org/thread/qcjpcw6m3p15wqxp6n6rqzlx01v1fl3v |
After merging your PR, Conbench analyzed the 5 benchmarking runs that have been run so far on merge-commit 107b215. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them. |
…ng queries (apache#36946) ### Rationale for this change In Flight RPC, FlightInfo includes addresses of workers alongside result partition info. This lets clients fetch data directly from workers, in parallel or even distributed across multiple machines. But this also comes with tradeoffs. Queries generally don't complete instantly (as much as we would like them to). So where can we put the 'query evaluation time'? * In `GetFlightInfo`: block and wait for the query to complete. * Con: this is a long-running blocking call, which may fail or time out. Then when the client retries, the server has to redo all the work. * Con: parts of the result may be ready before others, but the client can't do anything until everything is ready. * In `DoGet`: return a fixed number of partitions * Con: this makes handling worker failures hard. Systems like Trino support fault-tolerant execution by replacing workers at runtime. But GetFlightInfo has already passed, so we can't notify the client of new workers. * Con: we have to know or fix the partitioning up front. Neither solution is optimal. ### What changes are included in this PR? We can address this by adding a retryable version of `GetFlightInfo`: `PollFlightInfo(FlightDescriptor)` `PollFlightInfo` returns `PollInfo`: ```proto message PollInfo { // The currently available results so far. FlightInfo info = 1; // The descriptor the client should use on the next try. // If unset, the query is complete. FlightDescriptor flight_descriptor = 2; // Query progress. Must be in [0.0, 1.0] but need not be // monotonic or nondecreasing. If unknown, do not set. optional double progress = 3; // Expiration time for this request. After this passes, the server // might not accept the retry descriptor anymore (and the query may // be cancelled). This may be updated on a call to PollFlightInfo. google.protobuf.Timestamp expiration_time = 4; } ``` See the documentation changes for details of them: http://crossbow.voltrondata.com/pr_docs/36946/format/Flight.html#downloading-data-by-running-a-heavy-query ### Are these changes tested? Yes. This has C++, Go and Java implementations and an integration test with them. ### Are there any user-facing changes? Yes. * Closes: apache#36155 Lead-authored-by: Sutou Kouhei <[email protected]> Co-authored-by: Sutou Kouhei <[email protected]> Co-authored-by: David Li <[email protected]> Co-authored-by: Andrew Lamb <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
Rationale for this change
In Flight RPC, FlightInfo includes addresses of workers alongside result partition info. This lets clients fetch data directly from workers, in parallel or even distributed across multiple machines. But this also comes with tradeoffs.
Queries generally don't complete instantly (as much as we would like them to). So where can we put the 'query evaluation time'?
GetFlightInfo
: block and wait for the query to complete.DoGet
: return a fixed number of partitionsNeither solution is optimal.
What changes are included in this PR?
We can address this by adding a retryable version of
GetFlightInfo
:PollFlightInfo(FlightDescriptor)
PollFlightInfo
returnsPollInfo
:See the documentation changes for details of them:
http://crossbow.voltrondata.com/pr_docs/36946/format/Flight.html#downloading-data-by-running-a-heavy-query
Are these changes tested?
Yes.
This has C++, Go and Java implementations and an integration test with them.
Are there any user-facing changes?
Yes.