## Metadata - Author: [[aurimas|@aurimas]] - Full Title:: The Jungle of Metrics Layers and Its Invisible Elephant - Category:: #🗞️Articles - URL:: https://aurimas.eu/blog/2022/08/metrics-layers-and-power-bi/ - Finished date:: [[2024-02-15]] ## Highlights Until they supported it > the current DBT’s approach is to be the layer where metrics are only defined but not queried. The implementation of converting metric definitions to queries/computation of metrics is delegated to upstream tools. You can see how that plays out in an announcement from Cube, which just released DBT metrics support. ([View Highlight](https://read.readwise.io/read/01hppq53ms5b9jz0r4hpawyxbt)) > Here’s the thing: in none of the discussions about what a metrics layer should be / coverage of key players, have I ever seen a reference to a player that has functionality that fulfils most of the requirements typically listed for a metrics layer ([View Highlight](https://read.readwise.io/read/01hppq6na9cnek8fnm93m8m2zy)) > Cube, Metriql, Metlo, MetricFlow, AtScale and Malloy do not store data ([View Highlight](https://read.readwise.io/read/01hppqjg7ke61eymanc0ec34mt)) > However, even these players admit that in some cases querying raw data in data warehouses is suboptimal. Thus, some support the pre-aggregation – frequently used metrics and dimensions are precomputed and stored in their own database ([View Highlight](https://read.readwise.io/read/01hppqjt22k3ex4jfpnzg1jdk5)) > so far, we are still in the land of relatively basic metrics ([View Highlight](https://read.readwise.io/read/01hppqpeh0asz467dmgwp78ez4))