Para escrever um LookML eficiente, é necessário fazer referência a dimensões, medidas, visualizações ou tabelas derivadas atuais, mesmo que elas não estejam no escopo atual. Você também precisa fazer referência a colunas na tabela e usar as chamadas de função do seu dialeto de banco de dados para manipular esses valores.
Operador de substituição ($)
O operador de substituição, $, torna o código do LookML mais reutilizável e modular, permitindo que você faça referência a outras visualizações e tabelas derivadas, colunas em uma tabela SQL ou dimensões e medidas do LookML. Isso é bom por dois motivos. Primeiro, talvez você já tenha trabalhado em uma dimensão ou medida muito complicada e não precise escrever toda a complexidade novamente. Em segundo lugar, se você mudar algo em uma dimensão ou medida, essa mudança pode se propagar para tudo o 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 métrica 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. SQL_TABLE_NAME nesta referência é uma string literal. Não é necessário 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âmetrosql_triggerusado com datagroups.
Definição de escopo e nomeação
É possível nomear análises detalhadas, 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 têm o formato
<view>.<field-name | set-name>. O lado esquerdo indica o escopo, que é a visualização que contém o campo ou conjunto. O lado direito especifica o campo ou o nome do conjunto. - Os nomes curtos têm a forma
<field-name | set-name>, sem ponto de separação. O Looker expande nomes curtos em nomes completos usando o escopo em que eles são usados.
Confira a seguir um exemplo que mostra muitos formatos de nomes e escopos. Este é um grupo irrealístico de campos, 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, a visualização subjacente do bloco SQL (customer) é diferente do escopo de visualização de contenção (orders). Isso pode ser útil quando você precisa comparar campos entre duas visualizações diferentes.
Quando uma visualização (vamos chamar de "visualização A") se refere a um campo definido em outra visualização (vamos chamar de "visualização B"), é preciso considerar alguns pontos:
- O arquivo da visualização B precisa ser incluído no mesmo modelo que a visualização A, usando o parâmetro
include. - A visualização B precisa ser combinada com a visualização A em uma ou mais Análises. Consulte a página Como trabalhar com junções no LookML para saber mais sobre esse recurso.
Dialeto SQL
O Looker oferece suporte a 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ções diferentes, chamados de dialeto SQL.
O LookML foi projetado para funcionar com todos os dialetos do SQL, sem preferir um dialeto em relação a outro. No entanto, é necessário 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 ao seu banco de dados. Portanto, use o dialeto SQL correspondente. Por exemplo, se você usar uma função SQL, ela precisa ser compatível com seu banco de dados.
Blocos SQL
Alguns parâmetros do LookML exigem que você forneça expressões SQL brutas para que o Looker possa entender como recuperar dados do seu banco de dados.
Os parâmetros do LookML que começam com sql_ esperam uma expressão SQL de alguma forma. Por exemplo: sql_always_where, sql_on e sql_table_name. O parâmetro mais comum do LookML para blocos de SQL é sql, usado em definições de campo 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 SQL pode ser tão simples quanto um nome de campo ou tão complexo quanto um subselecionado correlacionado. O conteúdo pode ser bastante complexo, atendendo a quase todas as necessidades de expressar a lógica de consulta personalizada em SQL bruto. 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 métricas
Confira a seguir exemplos de blocos SQL para dimensões e métricas. O operador de substituição do LookML ($) pode fazer com que essas declarações sql pareçam muito diferentes do SQL. No entanto, depois que a substituição ocorre, 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}) ;;
}
Conforme mostrado nas duas últimas dimensões, 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 SQL com uma subseleção correlacionada
É possível 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 SQL para tabelas derivadas
As tabelas derivadas usam o bloco SQL para especificar a consulta que gera 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 fazer referência a um campo da LookML em outro, é possível instruir o Looker a tratar o campo referenciado como um tipo de dados específico usando dois-pontos (::) seguido 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 convertido em uma string.
O tipo de dados que você pode usar em uma referência depende do tipo de dados do campo original que você está referenciando. Por exemplo, se você estiver fazendo referência a um campo de string, o único tipo de dados que pode ser especificado é ::string. Confira a lista completa de referências de tipo de campo permitidas que podem ser usadas para cada tipo de campo:
- 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
::stringe::number. - Em uma referência a um campo de data ou hora, você pode usar
::string,::datee::datetime.As referências que usam::stringe::dateretornam dados no fuso horário da consulta, enquanto as referências que usam::datetimeretornam dados no fuso horário do banco de dados. - Em uma referência a um campo sim/não, você pode usar
::string,::numbere::boolean. As referências de campo que usam o tipo::booleannão estão disponíveis para dialetos de banco de dados que não oferecem suporte ao tipo de dados booleano. - Em uma referência a um campo de local, é possível usar
::latitudee::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 em grupos de dimensão de type: time. Neste exemplo, a dimensão enrollment_month é produzida pelo seguinte grupo de dimensão 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, você pode calcular quantos meses ou anos se passaram entre a matrícula e a formatura de um estudante criando um grupo de dimensões de type: duration. No entanto, como alguns campos de data são convertidos em strings no SQL gerado pelo Looker, definir as dimensões enrollment_month e graduation_month como os valores de sql_start e sql_end pode resultar em um erro.
Para evitar um erro resultante da conversão desses campos de tempo em strings, uma opção é criar um grupo de dimensão de type: duration, referenciando os períodos de 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 "Explorar", isso gera um grupo de dimensão chamado Duração da inscrição, com dimensões individuais Mêses de inscrição e Anos de inscrição.
Uma alternativa mais simples ao uso do período 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ão Duração de inscrição, mas o uso da referência ::date permite que as dimensões enrollment_month e graduation_month sejam usadas sem usar um período raw ou convertê-las em strings com SQL.
Para conferir outro exemplo de como as referências de 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 as medidas de
type: list, que não podem ser referenciadas a partir do Looker 6.8.
Constantes do LookML
O parâmetro constant permite especificar uma constante que pode ser usada em todo um projeto do LookML. Com as constantes do LookML, você pode definir um valor uma vez e fazer referência a ele em qualquer parte do projeto em que as strings sejam aceitas, reduzindo a repetição no código do LookML.
As constantes precisam ser declaradas em um arquivo de manifesto do projeto, e o valor de uma constante precisa ser uma string. Por exemplo, é possível definir uma constante city com o valor "Okayama" da seguinte maneira:
constant: city {
value: "Okayama"
}
A constante city pode ser referenciada em todo o projeto usando a sintaxe @{city}. Por exemplo, é possível usar a constante city com o parâmetro label na Análise detalhada users:
explore: users {
label: "@{city} Users"
}
O Looker mostra Usuários de Okayama no menu Explorar e no título da seção, em vez de Usuários.
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.