What Is the Looker Semantic Layer? LookML Explained
The Looker semantic layer is LookML, the Looker Modeling Language that Google's Looker uses to define dimensions, measures, calculations, and the joins between tables, so every query built in Looker returns numbers from the same definitions. LookML lives in version-controlled files, and Looker's SQL generator turns each request into SQL for the underlying database.
Looker was one of the first BI tools built around a code-based semantic layer, long before the term became popular. What has changed in the last two years is who reads it. LookML is now the source of truth for Gemini in Looker and its Conversational Analytics, for AI agents through the Looker MCP server, and for other tools such as Tableau, Power BI, Excel, and Google Sheets through Looker's connectors.
LookML defines views (how each table is calculated: dimensions and measures), models (which tables are used and how they join), and Explores (the query entry points), stored in Git. Conversational Analytics in Looker uses the LookML model as its source of truth, and the Looker-managed MCP server, generally available since October 2026, lets AI agents query LookML models. Outside Looker, BI connectors cover Connected Sheets, Data Studio, Excel, Power BI, and Tableau Desktop, and the Open SQL Interface exposes models over JDBC for BigQuery-backed projects. LookML decides how a metric is calculated in Looker; owners, approved definitions, and lineage across platforms come from a context layer.
What Is the Looker Semantic Layer?
A semantic layer sits between raw tables and the people and tools asking questions, and translates one into the other. In Looker that layer is LookML. Analysts and analytics engineers describe the database once, in LookML files, and business users then explore data by choosing dimensions and measures in an Explore, without writing SQL. Because every query goes through the model, "revenue" in one dashboard is calculated the same way as "revenue" in the next.
The same model can increasingly be queried from outside Looker too, by AI agents and by other BI tools. That broader use is covered below in using LookML outside Looker.
How LookML Works
A LookML project is a collection of files, typically version-controlled together in a Git repository. The main objects are:
- Views, which describe how information is calculated for each table: the dimensions (attributes to group and filter by) and the measures (aggregations such as counts, sums, and averages).
- Models, which state which tables the project uses and how they should be joined.
- Explores, defined in models, which are the starting points users pick in the Explore panel.
A minimal view looks like this:
view: orders {
sql_table_name: analytics.orders ;;
dimension: status {
type: string
sql: ${TABLE}.status ;;
}
measure: total_revenue {
type: sum
sql: ${TABLE}.amount ;;
}
}When a user builds a query in an Explore, Looker's SQL generator translates the chosen fields into SQL, runs it against the database, and returns the results. The definitions are code, so they get the same pull requests, reviews, and validation as other analytics code. Since September 2026 the Looker extension for VS Code is generally available and supports AI-assisted LookML development, including validation, through the Looker MCP server.
Gemini in Looker and LookML
Gemini in Looker is the family of AI features in Looker, and the most visible one is Conversational Analytics: users ask a question in natural language, Conversational Analytics picks the LookML fields, filters, and sorts, and Looker composes and runs the query from the model, so the agent does not write the joins itself. Google states that Conversational Analytics uses the Looker semantic model, the LookML definitions of your data, as its source of truth, so answers stay consistent with dashboards built on the same model.
Recent milestones from the Looker release notes:
- Verified queries, known-good question and query pairs that ground answers, became generally available in August 2026.
- Data agents for dashboards, including agents defined directly in version-controlled LookML for LookML dashboards, became generally available in October 2026.
- The Expression Assistant (July and August 2026) and the Visualization Assistant (October 2026) are generally available; scheduled agentic workflows for data agents are in preview.
The quality of these answers depends on the quality of the model. Gemini can only pick a field that exists and is described well, which is why descriptions, labels, and clear naming in LookML now matter for AI as much as for human users.
Looker MCP Server
On October 26, 2026, Google made the Looker-managed MCP server generally available. It lets AI agents interact with business data and LookML models without extra middleware, and it comes with a new Manage OAuth Clients admin page for controlling which external applications can connect. For developers, the same server backs the Looker extension for VS Code, where an agent can read local LookML, inspect database schemas, generate view boilerplate from a table, and run LookML validation.
The MCP server is what makes LookML relevant beyond Looker's own interface. An assistant such as Claude or a custom agent can ask Looker for a measure by name and receive a number calculated from the governed model, instead of generating its own SQL against raw tables. The general pattern is explained in what Model Context Protocol (MCP) is.
Using LookML Outside Looker
Google offers several ways to reuse LookML definitions in other tools:
- BI connectors. Looker lists connectors for Google Sheets (Connected Sheets), Data Studio, Microsoft Excel, Microsoft Power BI, and Tableau Desktop, with Tableau Cloud and Tableau Server configured separately. In Looker (Google Cloud core) the ability to connect other BI tools is on by default; in Looker (original) an admin has to enable it.
- Open SQL Interface. Any JDBC-capable application, such as Tableau or ThoughtSpot, can query LookML models as if they were a database: models appear as schemas, Explores as tables, and fields as columns. Google documents limits: the LookML project must use a BigQuery connection, only SELECT queries are supported (no joins, window functions, or subqueries, since joins belong in LookML), and measures must be wrapped in
AGGREGATE(). - In-database models. A preview feature,
model_source, lets teams define in-database analytic models such as BigQuery Graphs or Snowflake semantic views from LookML Explores. Snowflake in turn lists Looker, in preview, among the BI tools that work with its semantic views. - Metadata for catalogs. On Looker (Google Cloud core), Knowledge Catalog ingestion of Looker metadata and Looker data lineage, covering LookML dashboards and Conversational Analytics agents, became generally available in October 2026.
The direction is clear: LookML is moving from a BI tool's internal model toward a semantic layer other tools and agents can query, with the deepest openness today on BigQuery and Google Cloud.
LookML vs Other Semantic Layers
| Semantic layer | Where definitions live | Main consumers | Scope |
|---|---|---|---|
| Looker (LookML) | LookML files in Git, inside a Looker project | Looker, Gemini, MCP agents, BI connectors | Databases Looker connects to |
| dbt Semantic Layer | YAML in the dbt project, run by MetricFlow | BI integrations, APIs, dbt MCP server | Models built with dbt |
| Databricks metric views | YAML objects in Unity Catalog | AI/BI dashboards, Genie, SQL, external BI | Data in Databricks |
| Snowflake semantic views | Native Snowflake schema objects | Cortex Analyst, BI tools | Data in Snowflake |
| Tableau Semantics | Semantic models in Tableau Next and Data 360 | Tableau Next, Agentforce, Tableau via connector | Data in Data 360 |
Each of these calculates metrics consistently within its own scope. None of them, on its own, records who in the business approved a definition or traces a number across every platform it passes through. That is the difference between a semantic layer and a context layer, covered in context layer vs semantic layer and, for knowledge graphs, ontology vs semantic layer. A ranked comparison of tools is in the best semantic layer tools.
How Dawiso Works With a Looker Stack
In a Looker stack, Dawiso covers the layers around LookML. It reads metadata from more than 30 sources, including the warehouses and pipelines Looker typically queries, such as Google BigQuery, Snowflake, Databricks, and dbt. Scanning is read-only and copies no rows.
On top of that metadata, the business glossary holds the approved definition of a metric that a LookML measure implements, with the person who owns it, and lineage shows where the data in the warehouse comes from. AI tools that support MCP, such as Claude and Cursor, can query Dawiso through the Dawiso MCP Server and get the definition, owner, and lineage along with the number, so an agent that gets a figure from Looker can also explain what it means and where it came from.
Conclusion
LookML has been Looker's semantic layer from the start: dimensions, measures, and joins defined once in code and reused by every Explore. In 2026 it became something more, the source of truth for Gemini's Conversational Analytics, for AI agents through a generally available MCP server, and for Tableau, Power BI, Excel, and Sheets through Looker's connectors. What LookML does not hold is the business agreement behind each measure and the lineage outside Looker, which is the job of the context layer around it.
Sources
- Google Cloud - What is LookML?
- Google Cloud - Conversational Analytics in Looker overview
- Google Cloud - Looker release notes (entries from July to October 2026)
- Google Cloud - AI-assisted development with Looker
- Google Cloud - Looker BI connectors
- Google Cloud - Looker Open SQL Interface
- Snowflake - Snowflake Horizon Context: the governed context layer for AI, BI and apps (June 2026)
See it in action
Business Glossary
Clear context is essential to ensure everyone interprets terms consistently and accurately.