Este é um tópico avançado que pressupõe um bom conhecimento pré-existente de SQL e LookML.
O Looker oferece automaticamente aos usuários a capacidade de manipular as consultas ao criar filtros, que são baseados em dimensões e medidas. Embora esse método simples atenda a muitos casos de uso, ele não pode habilitar todas as necessidades analíticas. Os filtros de modelo e os parâmetros Liquid expandem consideravelmente os possíveis casos de uso aos quais você oferece suporte.
Do ponto de vista do SQL, as dimensões e medidas só podem alterar as cláusulas WHERE
ou HAVING
mais externas na sua consulta. No entanto, talvez você queira permitir que os usuários manipulem outras partes do SQL. Ajustar parte de uma tabela derivada, ajustar qual tabela do banco de dados é consultada ou criar dimensões e filtros multifuncionais são apenas alguns dos recursos que você pode ativar com filtros baseados em modelo e parâmetros líquidos.
Filtros com modelo e parâmetros Liquid usam a linguagem de modelos Liquid para inserir entradas do usuário em consultas SQL. Primeiro, você vai usar um parâmetro do LookML para criar um campo com o qual os usuários possam interagir. Em seguida, use uma variável Liquid para injetar a entrada do usuário em consultas SQL.
Examples
Vejamos alguns exemplos para demonstrar o valor dos filtros com modelo e dos parâmetros Liquid.
Como criar uma tabela derivada dinâmica com um filtro de modelo
Considere uma tabela derivada que calcula o gasto de vida útil de um cliente na região nordeste:
view: customer_facts {
derived_table: {
sql:
SELECT
customer_id, -- Can be made a dimension
SUM(sale_price) AS lifetime_spend -- Can be made a dimension
FROM
order
WHERE
region = 'northeast' -- Can NOT be made a dimension
GROUP BY 1
;;
}
}
Nesta consulta, você pode criar dimensões com base em customer_id
e lifetime_spend
. No entanto, suponha que você queira que o usuário possa especificar o region
, em vez de codificá-lo para "northeast". O region
não pode ser exposto como uma dimensão e, portanto, o usuário não pode filtrá-lo normalmente.
Uma opção seria usar um filtro com modelo, que ficaria assim:
view: customer_facts {
derived_table: {
sql:
SELECT
customer_id,
SUM(sale_price) AS lifetime_spend
FROM
order
WHERE
{% condition order_region %} order.region {% endcondition %}
GROUP BY 1
;;
}
filter: order_region {
type: string
}
}
Leia mais abaixo para ver instruções detalhadas.
Se uma tabela derivada usar um filtro com modelo, não será possível tornar a tabela persistente.
Como fazer uma medida dinâmica com um parâmetro Liquid
Considere uma medida filtrada que some o número de calças vendidas:
measure: pants_count {
filters: [category: "pants"]
}
Isso é simples, mas se houvesse dezenas de categorias, seria tedioso criar uma medida para cada. Além disso, isso pode sobrecarregar a experiência "Explorar" para os usuários.
Uma alternativa seria criar uma medida dinâmica como esta:
measure: category_count {
type: sum
sql:
CASE
WHEN ${category} = '{% parameter category_to_count %}'
THEN 1
ELSE 0
END
;;
}
parameter: category_to_count {
type: string
}
Leia mais abaixo para ver instruções detalhadas.
Uso básico
Etapa 1: criar algo com que o usuário possa interagir
- Para filtros com modelo, adicione um
filter
. - No caso de parâmetros Liquid, adicione um
parameter
.
Em ambos os casos, esses campos aparecem para o usuário na seção Campos somente para filtros do seletor de campo.
Os campos filter
e parameter
podem aceitar uma série de parâmetros filhos, permitindo que você personalize a operação deles. Consulte a página de documentação Parâmetros de campo para ver uma lista completa. Há duas opções com menções especiais para campos parameter
.
Primeiro, os campos parameter
podem ter um tipo especial chamado sem aspas:
parameter: table_name {
type: unquoted
}
Esse tipo permite que os valores sejam inseridos no SQL sem serem colocados entre aspas, como uma string. Isso pode ser útil quando você precisa inserir valores SQL, como nomes de tabelas.
Em segundo lugar, os campos parameter
têm uma opção chamada valores permitidos que permite associar um nome fácil de usar ao valor que você quer inserir. Exemplo:
parameter: sale_price_metric_picker {
description: "Use with the Sale Price Metric measure"
type: unquoted
allowed_value: {
label: "Total Sale Price"
value: "SUM"
}
allowed_value: {
label: "Average Sale Price"
value: "AVG"
}
allowed_value: {
label: "Maximum Sale Price"
value: "MAX"
}
allowed_value: {
label: "Minimum Sale Price"
value: "MIN"
}
}
Etapa 2: aplicar a entrada do usuário
A segunda etapa é usar Liquid para adicionar o filtro de modelo ou o parâmetro "Liquid", conforme desejado.
Filtros com modelo
A sintaxe dos filtros com modelo é dividida da seguinte maneira:
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}
- As palavras
condition
eendcondition
nunca mudam. - Substitua
filter_name
pelo nome do filtro criado na primeira etapa. Você também pode usar uma dimensão se não tiver criado um campo somente filtro. - Substitua
sql_or_lookml_reference
pelo SQL ou LookML que precisa ser definido como "igual" à entrada do usuário. Leia mais detalhes abaixo. Se estiver usando o LookML, use a sintaxe${view_name.field_name}
do LookML.
No exemplo anterior, Como fazer uma tabela derivada dinâmica com um filtro de modelo, usamos:
{% condition order_region %} order.region {% endcondition %}
É importante entender a interação entre as tags Liquid e o SQL que você escreve entre elas. As tags de filtro com modelo são sempre transformadas em uma expressão lógica. Por exemplo, se o usuário digitasse "Nordeste" no filtro order_region
, o Looker transformaria essas tags em: order.region = 'Northeast'
. Em outras palavras, o Looker entende a entrada do usuário e gera a expressão lógica adequada.
Isso costuma causar confusão entre os desenvolvedores do Looker. Os filtros com modelo sempre resultam em uma expressão lógica de algum tipo, e não no valor individual inserido por um usuário.
Como os filtros com modelo retornam uma expressão lógica, eles podem ser usados com outros operadores lógicos e expressões lógicas válidas na instrução SQL WHERE
. Usando o exemplo anterior, se você quiser retornar todos os valores, exceto a região que o usuário selecionou, use o seguinte na instrução WHERE
:
NOT ({% condition order_region %} order.region {% endcondition %})
Também é válido usar um campo do LookML como condição de filtro. Todos os filtros aplicados diretamente ao campo do LookML vão determinar o valor da instrução WHERE
:
view: customer_facts {
derived_table: {
sql:
SELECT
customer_id,
SUM(sale_price) AS lifetime_spend
FROM
order
WHERE
{% condition region %} order.region {% endcondition %}
GROUP BY 1
;;
}
dimension: region {
type: string
sql: ${TABLE}.region ;;
}
Parâmetros líquidos
A sintaxe dos parâmetros Liquid é dividida da seguinte forma:
{% parameter parameter_name %}
- A palavra
parameter
nunca muda. - Substitua
parameter_name
pelo nomeparameter
que você criou na primeira etapa.
Por exemplo, para aplicar a entrada do campo parameter
na etapa 1, crie uma medida como esta:
measure: sale_price_metric {
description: "Use with the Sale Price Metric Picker filter-only field"
type: number
label_from_parameter: sale_price_metric_picker
sql: {% parameter sale_price_metric_picker %}(${sale_price}) ;;
value_format_name: usd
}
Como escolher entre filtros com modelo e parâmetros líquidos
Embora os filtros modelo e os parâmetros líquidos sejam semelhantes, há uma diferença importante entre eles:
- Os parâmetros líquidos inserem diretamente a entrada do usuário ou usando os valores definidos com valores permitidos.
- Os filtros com modelo inserem valores como instruções lógicas, conforme descrito na seção "Filtros com modelo".
Quando você quiser oferecer entradas mais flexíveis aos usuários (como em vários tipos de períodos ou pesquisas de strings), tente usar filtros com modelos sempre que possível. O Looker pode interpretar a entrada do usuário e escrever o SQL apropriado em segundo plano. Isso evita que você precise considerar todos os tipos possíveis de entrada do usuário.
Use parâmetros Liquid em situações em que uma instrução lógica não pode ser inserida ou em que você conhece um conjunto finito de opções que o usuário pode inserir.