DFRay currently creates "stage processors" for each stage in a query plan and eagerly executes queries. This is good for low-latency use cases but can require a large amount of memory.
I would like to have the option to execute using a Spark-like approach where the output of each query stage is streamed to shuffle files and then the next stage streams from that shuffle file via flight (this is the design implemented in Ballista).
I would also like to have a fixed number of "executors" so that concurrency can be controlled more easily.
This would be helpful to cases where users are migrating away from Spark and want a similar execution model.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4