SUM
) will match the groups in the user query can be computed
by rolling up from the pre-aggregated dataset (see more details below).
For example, if the user count metric is additive (defined as a COUNT
), and there is a preaggregate
for total_users
by year, city
:
total_users
by year, city
will match exactly since it has same groups.total_users
by city
will match and summarize over all years.total_users
(no groups) will match and summarize over all years and cities.COUNT(DISTINCT)
) will match only when the groups in the
user query are exactly the same as in the pre-aggregated dataset.
For example, if the unique user count metric is non-additive (defined as a COUNT(DISTINCT)
), and there is a preaggregate
for unique_users
by year, city
:
unique_users
by year, city
will match exactly since it has same groups.unique_users
by city
will not match.filtered_domain
with a filter.filtered_domain
will use the cached pre-aggregate dataset.revenue
by year
and city
, where year = 2023
:
revenue
by year, city
, where year = 2023
will use the preaggregate (since it matches
all preaggregate filters and groups)revenue
by year, city
, where year = 2023 and city='Seattle'
will also use the
preaggregate (since it matches all preaggregate filters and groups, and its additional filters are on the
city
group that exists in the pre-aggregated dataset)revenue
by year
, where year = 2023 and city='Seattle'
will use the preaggregate
in the same way, but roll up over all cities to get a yearly total.revenue
by year, city
without any filters will not match the preaggregate
(since it was not filtered by year = 2023
)COUNT
, SUM
, MAX
, MIN
are additive: they can be “rolled-up” from the preaggregate.
SUM
), and there is a preaggregate for
revenue
by year, city
:
revenue
by year, city
will match exactly since it has same groups.revenue
by city
will match, and will roll up from year
groups to get totals per city.revenue
by year
will match, and will roll up from city
groups to get totals per year.revenue
(no groups) will match, and will roll up from all groups to get the total.revenue
by year, color
will not match since it has different groups.SUM
), and there is a preaggregate for revenue
by
customer.id
, then user queries on any group that comes from the customer
entity will roll up.
revenue
by customer.id
will match exactly.revenue
by customer.name
will match, and will roll up from customer.id
lines.revenue
by customer.name, customer.age
will also match, and roll up.revenue
totals (no groups) will match, and will roll up over all groups to get the total.rollup
metric property:
rollup
to allow aggregate aware roll-ups on complex metrics that are not detected automatically to
be additive.sum
: Run a SUM aggregation to roll up. Used for metrics that are a SUM
or COUNT
aggregation.min
, max
: Run a MIN or MAX aggregation to roll up. Used for the corresponding aggregations.hll
: (coming soon) Run an approximate distinct count combine (HLL_COMBINE
) to roll up (see
Estimating the Number of Distinct Values).no_rollup
: Disable roll-up behavior.SUM(RANDOM())
).config
macro to set up materialization settings such as clustering or dynamic tablesmonthly_kpi
model in dbt: