You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For any set of metrics and dimensions, we can generate measures SQL, which is used to materialize a dataset that can serve those metrics and dimensions in a more efficient manner.
Today, the generated measures SQL is non-optimized - the measures are computed at the level of the metrics' upstream transforms, without considering any downstream aggregation or grain optimizations. The current measures SQL endpoint is equivalent to the SQL generated for the selected metrics' upstream transforms:
Future
It is possible to make this significantly more efficient by breaking down metrics into pre-aggregated (but still further aggregatable) measures:
Metrics are combinations of one or more measures with specific aggregation or formulas applied (e.g., SUM(sales_amount), AVG(revenue), SUM(clicks) / SUM(impressions)).
Measures are components used to build metrics (e.g., sales_amount, revenue, user_count).
We'll aim to keep the same flexibility that users have today with the metric definition (e.g., arbitrary SQL). However, we'll parse out this SQL into a list of measures, along with the necessary aggregation function.
Steps:
Find the aggregation functions in the metric SQL.
The expressions inside the aggregation funcs can be turned into measures
The derived SQL can be generated by replacing the interior of the agg function with the measure
Introduction
For any set of metrics and dimensions, we can generate measures SQL, which is used to materialize a dataset that can serve those metrics and dimensions in a more efficient manner.
Today, the generated measures SQL is non-optimized - the measures are computed at the level of the metrics' upstream transforms, without considering any downstream aggregation or grain optimizations. The current measures SQL endpoint is equivalent to the SQL generated for the selected metrics' upstream transforms:
Future
It is possible to make this significantly more efficient by breaking down metrics into pre-aggregated (but still further aggregatable) measures:
SUM(sales_amount)
,AVG(revenue)
,SUM(clicks) / SUM(impressions)
).sales_amount
,revenue
,user_count
).We'll aim to keep the same flexibility that users have today with the metric definition (e.g., arbitrary SQL). However, we'll parse out this SQL into a list of
measures
, along with the necessaryaggregation
function.Steps:
Metric Types
Simple Sum
Complex Sum
Average
DJ will need to automatically detect this type and generate one measure for the numerator and one for the denominator (
count(*)
).Rates
Any type of metric with a numerator and a denominator.
Has Ever
Measures SQL
The measures SQL endpoint can be used to produce pre-aggregated dataset that can be used to serve the metrics + dimensions in question.
The text was updated successfully, but these errors were encountered: