What is LookML in Looker?

If you're using Looker, you can't go far without running into LookML. It's the unique language that acts as the brain behind every dashboard and report you see. This article will break down exactly what LookML is, explain its core components, and show you why it’s so powerful for businesses that want to build a reliable data culture.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

So, What Exactly Is LookML?

LookML, which stands for Looker Modeling Language, is the language used in Looker to describe the dimensions, measures, calculations, and data relationships within a SQL database. It’s not a language used to store your data, instead, it provides a layer of instructions that tells Looker how to interpret your database and generate SQL queries on the fly.

Think of it like this: your database is a giant warehouse full of raw ingredients (your tables and columns of data). LookML is the master recipe book that tells the chef (Looker) how to find those ingredients, how they relate to each other (e.g., this user information goes with that order information), and how to combine them into finished dishes (reports and charts).

Essentially, LookML separates the business logic - your company's unique definitions for things like "revenue," "active users," or "customer lifetime value" - from the raw data itself. By defining these business rules in one place, everyone in the organization can access and analyze data using the same consistent definitions, creating a true "single source of truth."

Why LookML Matters: Building a Single Source of Truth

Most businesses struggle with data chaos. The marketing team calculates "customer acquisition cost" one way in a Google Sheet, while the finance team calculates it another way in Excel. Sales reports might count a "deal" as soon as it's verbally committed, but operations only count it after the invoice is paid. The result? Endless meetings where teams argue about whose numbers are correct, wasting time and eroding trust in data.

This is the exact problem LookML was designed to solve. It creates a centralized data model where a data analyst or developer can define key business metrics once. They write the business logic in LookML code, a reusable and maintainable format.

• Consistency: When a marketer builds a report on customer acquisition cost, they are using the same officially defined customer_acquisition_cost measure as the CEO. No more duplicate, conflicting definitions.
• Reusability: Instead of writing a complex 200-line SQL query every time someone needs to see session data joined with purchase data, you define that relationship once in LookML. Now, any Looker user can simply select fields from both datasets, and LookML generates the complex SQL JOIN automatically.
• Governance: The data team maintains control over the core logic. They can ensure calculations are accurate and definitions are correct, all while empowering non-technical users to explore the data safely on their own.

This governed, self-service model is LookML’s greatest strength. It bridges the gap between the complex backend database and the front-end business user who just wants a clear answer to their question.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

The Core Components of a LookML Project

A LookML project is organized into several key file types that work together to create the data model. Understanding these building blocks is the first step to mastering LookML.

Models

The model file is the top-level orchestrator of your project. It’s where you specify which database connection to use and define the different "Explores" that will be available to users. Each project typically has at least one model file. You might have separate models for different departments, like a marketing model and a finance model.

Views

A view file directly corresponds to a table in your database (or a derived table you create with SQL). This is where you define the accessible fields from that table. Inside a view, you’ll define two main types of fields: dimensions and measures.

Dimensions

Dimensions are the “group-by” fields - the attributes, qualities, and characteristics of your data. Think of them as the columns you would use in the rows or columns of a pivot table. They describe your data.

• Examples: User ID, Order Date, Product Category, Geographic Region, Traffic Source.

You can create different types of dimensions, such as number, string, and time. For time-based fields, LookML makes it incredibly easy to create dimension_groups, which automatically break out a single timestamp into useful increments like date, week, month, quarter, and year.

Measures

Measures are your aggregated values. They perform calculations across multiple rows of data, like sums, counts, averages, minimums, or maximums. These are the values you want to measure.

• Examples: Total Sales (a sum of sales price), Count of Orders (a count of order IDs), Average Session Duration (an average of session time).

Measures are fundamentally defined by the dimensions. For instance, a measure for total_revenue would be defined as a sum of a dimension like order_item_price.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Explores

An “Explore” is what brings everything together for the business user. Defined within the model file, an Explore is a user-friendly starting point for a query. It typically begins with a base view and then specifies how other views can be joined to it. When an employee logs in to Looker to build a report, the list of choices they see on the left-hand navigation menu are the Explores you've created.

Joins

Inside an explore definition, you specify the join relationships between views. For example, you would join your orders view to your users view on user_id. LookML lets you define the join type (like left_outer), the relationship (like one_to_many), and the SQL condition for joining. Once this join is defined in the LookML model, users don't have to think about it, they can just pull fields from both orders and users, and Looker knows exactly how to connect them.

A Simple LookML Example: E-commerce Reporting

Let's make this concrete. Imagine you run an online store and want to analyze sales data. Your database has an orders table.

Your goal: let your team build a report showing the total number of orders and total revenue per week.

Step 1: Create the View File (orders.view.lkml)

First, you’d create a view file for your orders table. It would list the relevant columns from that table as dimensions and define your key metrics as measures.

view: orders {
  sql_table_name: `ecommerce.orders` ,,

  dimension: order_id {
    primary_key: yes
    type: number
    sql: ${TABLE}.id ,,
  }

  dimension: sale_price {
    type: number
    sql: ${TABLE}.sale_price ,,
  }

  dimension_group: created {
    type: time
    timeframes: [raw, time, date, week, month, year]
    sql: ${TABLE}.created_at ,,
  }

  measure: count {
    type: count
    drill_fields: [order_id, users.first_name, users.last_name]
  }

  measure: total_revenue {
    type: sum
    sql: ${sale_price} ,,
    value_format_name: usd_0
  }
}

In this simple file, we've:

• Told LookML our database table is named ecommerce.orders.
• Defined dimensions for order_id and sale_price.
• Created a dimension_group called created that gives users easy access to week, month, etc., from the created_at timestamp.
• Defined a measure called count to count the total number of orders.
• Defined another measure called total_revenue that sums the sale_price dimension.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Step 2: Create the Model File and Explore (ecommerce.model.lkml)

Next, you would create a model file to make this view available as an "Explore." This file tells Looker what database to connect to and which views to expose.

connection: "my_ecommerce_database"

include: "*.view.lkml"

explore: orders {}

Here, we've told Looker to use the "my_ecommerce_database" connection and have defined an Explore named orders. That’s all it takes to make the view accessible.

Step 3: The User Experience

Now, a user can log into Looker, select the "Orders" Explore, and they'll see a list of available dimensions and measures like "Created Week," "Count," and "Total Revenue." They can click on those fields, hit "Run," and Looker instantly writes the necessary SQL in the background to generate the report. They get a powerful, accurate answer without writing a single line of SQL or even knowing what GROUP BY means.

The Business Benefits of Committing to LookML

While learning LookML involves an initial ramp-up for your data team, the long-term benefits for the entire organization are massive.

• Data Democratization: It allows non-technical team members - from marketing and sales to operations and C-level execs - to confidently explore data and answer their own questions without joining the data team’s backlog.
• Increased Analyst Efficiency: Instead of servicing hundreds of one-off report requests, your data analysts can focus on building and expanding the LookML model. They solve a data problem once, and it serves the entire company forever. This lets them concentrate on deeper, more strategic analysis.
• Better, Faster Decisions: When everyone trusts the data and can access it quickly, the pace of decision-making accelerates. You can spot trends sooner, react to changes faster, and align the entire company around the same set of observable facts.
• Scalable and Maintainable: Since LookML is code, it lives in a Git repository. This brings all the benefits of software engineering to analytics: version control, peer review, and collaboration. As your company and its data complexity grow, your data model can grow in a controlled, scalable way.

Final Thoughts

LookML serves as the powerful engine within Looker, transforming complex database schemas into a user-friendly, business-centric analytical environment. By creating a reusable, governed layer of business logic, it empowers entire organizations to move beyond arguing over data and start making collaborative, insight-driven decisions.

While LookML was a huge step forward in making data modeling accessible, it still requires analysts who can work with code. Our approach at Graphed is to let you skip the modeling language entirely. We believe the future of data analysis is conversational. After connecting your data sources in a few clicks, you can simply ask questions in plain English - like "show me my total revenue by week for the last quarter" - and our AI builds the charts and dashboards for you instantly. You get the power of a governed BI tool without anyone on your team needing to learn a new coding dialect.