Transform has open sourced the metric layer yesterday and it has created some ripples in the industry — as many wait for the mythic dbt server to be unveiled. It let me to check out what is out there in the metric layer space and what might be the main differences.
Note: The purpose of this brief is not to discuss the benefits or main idea behind metrics layer (metrics layer, metrics store, headless BI, etc.).
Many offer similar features, some of them seem to be the main distinguishing factors:
- YAML for metric definition, dbt metric support for few
- Server with pre-caching
- JDBC/API/Python/SDKs for connection
- BI tool integrations (or rather the rich ecosystem of integrations)
It is important to say though, a lot of companies do struggle to have a decent data practice — so a metric layer seems to be a far fetched goal for majority of them — and they should not feel they are missing something crucial. I would suggest to concentrate on 99 other problems and leave this one for much later stages of data maturity of the company.
Comparison
Lets dive in, tools available (not all considered for comparison):
- Metriql
- dbt
- Cube
- Transform (Commercial), MetricFlow (Open Source)
- GoodData
- Looker (LookML)
- Malloy (Experimental)
- Minerva API (Closed, by AirBnB)
- uMetric (Closed, by Uber)
- Metrics catalog in “new experimentation platform” by Spotify (closed)
- Metlo (Commercial)
- PowerBI (Commercial) — assessment in progress
- Hellotrace.io (Commercial, stealth mode now) — assessment in progress
Note: Please let me know at fisa@keboola.com if you spot any inaccuracy, I would be happy to fix this table!
📂 Source (feel free to comment there)
Personal opinion
I think the dbt is well positioned, as its advantage is that you actually have SQL definition — so its easier to debug (until you bring Jinja into it, then it gets blurry fast). This gives an edge to metriql, since they support dbt deinitions, but also have rich support of tools and integrations already. Others (Malloy, Transform) are defined by its own language and generate SQL based on that — which is harder to debug, optimize, test. The most impressive from the integration point of view, especially custom apps, is Cube, with a rich toolkits (and also supports dbt definitions).
It actually seems quite simple to add metric layer definition on the top of prepped data, but to offer caching layer or complex SDKs or app development integrations (such as Cube offers) is a different level of effort.
As a final note, I would like to mention George Fraser here:
George Fraser from Fivetran had an unpopular opinion that all metrics stores will evolve into BI tools
Recommended reading:
- The missing piece of the modern data stack
- Headless bi
- Why metrics should be a first class citizen in a modern data stack | by Mona Akmal
- Data’s trillion dollar question mark — by Benn Stancil
- Introducing the Cube SQL API: Building Metrics Stores with Cube
- Is Minerva the answer? — by Benn Stancil
- Lightdash, Looker and dbt as the BI Tool Metrics Layer — Rittman Analytics
- The Future of BI is Headless | GoodData Developers
