andygrove commented on issue #2520: URL: https://github.com/apache/datafusion-ballista/issues/2520#issuecomment-6724675813
A data point for A2, from Comet Native Executors (apache/datafusion-comet#7288), which run Comet's plans on Ballista's scheduler and executors. One executor with 4 vcores, blocking mode, aggregates over a Parquet table of 13 files with one row group each (384 MB), read as 190 byte-range splits of 2 MiB. A split only gets the row groups that start in it, so 13 splits hold all the rows and 177 are empty. With the default (`max_partitions_per_task` unbounded), `bind_one` packed 4 consecutive splits into each task. Nearly every task held one of the 13 non-empty splits and three empty ones, and kept all 4 vcores until it finished, so the 13 non-empty splits ran one at a time, about 270 ms each: the scan stage took 3.7 s of the query's 3.9 s. With `ballista.scheduler.max_partitions_per_task=1` they ran 4 at a time and the query took 1.5 s. A heavier query went from 6.8 s to 2.4 s, and queries of a few hundred milliseconds barely changed (0.24 s to 0.22 s), so at this scale the extra tasks cost less than the idle vcores did. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
