[Epic] A collection of issues for extending the Aggregation function

[Weijun-H]

Is your feature request related to a problem or challenge?

DataFusion now supports several aggregation functions, but it still lacks some common ones that are essential for a broader range of data processing tasks. To make DataFusion more versatile and capable of handling diverse workloads, it should include additional aggregation functions commonly used in data analysis, such as mode and max_by.

Describe the solution you'd like

• Support max_by in Aggregation function #12252
• Support min_by in Aggregation function #12253
• Support kurtosis_pop in Aggregation function  #12251
• Support kurtosis(x) in Aggregation function #12250
• Support skewness(x) in Aggregation function #12249
• Support mode in Aggregation function #12248
• Support entropy in Aggregation function #12247

Describe alternatives you've considered

No response

Additional context

These functions should be implemented in datafusion-contrib/datafusion-functions-extra, instead of the core

[alamb]

I wonder if we should consider where to draw the line on what aggregate functions to include in the core (i.e. should we include all these new functions?)

Now that all aggregate functions use the same API, we could potentially keep more specialized functions such as listed here outside the ore -- either in its own crate or even own repo -- and then have other code integrate it in -- e.g. #11979

[alamb]

I started a discussion about if we should be adding all these functions directly in the core here: #12357

[Weijun-H]

I wonder if we should consider where to draw the line on what aggregate functions to include in the core (i.e. should we include all these new functions?)

Now that all aggregate functions use the same API, we could potentially keep more specialized functions such as listed here outside the ore -- either in its own crate or even own repo -- and then have other code integrate it in -- e.g. #11979

I like this idea! 🚀

[alamb]

@Weijun-H and @dmitrybugakov and @dharanad -- what do you think about creating a datafusion-functions-duckdb repo in datafusion-contrib similar to https://github.com/datafusion-contrib/datafusion-functions-json for JSON from @samuelcolvin and co.

It would be a pretty neat way to help build out the function library in DataFUsion and would show off its extensibility

I could then try an integrate it into dft that @matthewmturner and I have been working on: https://github.com/datafusion-contrib/datafusion-dft which would make it easer to use

Originally from: #12476 (comment)

[austin362667]

Thank you @alamb for proposing this initiative. I like this idea. What about others' thought?
It clearly draws a line between the core and the extensions. And we can still leverage those functions as extension in dft.

[demetribu]

@alamb
I’m generally in favor of moving additional features from the core to separate subprojects. However, could we consider using a more general name than datafusion-functions-duckdb? What are your thoughts on using something like datafusion-functions-sql or another broader name?

[alamb]

@alamb I’m generally in favor of moving additional features from the core to separate subprojects. However, could we consider using a more general name than datafusion-functions-duckdb? What are your thoughts on using something like datafusion-functions-sql or another broader name?

I do not have a strong preference -- I think it likely depends on the usecase:

• trying to migrate spark workloads
• trying to migrate duckdb workloads
• triynt to make the most useful sql system you can

However, let's not let get too carried away with details at the moment.

I created https://github.com/datafusion-contrib/datafusion-functions-extra and added @dmitrybugakov and @austin362667 as admins. If anyone else wants to help let me know and we can add you too.

@dmitrybugakov or @austin362667 would you be willing to setup the basic skeleton of the repo?

Perhaps you could follow the model of https://github.com/datafusion-contrib/datafusion-functions-json for readme and registration function

And then try to put the mode function there: #12385

[alamb]

Update: I also added @Lordworms (a longtime DataFusion contributor) per #12284 (comment)

[Weijun-H]

@alamb I’m generally in favor of moving additional features from the core to separate subprojects. However, could we consider using a more general name than datafusion-functions-duckdb? What are your thoughts on using something like datafusion-functions-sql or another broader name?

I do not have a strong preference -- I think it likely depends on the usecase:

• trying to migrate spark workloads
• trying to migrate duckdb workloads
• triynt to make the most useful sql system you can

However, let's not let get too carried away with details at the moment.

I created datafusion-contrib/datafusion-functions-extra and added @dmitrybugakov and @austin362667 as admins. If anyone else wants to help let me know and we can add you too.

@dmitrybugakov or @austin362667 would you be willing to setup the basic skeleton of the repo?

Perhaps you could follow the model of datafusion-contrib/datafusion-functions-json for readme and registration function

And then try to put the mode function there: #12385

I agree that 'datafusion-functions-extra' is sufficient for the current scenario because our goal is to decouple the extra functions from the core and make them lightweight. Additionally, it would be easier to split 'datafusion-functions-extra' into many specific use cases if necessary.

[alamb]

I believe the consensus is that we are going to implement these functions in https://github.com/datafusion-contrib/datafusion-functions-extra -- I will close the related tickets so we are not confusing people about what we are looking for

[alamb]

I filed #12625 to propose moving kertosis_pop