Semantic Layer Tools: dbt, LookML, Cube
Same idea, five sharp opinions
dbt Semantic Layer/MetricFlow, Looker LookML, Cube, and commercial tools (GoodData, AtScale) express the same idea differently: code-first, GUI-authoring, or API-first. Choose by team and stack.
What you will learn
- Compare dbt MetricFlow, LookML and Cube approaches
- Match tool choice to team archetype
- Describe a headless semantics: definitions vs serving
What is this?
The semantic-layer idea ships in different shapes: MetricFlow (dbt Semantic Layer) keeps metrics in YAML riding the dbt project; LookML (Looker) builds the whole explore from code; Cube is a headless-API metrics store for apps; AtScale/GoodData bring GUI-governed layers. The tool choice rides on who authors, how it's served, and where the stack lives.
Why do you need it?
- Authoring experience decides adoption: analysts vs engineers vs business users.
- Serving story matters: direct SQL, REST API, or embedded BI.
- Code-first layers ride existing dbt/CI pipelines; GUI layers fit governance shops.
- Interviews test awareness of the tool landscape, not just one vendor.
Mental model
Car rentals: sedan SUV, van, sports
Semantic layer tools
For a road trip you pick by passengers + luggage (team + stack). An engineer-run dbt shop picks code-first MetricFlow; an app team serving dashboards to users picks an API-first Cube; a governed GUI shop picks AtScale. Same purpose, different drivers.
How it works
- MetricFlow/dbt: metrics defined in YAML; dbt compiles + serves via SQL; deep integration with the existing dbt project.
- LookML: Looker files (views, explores) are the model; Looker generates SQL to the warehouse.
- Cube: a headless API layer with data modeling, caching and REST/SQL/GraphQL to apps.
- Commercial GUI layers: AtScale/GoodData/Cognos mask the schema with admin-led governance.
- They converge: all expose a vocabulary + serving endpoint; delivery differs.
Terminal dimensions of layer tools.
Examples
The same metric in three dialects
-- dbt MetricFlow (YAML):metrics: - name: revenue type: sum path: fact_sales label: Revenue -- LookML:dimension: revenue { type: sum sql: ${orders.amount} ;;} -- Cube:measures: { revenue: { type: "sum", sql: "amount" } }Conceptually identical; the difference is the surrounding workflow — dbt's CI, Looker's explore, or Cube's API.
In production
- A dbt-first data team layers MetricFlow on the existing project — same PRs/tests.
- A SaaS product embeds Cube so the UI auto-queries the metric store.
- A BI-governance shop centralizes LookML explores so users never hand-join.
Best practices
- Match tooling to who authors: engineers → code-first; admins → GUI layers.
- Keep one layer, not five overlapping ones.
- Verify serving latency for the consumer set (SQL vs API vs embedded).
- Ride the same CI/versioning your warehouse models already use.
Common mistakes
- Buying a heavyweight GUI layer for an engineer-owned dbt shop (and vice versa).
- Layer tools multiplying 'metrics' across two systems.
- Ignoring serving path: an elegant layer that can't feed your front-end is a museum.
- Locking a layer to a warehouse vendor's quirks.
Debugging tips
- Layer 'works' but silent → check how consumers call it; enforce the serving endpoint.
- Query slow → inspect the generated SQL/Cube pre-aggregation plan.
- Two layers disagree → consolidate; declare a single 'source of truth' layer.
Interview checkpoint
Quick quiz
Which layer tool is designed primarily for app/embedded consumption via API?
Looker's LookML defines the semantic model in code files.