Analytics & BI Tools · Chapter 4 of 18
Looker, and the semantic-layer approach
The tool that took the opposite bet — model first, visualise second. Why that matters more than it sounds.
Looker's design decision is that the metric definition belongs in a modelled, version-controlled layer — LookML — and that reports are consumers of it rather than authors of it. That is a governance position expressed as a product.
What that buys
- One definition, enforced. If revenue is defined in LookML, every report uses that definition. The 'two dashboards disagree' problem largely disappears by construction.
- Version control and code review for the semantic layer, so metric changes go through the same process as code.
- Queries are generated against the warehouse rather than extracted, so there is no copy to go stale — and the warehouse does the work.
- Governed self-service is genuinely achievable: users explore freely within definitions somebody owns.
What it costs
You must model before you get value. There is real upfront work and it needs someone who can write LookML. Organisations wanting a dashboard this week find this frustrating.
Every interaction is a warehouse query. Excellent for freshness and governance, and it makes your warehouse bill a function of dashboard usage — which is a genuine cost pattern to plan for.
Visualisation is adequate rather than exceptional. If visual craft is the priority, this is not the strongest tool.
Licensing is enterprise-priced and the pricing is less transparent than the alternatives.
The broader point outlives the product: the semantic layer is now a category — dbt's semantic layer, Cube, and Power BI's datasets all implement the same idea. If you take one thing from this book, take the argument that the definition belongs above the dashboard and below the warehouse.
What the semantic layer actually buys you
Most business-intelligence tools let you build a chart and define the logic on the way. This one inverts that: you define the model first, in code, and every chart is generated from it. The consequence is not aesthetic — it is that a metric has exactly one definition and everything that renders it is downstream of that definition.
| Concept | What it is | Why it matters |
|---|---|---|
| View | A table plus its dimensions and measures, declared in code | The measure lives with the data, once, not in each report |
| Explore | A curated join graph someone is allowed to query | The governance surface. It bounds which joins are possible, so a user cannot silently create a wrong one |
| Model | Which explores exist and who may reach them | Where access and curation are expressed |
| Symmetric aggregates | Correct measures across a fan-out join | The genuinely clever part — see below |
Symmetric aggregates, and the bug they exist to prevent
Join a one-row-per-order table to a one-row-per-item table and the order total repeats on every item row. Sum it and revenue is overstated by however many items the order had.
Nothing errors. Every row is real. The number is simply wrong, and it stays wrong until someone reconciles against finance.
This is the single most common serious defect in hand-built BI reports, and it is the same silent-fan-out failure described in the data-modelling chapter.
The semantic layer solves it structurally: it detects the fan-out and computes the aggregate so that the duplicated rows are not double-counted. You do not have to notice the problem to avoid it, which is the property that matters — controls that require vigilance fail eventually.
The cost of this design is real and worth stating: nothing is quick. Adding a field means editing the model, which means a code review, which means the analyst who wanted a column now waits. Teams that adopt this and keep expecting spreadsheet-speed self-service are unhappy, and the unhappiness is with the trade rather than the tool.
When this bet is right, and when it is not
- Right when numbers must agree across the organisation. If two dashboards disagreeing about revenue is a serious problem for you, a single enforced definition is worth the friction.
- Right when the consumers outnumber the authors heavily. The modelling cost is paid once and amortised across everyone querying.
- Wrong for exploratory analysis. If the question is new every week and the shape of the data is still being discovered, modelling first means modelling something you do not understand yet.
- Wrong when there is nobody to own the model. This approach requires a maintained codebase. Without an owner it decays into a model nobody dares change, and then people export to a spreadsheet and you have the worst of both.
- And note the direction of travel: the semantic-layer idea has been widely absorbed — warehouse-native metric layers and transformation frameworks now offer their own versions. The idea won more decisively than any product did, which is the useful thing to say about it in an interview.
Check yourself