woah https://github.com/dbt-labs/dbt-core/issues/4071

Shots fired

At whom in your mind @stephen_bailey? I figured this was an inevitability.

At other players in the nascent “metrics layer” space and LookML, mostly. It does feel inevitable but it also feels like if BI tools are going to start to integrate with “metrics definitions” a la the Looker / Tableau partnership, dbt is going to have a major edge

to a point. the implicatino with this is that dbt cloud will generate the sql and provide that api. a lot of other people could do that and still enable you to use dbt core. but yeah, the game is a foot

Because if a BI tool integrates with a MetriQL metrics endpoint, for example, it gets columns. If it integrates with dbt cloud’s metrics endpoint, it can have everything — lineage, run history, tags, etc

@emre may have more to add on this and how they’re thinking about it 🙂

I see it more ontologically part of the project definition, meaning I think it makes a lot of sense to define "how the columns are or are not to be used" at the same time as you are creating the columns. There's still plenty of space for the thousands of ways to do visualizations. And although I haven't used MetriQL or some of the other mentioned tools, I am really excited for this. I will be happy if every danged Excel spreadsheet or Power BI report or (insert your dashboard layer here) wasn't recreating the same metrics from scratch with subtly different definitions. Also - a lot of those legacy BI tools don't support Git integration (<insert rant here>) so there's a big win right there just to get the definitions into git.

@taylor thanks for mentioning me! @stephen_bailey the BI tools usually care about the semantic layer, not the lineage or the run history (maybe the the time of the recent run?). We expose the tags and all the dbt resources (models, seeds and sources) as datasets similar to how database connections work. In addition to that, we synchronize the metric definitions to your BI/data tools if applicable. Here are the benefits of having a metrics layer: 1. Automating your BI workflow. (metric definitions, field types, descriptions, labels, formatting, join relations, etc.) 2. Speeding up BI queries by creating dimensional tables automatically. (see Aggregates) 3. Auditing all the BI / data queries and analyzing how the data is being used. Essentially, Metriql is the serving layer of dbt so the data tools connect the data warehouse through Metriql. We act as a proxy to your data warehouse and help you automate the workflow and make sure that you’re making use of your data warehouse in an efficient and consistent way.

awesome, and great podcast @emre ! appreciate the work you're doing trailblazing in this space. So you think overall having a dbt-sanctioned "metrics definition" will be a net win for metriql? It does open up your audience to the whole user base, and allows you to focus on what comes after the definition rather than the spec itself?