LookML — Views, Fields, and the SQL Compiler

The grand-daddy of semantic layers

Looker (now part of Google Cloud) shipped its declarative modelling language LookML in 2012, years before 'semantic layer' became a buzzword. Every modern semantic layer borrows from its design.

The core file: a view

A LookML view describes one physical table:

view: orders {
  sql_table_name: analytics.fct_orders ;;

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

  dimension: country {
    type: string
    sql: ${TABLE}.country ;;
  }

  dimension_group: order {
    type: time
    timeframes: [date, week, month, quarter, year]
    sql: ${TABLE}.order_ts ;;
  }

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.amount_cents / 100.0 ;;
    value_format_name: usd
  }
}

Three LookML-isms worth pointing out:

• ${TABLE} and ${field_name} — the substitution system. Looker rewrites these to fully-qualified column refs at compile time, which is what makes derived measures (${total_revenue} / ${count}) refactor-safe.
• dimension_group: time — one declaration produces every requested timeframe (day, week, month, quarter, year). No more re-writing DATE_TRUNC boilerplate in five places.
• value_format_name — formatting is part of the model, so every dashboard renders dollars consistently.

LookML is a Wikipedia infobox template. An editor fills in fields once (birth_date, nationality, occupation) and every article that uses the template renders a consistent, structured sidebar — without anyone re-formatting the same data on each page. LookML views are the templates, Looker dashboards are the articles, and dimension_group: time is the trick that turns one infobox field into all the renderings the wiki could ever need.