Getting started with Looker

Best Practices

Documentation

Community

Training

Certification

Articles in this section

See more

What is LookML?

Avatar
Looker Support
  • Updated
Follow

LookML is a language for describing dimensions, aggregates, calculations, and data relationships in a SQL database. Looker uses a model written in LookML to construct SQL queries against a particular database.

LookML projects

A LookML project is a collection of model, view, and dashboard files that are typically version controlled together via a Git repository. The model files contain information about which tables to use, and how they should be joined together. The view files contain information about how to calculate information about each table (or across multiple tables if the joins permit them).

LookML separates structure from content, so the query structure (how tables are joined) is independent of the query content (the columns to access, derived fields, aggregate functions to compute, and filtering expressions to apply).

SQL queries generated by Looker

For data analysts, LookML fosters DRY style (“don’t repeat yourself”), meaning you write SQL expressions once, in one place, and Looker uses the code repeatedly to generate ad hoc SQL queries. For business users, the end result is the ability to build complex queries in Looker, focusing only on the content they need, not the complexities of SQL structure.

The following figure shows a query, built in Looker, that joins values from multiple tables — Orders Items, Products, and Users:

In the figure above, the end-user doesn’t need to understand SQL expressions for joins or filtering.

A dependency language for describing data structures

LookML is a dependency language like make, as opposed to an imperative language like C or Ruby. LookML provides predefined data types and syntax for data modeling. LookML syntax has a structure that is clear and easy to learn. (You don’t need prior experience with programming languages, everything you need to know is documented here.) LookML is independent of particular SQL dialects, and encapsulates SQL expressions to support any SQL implementation.

Code sample

The example below shows a minimal LookML project for an e-commerce store, which has a model file and two view files:

###################################### # FILE: ecommercestore.model.lkml # # Define the explores and join logic # ###################################### connection: order_database include: "*.view.lkml" explore: orders { join: customers { sql_on: ${orders.customer_id} = ${customers.id} ;; } }   ########################################################## # FILE: orders.view.lkml # # Define the dimensions and measures for the ORDERS view # ########################################################## view: orders { dimension: id { primary_key: yes type: number sql: ${TABLE}.id ;; } dimension: customer_id { # field: orders.customer_id sql: ${TABLE}.customer_id ;; } dimension: amount { # field: orders.amount type: number value_format: "0.00" sql: ${TABLE}.amount ;; } dimension_group: created { # generates fields: type: time # orders.created_time, orders.created_date timeframes: [time, date, week, month] # orders.created_week, orders.created_month sql: ${TABLE}.created_at ;; } measure: count { # field: orders.count type: count # creates a sql COUNT(*) drill_fields: [drill_set*] # list of fields to show when someone clicks 'ORDERS Count' } measure: total_amount { type: sum sql: ${amount} ;; } set: drill_set { fields: [id, created_time, customers.name, amount] } }   ############################################################# # FILE: customers.view.lkml # # Define the dimensions and measures for the CUSTOMERS view # ############################################################# view: customers { dimension: id { primary_key: yes type: number sql: ${TABLE}.id ;; } dimension: city { # field: customers.city sql: ${TABLE}.city ;; } dimension: state { # field: customers.state sql: ${TABLE}.state ;; } dimension: name { sql: CONCAT(${TABLE}.firstname, " ", ${TABLE}.lastname) ;; } measure: count { # field: customers.count type: count # creates a sql COUNT(*) drill_fields: [drill_set*] # fields to show when someone clicks 'CUSTOMERS Count' } set: drill_set { # set: customers.drill_set fields: [id, state, orders.count] # list of fields to show when someone clicks 'CUSTOMERS Count' } }

LookML is case-sensitive

LookML is case-sensitive, so be sure to match the case when referring to LookML elements. Looker will alert you if you have referred to an element that doesn’t exist. In the example below, the developer has incorrectly capitalized “FLIGHTS.” The Looker IDE shows a warning that the e_FLIGHTS_pdt does not exist. In addition, the IDE suggests the name of an existing Explore, which is e_flights_pdt:

However, if your project contained both e_FLIGHTS_pdt and e_flights_pdt, the Looker IDE would not be able to correct you, so you would have to be sure which version you intended. Generally, it’s a good idea to stick with lowercase when naming LookML objects.

IDE folder names are also case-sensitive. You must match the capitalization of folder names whenever you specify file paths. For example, if you have a folder named Views, you must use this same capitalization in the include parameter. Again, the Looker IDE will indicate an error if your capitalization doesn’t match an existing folder in your project:

Overview of fundamental LookML elements

The following diagram shows fundamental LookML elements and their relationships. For more detail, see LookML terms and concepts.

Related articles