SUM, AVG, MAX…) are natively converted to the remote database equivalent aggregations.
However, if you write some custom aggregation functions (UDAF) you will also need to define how this aggregation is done in your remote database.
Sum product example
This example is based on a ClickHouse database and SQL but can easily be ported to other databases. For instance let’s consider a simple sum product on scalar values, which in SQL would beSUM(quantity * price).
The measure is defined in the cube with a Copper UDAF, whether the cube runs on an in-memory database or on DirectQuery.
Here is a simple implementation:
- the plugin key of the Copper UDAF, set with
pluginKey(...). DirectQuery finds the DirectQuery UDAF of a measure through this key, so both UDAFs must declare the same one - the number of inputs of the SQL expressions (i.e. the number of SQL columns to read)
- the SQL expression(s) resolving the aggregation function results(s)
- the aggregation function(s) results types
- the re-aggregation function, to query an aggregate table at a coarser granularity than the one it stores
You must provide as much aggregation results as needed in your registered Copper terminate function.
Re-aggregable UDAF
A DirectQuery UDAF must be re-aggregable for an aggregate table to serve queries at a coarser granularity than the one it stores. At the granularity of the aggregate table, DirectQuery reads its rows as they are and does not need a re-aggregation function. An aggregation function is re-aggregable if a function, capable of merging two aggregation results into one, exists. For instance, the sum product aggregation can be re-aggregated by theSUM aggregation function in the example above.
DirectQuery applies the re-aggregation function in the external database, to the aggregate table column storing the UDAF.
It is not used anywhere else: in memory, Atoti merges aggregates with the merge function of the Copper UDAF.