Como incorporar SQL e se referir a objetos LookML

Para criar um LookML avançado, é preciso ser capaz de referenciar dimensões, medidas, visualizações ou tabelas derivadas existentes, mesmo que não estejam no escopo atual. Você também precisa fazer referência a colunas na tabela subjacente e usar as chamadas de função do dialeto do banco de dados para manipular esses valores.

Operador de substituição ($)

O operador de substituição $ torna o código LookML mais reutilizável e modular. Assim, é possível referenciar outras visualizações e tabelas derivadas, colunas em uma tabela SQL ou dimensões e medições do LookML. Isso é bom por dois motivos. Primeiro, você pode já ter trabalhado com uma dimensão ou medição realmente complicada e não precisa escrever toda a complexidade novamente. Em segundo lugar, se você alterar algo em uma dimensão ou medida, essa alteração poderá ser propagada para todo o resto que depende dela.

Há várias maneiras de usar o operador de substituição:

${TABLE}.column_name faz referência a uma coluna na tabela que está conectada à visualização em que você está trabalhando. Exemplo:

dimension: customer_id {
  type: number
  sql: ${TABLE}.customer_id ;;
}

${field_name} faz referência a uma dimensão ou medida na visualização em que você está trabalhando. Exemplo:

measure: total_population {
  type: sum
  sql: ${population} ;;
}

${view_name.field_name} faz referência a uma dimensão ou medida de outra visualização. Exemplo:

dimension: lifetime_orders {
  type: number
  sql: ${user_order_facts.lifetime_orders} ;;
}

${view_name.SQL_TABLE_NAME} faz referência a outra visualização ou tabela derivada. Observe que SQL_TABLE_NAME nesta referência é uma string literal. Você não precisa substituí-la por nada. Exemplo:

explore: trips {
  view_label: "Long Trips"
  # This will ensure that we only see trips that are longer than average!
  sql_always_where: ${trips.trip_duration}>=(SELECT tripduration FROM ${average_trip_duration.SQL_TABLE_NAME});;
}

${view_name.SQL_TABLE_NAME} não funciona com o parâmetro sql_trigger usado com datagroups.

Escopo e nomenclatura

Você pode nomear "Explores", visualizações, campos e conjuntos. Esses identificadores do Looker são escritos sem aspas.

Os campos e conjuntos do LookML têm nomes completos e nomes curtos:

  • Os nomes completos estão no formato <view>.<field-name | set-name>. O lado esquerdo indica o escopo, que é a visualização que contém o campo ou o conjunto. O lado direito especifica o campo ou nome do conjunto específico.
  • Os nomes curtos simplesmente assumem o formato <field-name | set-name>, sem ponto de separação. O Looker expande nomes curtos em nomes completos com o escopo em que eles são usados.

Veja abaixo um exemplo que mostra várias formas de nomes e escopo. Esse grupo de campos não é realista, mas é mostrado para demonstrar várias expressões de escopo possíveis.

view: orders {                   # "orders" becomes the containing scope
  measure: count {               # short name, equivalent to orders.count
    type: count
  }
  dimension: customer_id {       # short name, equivalent to orders.customer_id
    type: number
    sql: ${TABLE}.customer_id ;;
  }
  dimension: customer_address {  # short name, equivalent to orders.customer_address
    sql: ${customer.address} ;;  # full name, references a field defined in the "customer" view
  }
  set: drill_fields {            # short name, equivalent to orders.drill_fields
    fields: [
      count,                     # short name, equivalent to orders.count
      customer.id                # full name, references a field defined in the "customer" view
    ]
  }
}

Na declaração dimension: customer_address acima, observe que a visualização subjacente do bloco SQL (customer) é diferente do escopo da visualização delimitada (orders). Isso pode ser útil quando você precisa comparar campos entre duas visualizações diferentes.

Quando uma visualização (chamá-la de "visualização A") se referir a um campo definido em uma visualização diferente (chamá-la de "visualização B"), há alguns pontos a serem considerados:

  1. O arquivo da visualização B precisa ser incluído no mesmo modelo da visualização A usando o parâmetro include.
  2. A visualização B precisa ser unida para que a A esteja em um ou mais Explores. Consulte a página Como trabalhar com mesclagens no LookML para saber mais.

Dialeto SQL

O Looker é compatível com muitos tipos de banco de dados, como MySQL, Postgres, Redshift, BigQuery e assim por diante. Cada banco de dados oferece suporte a um conjunto de recursos ligeiramente diferente com nomes de função distintos, conhecido como dialeto SQL.

O LookML foi projetado para funcionar com todos os dialetos SQL, e o LookML não dá preferência a um dialeto. No entanto, você vai precisar incluir expressões de código SQL (conhecidas como blocos SQL) em determinados parâmetros do LookML. Com esses parâmetros, o Looker transmite a expressão SQL diretamente para o banco de dados. Por isso, você precisa usar o dialeto SQL correspondente ao banco de dados. Por exemplo, se você usar uma função SQL, ela precisa ser compatível com seu banco de dados.

Blocos de SQL

Alguns parâmetros do LookML exigem que você forneça expressões SQL brutas para que o Looker possa entender como extrair dados do banco de dados.

Os parâmetros do LookML que começam com sql_ esperam uma expressão SQL de algum formato. Por exemplo: sql_always_where, sql_on e sql_table_name. O parâmetro LookML mais comum para blocos SQL é sql, usado nas definições de campos de dimensão e medida para especificar a expressão SQL que define a dimensão ou medida.

O código especificado em um bloco de SQL pode ser tão simples quanto um único nome de campo ou complexo como uma subseleção correlacionada. O conteúdo pode ser bastante complexo, acomodando quase qualquer necessidade que você possa ter de expressar a lógica de consulta personalizada em SQL bruto. Observe que o código usado nos blocos SQL precisa corresponder ao dialeto SQL usado pelo banco de dados.

Exemplos de blocos SQL para dimensões e medidas

Confira abaixo exemplos de blocos SQL para dimensões e medidas. O operador de substituição LookML ($) (link em inglês) pode fazer com que essas declarações sql apareçam de maneira enganosa ao contrário do SQL. No entanto, após a substituição, a string resultante é SQL puro, que o Looker injeta na cláusula SELECT da consulta.

dimension: id {
  primary_key: yes
  sql: ${TABLE}.id ;;   # Specify the primary key, id
}
measure: average_cost {
  type: average
  value_format: "0.00"
  sql: ${order_items.cost} ;;   # Specify the field that you want to average
}
dimension: name {
  sql: CONCAT(${first_name}, ' ', ${last_name}) ;;
}
dimension: days_in_inventory {
  type: int
  sql: DATEDIFF(${sold_date}, ${created_date}) ;;
}

Como mostrado nas duas últimas dimensões acima, os blocos SQL podem usar funções compatíveis com o banco de dados subjacente (como as funções CONCAT e DATEDIFF do MySQL neste exemplo).

Exemplo de bloco de SQL com uma subseleção correlacionada

Você pode colocar qualquer instrução SQL no bloco SQL de um campo, incluindo uma subseleção correlacionada. Veja um exemplo abaixo:

view: customers {
  dimension: id {
    primary_key: yes
    sql: ${TABLE}.id ;;
  }
  dimension: first_order_id {
    sql: (SELECT MIN(id) FROM orders o WHERE o.customer_id=customers.id) ;;
         # correlated subselect to derive the value for "first_order_id"
  }
}

Exemplo de bloco de SQL para tabelas derivadas

As tabelas derivadas usam o bloco SQL para especificar a consulta que deriva a tabela. Veja um exemplo abaixo:

view: user_order_facts {
  derived_table: {
    sql:            # Get the number of orders for each user
      SELECT
        user_id
        , COUNT(*) as lifetime_orders
      FROM orders
      GROUP BY 1 ;;
  }
  # later, dimension declarations reference the derived column(s)

  dimension: lifetime_orders {
    type: number
  }
}

Referências de tipo de campo do LookML

Ao referenciar um campo do LookML atual em outro campo, é possível instruir o Looker a tratar o campo referenciado como um tipo de dado específico usando dois-pontos (::) seguidos pelo tipo desejado. Por exemplo, se você referenciar a dimensão orders.created_date em outro campo, poderá usar a sintaxe ${orders.created_date::date} para garantir que o campo created_date seja tratado como um campo de data no SQL gerado pelo Looker, em vez de ser transmitido como uma string.

O tipo de dado que pode ser usado em uma referência depende do tipo de dado do campo original que você está referenciando. Por exemplo, se estiver fazendo referência a um campo de string, o único tipo de dado que pode ser especificado é ::string. Veja a seguir a lista completa de referências de tipo de campo permitidas que podem ser usadas para cada tipo:

  • Em uma referência a um campo de string, você pode usar ::string.
  • Em uma referência a um campo numérico, é possível usar ::string e ::number.
  • Em uma referência a um campo de data ou hora, você pode usar ::string, ::date e ::datetime.

    As referências que usam ::string e ::date retornam dados no fuso horário da consulta, enquanto as que usam ::datetime retornam dados no fuso horário do banco de dados.
  • Em uma referência a um campo yesno, você pode usar ::string, ::number e ::boolean.

    As referências de campo que usam o tipo ::boolean não estão disponíveis para dialetos de banco de dados que não são compatíveis com o tipo de dados booleano.
  • Em uma referência a um campo de local, você pode usar ::latitude e ::longitude.

Como usar referências de tipo de campo do LookML com campos de data

Por exemplo, suponha que você tenha uma dimensão enrollment_month e uma graduation_month, ambas criadas nos grupos de dimensões de type: time. Neste exemplo, a dimensão enrollment_month é produzida pelo seguinte grupo de dimensões de type: time:


dimension_group: enrollment {
  type: time
  timeframes: [time, date, week, month, year, raw]
  sql: ${TABLE}.enrollment_date ;;
}

Da mesma forma, a dimensão graduation_month é criada pelo seguinte grupo de dimensões de type: time:


dimension_group: graduation {
  type: time
  timeframes: [time, date, week, month, year, raw]
  sql: ${TABLE}.graduation_date ;;
}

Usando as dimensões enrollment_month e graduation_month, é possível calcular quantos meses ou anos se passaram entre a matrícula e a graduação de um estudante, criando um grupo de dimensão de type: duration. No entanto, como alguns campos de data são convertidos como strings no SQL gerado pelo Looker, definir as dimensões enrollment_month e graduation_month como valores para sql_start e sql_end pode resultar em um erro.

Para evitar um erro resultante da transmissão desses campos de tempo como strings, uma opção é criar um grupo de dimensões de type: duration, referenciando os períodos raw dos grupos de dimensão enrollment e graduation nos parâmetros sql_start e sql_end:


dimension_group: enrolled {
  type: duration
  intervals: [month, year]
  sql_start: ${enrollment_raw} ;;
  sql_end: ${graduation_raw} ;;
}

Na interface do Explore, isso gera um grupo de dimensões chamado Duração do cadastro, com dimensões individuais Meses de inscrição e Anos de inscrição.

Uma alternativa mais simples ao uso do período de tempo raw em um grupo de dimensões de type: duration é especificar o tipo de referência ::date ou ::datetime para os campos referenciados nos parâmetros sql_start e sql_end.


dimension_group: enrolled {
  type: duration
  intervals: [month, year]
  sql_start: ${enrollment_month::date} ;;
  sql_end: ${graduation_month::date} ;;
}

O LookML neste exemplo também cria um grupo de dimensões Duração registrada, mas o uso da referência ::date permite que as dimensões enrollment_month e graduation_month sejam utilizadas sem usar um período de tempo raw nem transmiti-las como strings com SQL.

Se quiser outro exemplo de como as referências ao tipo de campo do LookML podem ser usadas para criar grupos de dimensões personalizadas de type: duration, consulte a página de documentação do parâmetro dimension_group.

Essa sintaxe não está disponível com medidas de type: list, que não podem ser referenciadas no Looker 6.8.

Constantes do LookML

O parâmetro constant permite especificar uma constante que pode ser usada em um projeto do LookML. Com as constantes do LookML, você pode definir um valor uma vez e referenciá-lo em qualquer parte do projeto em que strings sejam aceitas, reduzindo assim a repetição no código LookML.

Constantes precisam ser declaradas em um arquivo de manifesto de projeto, e o valor de uma constante precisa ser uma string. Por exemplo, você pode definir uma constante city com o valor "Okayama" desta maneira:

constant: city {
  value: "Okayama"
}

A constante city pode ser referenciada em todo o projeto usando a sintaxe @{city}. Por exemplo, você pode usar a constante city com o parâmetro label na Análise users:


explore: users {
  label: "@{city} Users"
}

Em seguida, o Looker mostra os Usuários do Okayama no menu Explorar e no título da opção "Explorar", em vez da opção Usuários padrão.

Para mais informações e exemplos de como usar constantes do LookML para escrever código reutilizável, consulte a página de documentação do parâmetro constant.