realno commented on a change in pull request #1525: URL: https://github.com/apache/arrow-datafusion/pull/1525#discussion_r780443231
########## File path: datafusion/src/physical_plan/expressions/stddev.rs ########## @@ -0,0 +1,312 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +//! Defines physical expressions that can evaluated at runtime during query execution + +use std::any::Any; +use std::sync::Arc; + +use crate::error::{DataFusionError, Result}; +use crate::physical_plan::{ + expressions::variance::VarianceAccumulator, Accumulator, AggregateExpr, PhysicalExpr, +}; +use crate::scalar::ScalarValue; +use arrow::datatypes::DataType; +use arrow::datatypes::Field; + +use super::format_state_name; + +/// STDDEV (standard deviation) aggregate expression +#[derive(Debug)] +pub struct Stddev { + name: String, + expr: Arc<dyn PhysicalExpr>, + data_type: DataType, +} + +/// function return type of standard deviation +pub fn stddev_return_type(arg_type: &DataType) -> Result<DataType> { + match arg_type { + DataType::Int8 + | DataType::Int16 + | DataType::Int32 + | DataType::Int64 + | DataType::UInt8 + | DataType::UInt16 + | DataType::UInt32 + | DataType::UInt64 + | DataType::Float32 + | DataType::Float64 => Ok(DataType::Float64), + other => Err(DataFusionError::Plan(format!( + "STDDEV does not support {:?}", + other + ))), + } +} + +pub(crate) fn is_stddev_support_arg_type(arg_type: &DataType) -> bool { + matches!( + arg_type, + DataType::UInt8 + | DataType::UInt16 + | DataType::UInt32 + | DataType::UInt64 + | DataType::Int8 + | DataType::Int16 + | DataType::Int32 + | DataType::Int64 + | DataType::Float32 + | DataType::Float64 + ) +} + +impl Stddev { + /// Create a new STDDEV aggregate function + pub fn new( + expr: Arc<dyn PhysicalExpr>, + name: impl Into<String>, + data_type: DataType, + ) -> Self { + // the result of stddev just support FLOAT64 and Decimal data type. Review comment: Yes, we should support decimal according to spec. I am glad to see you are working on adding decimal - which is the reason I left it out at the moment. Please let me know once it's merged I am happy to open another PR to add it. Once this PR is merged I will create an issue to track this. ########## File path: datafusion/src/physical_plan/expressions/variance.rs ########## @@ -0,0 +1,376 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +//! Defines physical expressions that can evaluated at runtime during query execution + +use std::any::Any; +use std::sync::Arc; + +use crate::error::{DataFusionError, Result}; +use crate::physical_plan::{Accumulator, AggregateExpr, PhysicalExpr}; +use crate::scalar::ScalarValue; +use arrow::datatypes::DataType; +use arrow::datatypes::Field; + +use super::format_state_name; + +/// VARIANCE aggregate expression +#[derive(Debug)] +pub struct Variance { + name: String, + expr: Arc<dyn PhysicalExpr>, +} + +/// function return type of variance +pub fn variance_return_type(arg_type: &DataType) -> Result<DataType> { + match arg_type { + DataType::Int8 + | DataType::Int16 + | DataType::Int32 + | DataType::Int64 + | DataType::UInt8 + | DataType::UInt16 + | DataType::UInt32 + | DataType::UInt64 + | DataType::Float32 + | DataType::Float64 => Ok(DataType::Float64), + other => Err(DataFusionError::Plan(format!( + "VARIANCE does not support {:?}", + other + ))), + } +} + +pub(crate) fn is_variance_support_arg_type(arg_type: &DataType) -> bool { + matches!( + arg_type, + DataType::UInt8 + | DataType::UInt16 + | DataType::UInt32 + | DataType::UInt64 + | DataType::Int8 + | DataType::Int16 + | DataType::Int32 + | DataType::Int64 + | DataType::Float32 + | DataType::Float64 + ) +} + +impl Variance { + /// Create a new VARIANCE aggregate function + pub fn new( + expr: Arc<dyn PhysicalExpr>, + name: impl Into<String>, + data_type: DataType, + ) -> Self { + // the result of variance just support FLOAT64 data type. + assert!(matches!(data_type, DataType::Float64)); Review comment: Please see reply from stddev. Will create new PR once decimal support is added. ########## File path: datafusion/src/physical_plan/expressions/variance.rs ########## @@ -0,0 +1,376 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +//! Defines physical expressions that can evaluated at runtime during query execution + +use std::any::Any; +use std::sync::Arc; + +use crate::error::{DataFusionError, Result}; +use crate::physical_plan::{Accumulator, AggregateExpr, PhysicalExpr}; +use crate::scalar::ScalarValue; +use arrow::datatypes::DataType; +use arrow::datatypes::Field; + +use super::format_state_name; + +/// VARIANCE aggregate expression +#[derive(Debug)] +pub struct Variance { + name: String, + expr: Arc<dyn PhysicalExpr>, +} + +/// function return type of variance +pub fn variance_return_type(arg_type: &DataType) -> Result<DataType> { + match arg_type { + DataType::Int8 + | DataType::Int16 + | DataType::Int32 + | DataType::Int64 + | DataType::UInt8 + | DataType::UInt16 + | DataType::UInt32 + | DataType::UInt64 + | DataType::Float32 + | DataType::Float64 => Ok(DataType::Float64), + other => Err(DataFusionError::Plan(format!( + "VARIANCE does not support {:?}", + other + ))), + } +} + +pub(crate) fn is_variance_support_arg_type(arg_type: &DataType) -> bool { + matches!( + arg_type, + DataType::UInt8 + | DataType::UInt16 + | DataType::UInt32 + | DataType::UInt64 + | DataType::Int8 + | DataType::Int16 + | DataType::Int32 + | DataType::Int64 + | DataType::Float32 + | DataType::Float64 + ) +} + +impl Variance { + /// Create a new VARIANCE aggregate function + pub fn new( + expr: Arc<dyn PhysicalExpr>, + name: impl Into<String>, + data_type: DataType, + ) -> Self { + // the result of variance just support FLOAT64 data type. + assert!(matches!(data_type, DataType::Float64)); + Self { + name: name.into(), + expr, + } + } +} + +impl AggregateExpr for Variance { + /// Return a reference to Any that can be used for downcasting + fn as_any(&self) -> &dyn Any { + self + } + + fn field(&self) -> Result<Field> { + Ok(Field::new(&self.name, DataType::Float64, true)) + } + + fn create_accumulator(&self) -> Result<Box<dyn Accumulator>> { + Ok(Box::new(VarianceAccumulator::try_new()?)) + } + + fn state_fields(&self) -> Result<Vec<Field>> { + Ok(vec![ + Field::new( + &format_state_name(&self.name, "count"), + DataType::UInt64, + true, + ), + Field::new( + &format_state_name(&self.name, "mean"), + DataType::Float64, + true, + ), + Field::new( + &format_state_name(&self.name, "m2"), + DataType::Float64, + true, + ), + ]) + } + + fn expressions(&self) -> Vec<Arc<dyn PhysicalExpr>> { + vec![self.expr.clone()] + } + + fn name(&self) -> &str { + &self.name + } +} + +/// An accumulator to compute variance +#[derive(Debug)] +pub struct VarianceAccumulator { + m2: ScalarValue, + mean: ScalarValue, + count: u64, +} + +impl VarianceAccumulator { + /// Creates a new `VarianceAccumulator` + pub fn try_new() -> Result<Self> { + Ok(Self { + m2: ScalarValue::from(0 as f64), + mean: ScalarValue::from(0 as f64), + count: 0, + }) + } + + pub fn get_count(&self) -> u64 { + self.count + } + + pub fn get_mean(&self) -> ScalarValue { + self.mean.clone() + } + + pub fn get_m2(&self) -> ScalarValue { + self.m2.clone() + } +} + +impl Accumulator for VarianceAccumulator { + fn state(&self) -> Result<Vec<ScalarValue>> { + Ok(vec![ + ScalarValue::from(self.count), + self.mean.clone(), + self.m2.clone(), + ]) + } + + fn update(&mut self, values: &[ScalarValue]) -> Result<()> { + let values = &values[0]; + let is_empty = values.is_null(); + + if !is_empty { + let new_count = self.count + 1; + let delta1 = ScalarValue::add(values, &self.mean.arithmetic_negate())?; Review comment: Completely agree. I have plan to investigate this as followup PR. The current challenge is the algorithm will loose parallelizability if using a batch friendly algorithm. And I need to spend more time to understand the code. One question I have is will there be a chance `update` and `batch_update` can be used in the same job, i.e. if one job can call `update` on some data and `batch_update` on some other data. Reason for that is the online version of the algorithm requires an intermediate value to be calculated so it is not compatible with batch mode, that is, we can only do all batch or all online. ########## File path: datafusion/src/scalar.rs ########## @@ -526,6 +526,282 @@ macro_rules! eq_array_primitive { } impl ScalarValue { + /// Return true if the value is numeric + pub fn is_numeric(&self) -> bool { + matches!(self, + ScalarValue::Float32(_) + | ScalarValue::Float64(_) + | ScalarValue::Decimal128(_, _, _) + | ScalarValue::Int8(_) + | ScalarValue::Int16(_) + | ScalarValue::Int32(_) + | ScalarValue::Int64(_) + | ScalarValue::UInt8(_) + | ScalarValue::UInt16(_) + | ScalarValue::UInt32(_) + | ScalarValue::UInt64(_) + ) + } + + /// Add two numeric ScalarValues + pub fn add(lhs: &ScalarValue, rhs: &ScalarValue) -> Result<ScalarValue> { Review comment: Completely agree. My feeling is these basic operations could be implemented in ScalarValue since many operators will depend on them. I want to pick your brain (and other contributor's too) if you think this is a good idea - this deserves a seperate discussion. Also with the way ScalarValue is implemented currently each operator needs a high match block, maybe using generics can make it a little easier? Here are some options I propose: 1. Remove the redundency, I can either move sum to Scalavalue or the other direction is fine. Personally I prefer to have it in ScalarValue. 2. Leave the code as is until we have a discussion/conclusion around how to handle arithmetic operation for ScalarValue. ########## File path: datafusion/src/scalar.rs ########## @@ -526,6 +526,282 @@ macro_rules! eq_array_primitive { } impl ScalarValue { + /// Return true if the value is numeric + pub fn is_numeric(&self) -> bool { + matches!(self, + ScalarValue::Float32(_) + | ScalarValue::Float64(_) + | ScalarValue::Decimal128(_, _, _) + | ScalarValue::Int8(_) + | ScalarValue::Int16(_) + | ScalarValue::Int32(_) + | ScalarValue::Int64(_) + | ScalarValue::UInt8(_) + | ScalarValue::UInt16(_) + | ScalarValue::UInt32(_) + | ScalarValue::UInt64(_) + ) + } + + /// Add two numeric ScalarValues + pub fn add(lhs: &ScalarValue, rhs: &ScalarValue) -> Result<ScalarValue> { + if !lhs.is_numeric() || !rhs.is_numeric() { + return Err(DataFusionError::Internal(format!( + "Addition only supports numeric types, \ + here has {:?} and {:?}", + lhs.get_datatype(), + rhs.get_datatype() + ))); + } + + // TODO: Finding a good way to support operation between different types without Review comment: Good point, will explore the option. ########## File path: datafusion/src/scalar.rs ########## @@ -526,6 +526,282 @@ macro_rules! eq_array_primitive { } impl ScalarValue { + /// Return true if the value is numeric + pub fn is_numeric(&self) -> bool { + matches!(self, + ScalarValue::Float32(_) + | ScalarValue::Float64(_) + | ScalarValue::Decimal128(_, _, _) + | ScalarValue::Int8(_) + | ScalarValue::Int16(_) + | ScalarValue::Int32(_) + | ScalarValue::Int64(_) + | ScalarValue::UInt8(_) + | ScalarValue::UInt16(_) + | ScalarValue::UInt32(_) + | ScalarValue::UInt64(_) + ) + } + + /// Add two numeric ScalarValues + pub fn add(lhs: &ScalarValue, rhs: &ScalarValue) -> Result<ScalarValue> { Review comment: Completely agree. My feeling is these basic operations could be implemented in ScalarValue since many operators will depend on them. I want to pick your brain (and other contributor's too) if you think this is a good idea - this deserves a seperate discussion. Also with the way ScalarValue is implemented currently each operator needs a huge match block, maybe using generics can make it a little easier? Here are some options I propose: 1. Remove the redundency, I can either move sum to Scalavalue or the other direction is fine. Personally I prefer to have it in ScalarValue. 2. Leave the code as is until we have a discussion/conclusion around how to handle arithmetic operation for ScalarValue. ########## File path: datafusion/src/scalar.rs ########## @@ -526,6 +526,282 @@ macro_rules! eq_array_primitive { } impl ScalarValue { + /// Return true if the value is numeric + pub fn is_numeric(&self) -> bool { + matches!(self, + ScalarValue::Float32(_) + | ScalarValue::Float64(_) + | ScalarValue::Decimal128(_, _, _) + | ScalarValue::Int8(_) + | ScalarValue::Int16(_) + | ScalarValue::Int32(_) + | ScalarValue::Int64(_) + | ScalarValue::UInt8(_) + | ScalarValue::UInt16(_) + | ScalarValue::UInt32(_) + | ScalarValue::UInt64(_) + ) + } + + /// Add two numeric ScalarValues + pub fn add(lhs: &ScalarValue, rhs: &ScalarValue) -> Result<ScalarValue> { Review comment: The different value from postgres and google is because of the nature of stddev, there are two versions: 1. population and 2. sample. The one in this PR is population, looks like the default one with postgres and google is sample. The difference in the calculation is very minimal I can include the sampe version in the PR as well. Good catch! So my proposal is to add two functions: stddev_pop and stddev_s, does this look reasonable? @alamb And I will look into the inconsistency between query runs. Thanks! ########## File path: datafusion/src/scalar.rs ########## @@ -526,6 +526,282 @@ macro_rules! eq_array_primitive { } impl ScalarValue { + /// Return true if the value is numeric + pub fn is_numeric(&self) -> bool { + matches!(self, + ScalarValue::Float32(_) + | ScalarValue::Float64(_) + | ScalarValue::Decimal128(_, _, _) + | ScalarValue::Int8(_) + | ScalarValue::Int16(_) + | ScalarValue::Int32(_) + | ScalarValue::Int64(_) + | ScalarValue::UInt8(_) + | ScalarValue::UInt16(_) + | ScalarValue::UInt32(_) + | ScalarValue::UInt64(_) + ) + } + + /// Add two numeric ScalarValues + pub fn add(lhs: &ScalarValue, rhs: &ScalarValue) -> Result<ScalarValue> { Review comment: The different value from postgres and google is because of the nature of stddev, there are two versions: 1. population and 2. sample. The one in this PR is population, looks like the default one with postgres and google is sample. The difference in the calculation is very minimal I can include the sampe version in the PR as well. Good catch! So my proposal is to add two functions: stddev_pop and stddev_samp (following Postgres standard), and have stddev default to stddev_samp. Does this look reasonable? @alamb And I will look into the inconsistency between query runs. Thanks! ########## File path: datafusion/src/physical_plan/expressions/mod.rs ########## @@ -84,9 +86,13 @@ pub use nth_value::NthValue; pub use nullif::{nullif_func, SUPPORTED_NULLIF_TYPES}; pub use rank::{dense_rank, percent_rank, rank}; pub use row_number::RowNumber; +pub(crate) use stddev::is_stddev_support_arg_type; +pub use stddev::{stddev_return_type, Stddev}; Review comment: 👍 ########## File path: datafusion/src/scalar.rs ########## @@ -526,6 +526,282 @@ macro_rules! eq_array_primitive { } impl ScalarValue { + /// Return true if the value is numeric + pub fn is_numeric(&self) -> bool { + matches!(self, + ScalarValue::Float32(_) + | ScalarValue::Float64(_) + | ScalarValue::Decimal128(_, _, _) + | ScalarValue::Int8(_) + | ScalarValue::Int16(_) + | ScalarValue::Int32(_) + | ScalarValue::Int64(_) + | ScalarValue::UInt8(_) + | ScalarValue::UInt16(_) + | ScalarValue::UInt32(_) + | ScalarValue::UInt64(_) + ) + } + + /// Add two numeric ScalarValues + pub fn add(lhs: &ScalarValue, rhs: &ScalarValue) -> Result<ScalarValue> { + if !lhs.is_numeric() || !rhs.is_numeric() { + return Err(DataFusionError::Internal(format!( + "Addition only supports numeric types, \ + here has {:?} and {:?}", + lhs.get_datatype(), + rhs.get_datatype() + ))); + } + + // TODO: Finding a good way to support operation between different types without Review comment: First of all, thanks for suggesting this approach, I was able to get it working after making `evaluate_to_scalar` to `pub(crate)`, it will reduce the amount of code significantly. Though after some thinking I am leaning towards having a separate discussion and make the change in a different PR. Here are some of my thoughts: 1. It requires changing the scope of an internal function 2. As you mentioned, there are quite a bit of performance overhead 3. I think ScalarValue arithmetic is important to many future operators, we can take the chance to provide official support. It feels right to formally discuss the topic and review if this is the best way to achieve it. 4. This method doesn't support uptype when overflow happens. This is useful because for aggregation functions it is quite common the results requires more accuracy than the original type. 5. Some other functions such as `sum` and `avg` also have similar implementations. Though this is not a good reason to keep as is but it shows the value of official Scalar arithmetic support. Please let me know your thoughts. If makes sense I am happy to create a new issue for the work and join the discussion. Thanks! ########## File path: datafusion/src/scalar.rs ########## @@ -526,6 +526,282 @@ macro_rules! eq_array_primitive { } impl ScalarValue { + /// Return true if the value is numeric + pub fn is_numeric(&self) -> bool { + matches!(self, + ScalarValue::Float32(_) + | ScalarValue::Float64(_) + | ScalarValue::Decimal128(_, _, _) + | ScalarValue::Int8(_) + | ScalarValue::Int16(_) + | ScalarValue::Int32(_) + | ScalarValue::Int64(_) + | ScalarValue::UInt8(_) + | ScalarValue::UInt16(_) + | ScalarValue::UInt32(_) + | ScalarValue::UInt64(_) + ) + } + + /// Add two numeric ScalarValues + pub fn add(lhs: &ScalarValue, rhs: &ScalarValue) -> Result<ScalarValue> { + if !lhs.is_numeric() || !rhs.is_numeric() { + return Err(DataFusionError::Internal(format!( + "Addition only supports numeric types, \ + here has {:?} and {:?}", + lhs.get_datatype(), + rhs.get_datatype() + ))); + } + + // TODO: Finding a good way to support operation between different types without + // writing a hige match block. + // TODO: Add support for decimal types + match (lhs, rhs) { + (ScalarValue::Decimal128(_, _, _), _) | + (_, ScalarValue::Decimal128(_, _, _)) => { + Err(DataFusionError::Internal( + "Addition with Decimals are not supported for now".to_string() + )) + }, + // f64 / _ + (ScalarValue::Float64(f1), ScalarValue::Float64(f2)) => { + Ok(ScalarValue::Float64(Some(f1.unwrap() + f2.unwrap()))) Review comment: Added checkes for `None` values. ########## File path: datafusion/src/scalar.rs ########## @@ -526,6 +526,282 @@ macro_rules! eq_array_primitive { } impl ScalarValue { + /// Return true if the value is numeric + pub fn is_numeric(&self) -> bool { + matches!(self, + ScalarValue::Float32(_) + | ScalarValue::Float64(_) + | ScalarValue::Decimal128(_, _, _) + | ScalarValue::Int8(_) + | ScalarValue::Int16(_) + | ScalarValue::Int32(_) + | ScalarValue::Int64(_) + | ScalarValue::UInt8(_) + | ScalarValue::UInt16(_) + | ScalarValue::UInt32(_) + | ScalarValue::UInt64(_) + ) + } + + /// Add two numeric ScalarValues + pub fn add(lhs: &ScalarValue, rhs: &ScalarValue) -> Result<ScalarValue> { Review comment: The inconsistency between query runs are now fixed. -- 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]
