Quick scan of dbt metrics - looks like it lets you define a flat, single view of a metric with a predefined set of “filters” (Ie sql predicates). Also it only allows a metric to come from a single table; “joins” are a TODO.
It is missing the runtime engine to “interpret” the semantic model and so arbitrary but correct joins among tables and generate the appropriate SQl to realize those arbitrary joins.
If anyone know dbt better and also knows semantic models, please correct.
I think those points are on the mark. I added some notes to the similar question that asked for a comparison of dbt, cube and MetricFlow!
I'll just say Joins are hard, but if solved elegantly they allow you to do some really interesting stuff. As an example in MetricFlow you can traverse the data graph in your queries. For example if you go `pip install metricflow` and try the tutorial: `mf_tutorial`
You can see what I mean by running queries that traverse the multiple joins to get to other dimensions:
1. Ask for transactions by day by customer `mf query --metrics transactions --dimensions ds,customer --order ds`
2. Ask for transactions by day by customer country `mf query --metrics transactions --dimensions ds,customer__country --order ds`
3. Ask for transactions by day by customer region where we traverse through a country to region mapping
`mf query --metrics transactions --dimensions ds,customer__country__region --order ds`
It is missing the runtime engine to “interpret” the semantic model and so arbitrary but correct joins among tables and generate the appropriate SQl to realize those arbitrary joins.
If anyone know dbt better and also knows semantic models, please correct.