Analytics & BI Tools · Chapter 4 of 8
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.