Skip to content
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

feat: Add one config to limit max disk usage for spilling queries #14975

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

2010YOUY01
Copy link
Contributor

@2010YOUY01 2010YOUY01 commented Mar 3, 2025

Which issue does this PR close?

  • Closes #.

Rationale for this change

For memory-limit queries, executors might write temporary results into the disk to reduce memory load. It's important to have a configuration option to limit the max disk usage, in case some query would bloat the disk and cause other issues.

DuckDB provides a similar configuration:

max_temp_directory_size | The maximum amount of data stored inside the 'temp_directory' (when set) (e.g., 1GB)

What changes are included in this PR?

This PR is mostly refactoring, the actual change is small. I made one big refactor into a separate commit, so you can only look at the second commit for the related changes.

Changes

1. refactor: Move metrics module from datafusion_physical_plan crate to datafusion_execution crate

Current code organization:

  • datafusion_physical_plan depends on datafusion_execution
  • datafusion_physical_plan includes physical executors like SortExec
  • datafusion_execution includes memory reservation and disk manager

This PR requires adding metrics tracking ability to DiskManager, besides, I believe in the future we can also add more Metrics into MemoryPool and DiskManager, for aggregated statistics across different executors, so this PR first made this refactoring change.

2. refactor: Group all spilling-related metrics in executors into a single struct SpillMetrics

This way we can ensure the metrics across different operators can be kept consistent.

3. refactor: Move IPCStreamWriter from datafusion_physical_plan to datafusion_execution::DiskManager

4. Implement the utility function to spill batches inside DiskManager

try_spill_record_batches is implemented to replace the old utility function spill_record_batches, this way the total spilled file size can be tracked, also the interface for external operators to use is a little simpler.

Are these changes tested?

Yes, integration test is included for queries exceed/not-exceed the disk limit.

Are there any user-facing changes?

No. However there is one deprecation, I'll explain separately.

@github-actions github-actions bot added core Core DataFusion crate execution Related to the execution crate labels Mar 3, 2025
since = "46.0.0",
note = "This function is deprecated. Use `datafusion_execution::DiskManager::try_spill_record_batch_by_size` instead. Note this method is mainly used within DataFusion for spilling operators. If you only
want the functionality of writing `RecordBatch`es to disk, consider using `arrow::ipc::writer::StreamWriter` instead."
)]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function doesn't have to be public, see spill_record_batches() is also non-public.
I believe this utility function is used mainly for tracking temp files and metrics for DataFusion executor's internal use, the major functionality for writing RecordBatches to disk is in arrow::ipc, so I guess deprecating it won't cause major issues.

let disk_manager = DiskManager::try_new_without_arc(DiskManagerConfig::NewOs)?
.with_max_temp_directory_size(disk_limit)?;

let runtime = RuntimeEnvBuilder::new()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't use the builder to specify disk limit for now, because DiskManagerConfig is an enum instead of struct, so now the setup routine is a bit hacky.
Changing it I think will inevitably cause API change, so I prefer to leave it to a separate PR.

@comphead
Copy link
Contributor

comphead commented Mar 3, 2025

Nice PR thanks @2010YOUY01 I'm planning to review it today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Core DataFusion crate execution Related to the execution crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants