[DISCUSSION] 2024 Q4 / 2025 Q1 Roadmap

[alamb]

Is your feature request related to a problem or challenge?

The last roadmap discussion we had seems to have worked out well to galvanize and get us organized around some common goals

• 2024 Q3-Q4 Roadmap? #11442

Describe the solution you'd like

Let's collect any projects that people think they are likely to spend time on or projects that the broader community would really like to see done and write them down!

Describe alternatives you've considered

No response

Additional context

No response

[alamb]

BTW my personal plans over the next few months are likely going to be focus on consolidating some of the gains / improvements we have made recently. That includes:

• External communication / documentation
• with @SamSynnada like Enhancing DataFusion's Community Engagement and Visibility #13049
• Blog post with DataFusion July - Sep 2024 #11631

Improve the project's documentation

• [EPIC] Improve examples to make them easier to navigate #11172
• Document DataFusion Threading / tokio runtimes (how to separate IO and CPU bound work) #12393
• [Epic] Better / Improved Documentation, Tutorials and Examples #7013

Performance wise I plan to

• help work on more advanced parquet predicate pushdown with @XiangpengHao Enable parquet filter pushdown by default #3463
• Continue to flesh out the grouping code: [EPIC] Improvements to GroupColumn multi-column aggregation performance #12680

[matthewmturner]

I am not sure if this is the place for it but I have been putting a lot of work into dft and plan on doing a release before end of year.

[alamb]

I am not sure if this is the place for it but I have been putting a lot of work into dft and plan on doing a release before end of year.

For anyone else following along, dft is https://github.com/datafusion-contrib/datafusion-dft

[jayzhan211]

I am not sure if this is the place for it but I have been putting a lot of work into dft and plan on doing a release before end of year.

I may want to help delta / iceberg integration, I think they are quite important. But I will work on performance task first

[matthewmturner]

I may want to help delta / iceberg integration, I think they are quite important. But I will work on performance task first

@jayzhan211 I agree, they are very important. Unfortunately, we have been held up because of the crates using different versions of datafusion. The idea was to converge on 42 - which iceberg and hudi currently use but deltalake (which we already have an integration for) is on 41 and hasnt been able to upgrade yet. It looks like they are skipping version 42 now and will use 43 - so hopefully this is resolved soon.

Here is some relevant work

• Integrate Hudi
• Implement TableProviderFactory for Iceberg

[matthewmturner]

@jayzhan211 and to be more explicit on my release plans, i did not plan on releasing until iceberg and hudi were added.

[jayzhan211]

LogicalType is important too #12622

[alamb]

I may want to help delta / iceberg integration, I think they are quite important. But I will work on performance task first

@jayzhan211 I agree, they are very important. Unfortunately, we have been held up because of the crates using different versions of datafusion.

I think another potentially very interesting approach here will be to use the FFI bindings from @timsaucer:

• FFI initial implementation #12920
• Example: FFI Table Provider as dynamic module loading #13183

The idea there would be to wrap the delta / iceberge in a stable ABI (aka the FFI bindings) so we could call delta.rs / iceberg which used a different version of DataFusion from dft.

[timsaucer]

On the python side, getting better integration with the python delta-rs package was the entire reason for pushing for the FFI bindings. I have branches ready to go for datafusion-python and delta-rs as soon as 43.0.0 releases. I also have tested it with a few of the other table providers in datafusion-contrib.

For the pure rust implementations, I think it would be best to not cross the unsafe FFI boundary if you don't have to. Unfortunately that does put additional dependencies on the other crates updating at a reasonable pace.

[alamb]

I think as soon as DataFusion 43.0.0 is released we'll be able to test it out:

1. Update dft to DataFusion 43
2. Implement a crate binding (in dft to delta-rs with older datafusion version)

It should be quite sweet

[timsaucer]

I don't know if this discussion is the place we want to track work in the other related projects, but my top goals for 2024 Q4 are:

• Get the datafusion-python and delta-rs integration over the line using FFI Add foreign table providers datafusion-python#921
• Adding a user tutorial for datafusion-python RFC: Ideas for what to include in a user tutorial datafusion-python#842
• Evaluating cuDF integration either in datafusion-python or datafusion Spike: evaluate if cuDF can be used with datafusion-python datafusion-python#936 - this might be Q1 2025
• Adding QueryPlanner to datafusion-python and implementing a custom query planner in datafusion-ray so that we can run all datafusion commands that perform execute() on the dataframe and it just knows to how to run them distributed
• Probably looking to expose more of the SessionContext via FFI

[matthewmturner]

One thing thats not clear to me with the FFI approach is who the intended owner of the bindings are - should it be dft as i dont want to worry about my deps being on different datafusion versions or is it more for the table providers crates (iceberg, deltalake, hudi, etc)?

Of course in the short term it could be prototyped in dft and contributed back to those repos but im asking more in the target state where the appropriate home would be.