Filtros baseados em modelos e parâmetros Liquid

Este é um tópico avançado destinado a utilizadores com um bom conhecimento pré-existente de SQL e LookML.

O Looker oferece automaticamente aos utilizadores a capacidade de manipular as respetivas consultas criando filtros, que se baseiam em dimensões e medidas. Embora este método satisfaça muitos exemplos de utilização, não consegue satisfazer todas as necessidades de análise. Os filtros baseados em modelos e os parâmetros Liquid expandem significativamente os exemplos de utilização possíveis que pode suportar.

Do ponto de vista do SQL, as dimensões e as medidas só podem alterar as cláusulas WHERE ou HAVING mais externas na sua consulta. No entanto, pode querer permitir que os utilizadores manipulem outras partes do SQL. Ajustar parte de uma tabela derivada, ajustar a tabela de base de dados que é consultada ou criar dimensões e filtros multifunções são apenas algumas das funcionalidades que pode ativar com filtros baseados em modelos e parâmetros Liquid.

Os filtros baseados em modelos e os parâmetros Liquid usam a linguagem de modelos Liquid para inserir a entrada do utilizador em consultas SQL. Primeiro, usa um parâmetro do LookML para criar um campo com o qual os utilizadores podem interagir. Em seguida, usa uma variável Liquid para inserir a entrada do utilizador em consultas SQL.

Exemplos

Vejamos alguns exemplos para demonstrar o valor dos filtros baseados em modelos e dos parâmetros Liquid.

Criar uma tabela derivada dinâmica com um filtro baseado em modelos

Considere uma tabela derivada que calcule os gastos vitalícios 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, pode criar dimensões a partir de customer_id e lifetime_spend. No entanto, suponhamos que quer que o utilizador possa especificar o region, em vez de o codificar como "northeast". O region não pode ser exposto como uma dimensão e, por isso, o utilizador não pode filtrá-lo normalmente.

Uma opção seria usar um filtro baseado em modelos, que teria o seguinte aspeto:

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 na secção Utilização básica para ver instruções passo a passo.

Criar 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"]
}

Isto é simples, mas se houvesse dezenas de categorias, seria fastidioso criar uma medida para cada uma. Além disso, pode desorganizar a experiência Explorar para os utilizadores.

Em alternativa, pode criar uma medida dinâmica da seguinte forma:

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 na secção Utilização básica para ver instruções passo a passo.

Utilização básica

Passo 1: crie algo com que o utilizador possa interagir

  • Para filtros baseados em modelos, adicione um filter.
  • Para parâmetros Liquid, adicione um parameter.

Em ambos os casos, estes campos são apresentados ao utilizador na secção Campos apenas de filtro do selecionador de campos.

Ambos os campos filter e parameter podem aceitar uma série de parâmetros secundários, o que lhe permite personalizar o respetivo funcionamento. Consulte a página de documentação Parâmetros de campo para ver uma lista completa. Existem duas opções que merecem uma menção especial para os campos parameter.

Primeiro, os campos parameter podem ter um tipo especial denominado unquoted:

parameter: table_name {
  type: unquoted
}

Este tipo permite que os valores sejam inseridos no SQL sem serem incluídos entre aspas, como seria o caso de uma string. Isto pode ser útil quando precisa de inserir valores SQL, como nomes de tabelas.

Em segundo lugar, os campos parameter têm uma opção denominada valores permitidos que lhe permite associar um nome simples ao valor que quer inserir. Por 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"
    }
  }

Passo dois: aplique a entrada do utilizador

O segundo passo é usar o Liquid para adicionar o filtro baseado em modelos ou o parâmetro Liquid conforme pretendido.

Filtros baseados em modelos

A sintaxe dos filtros baseados em modelos divide-se da seguinte forma:

{% condition filter_name %} sql_or_lookml_reference {% endcondition %}
  • As palavras condition e endcondition nunca mudam.
  • Substitua filter_name pelo nome do filtro que criou no primeiro passo. Também pode usar uma dimensão se não tiver criado um campo apenas de filtragem.
  • Substitua sql_or_lookml_reference pelo SQL ou LookML que deve ser definido como "igual" à entrada do utilizador (isto é explicado mais detalhadamente mais adiante nesta secção). Se usar o LookML, use a ${view_name.field_name} sintaxe do LookML.

No exemplo anterior, Criar uma tabela derivada dinâmica com um filtro baseado em modelos, usámos:

{% condition order_region %} order.region {% endcondition %}

É importante compreender a interação entre as etiquetas Liquid e o SQL que escreve entre as etiquetas. Estas etiquetas de filtro baseadas em modelos são sempre transformadas numa expressão lógica. Por exemplo, se o utilizador introduzisse "Nordeste" no filtro order_region, o Looker transformaria estas etiquetas no seguinte:

order.region = 'Northeast'

Por outras palavras, o Looker interpreta a entrada do utilizador e gera a expressão lógica adequada.

Uma vez que os filtros baseados em modelos devolvem uma expressão lógica, pode usá-los com outros operadores lógicos e expressões lógicas válidas na declaração SQL WHERE. Com base no exemplo anterior, se quiser devolver todos os valores exceto a região que o utilizador selecionou, pode usar o seguinte na declaração WHERE:

NOT ({% condition order_region %} order.region {% endcondition %})

Também é válido usar um campo LookML como condição do filtro. Quaisquer filtros aplicados diretamente ao campo LookML determinam o valor da declaraçã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 Liquid

A sintaxe dos parâmetros Liquid divide-se da seguinte forma:

{% parameter parameter_name %}
  • A palavra parameter nunca muda.
  • Substitua parameter_name pelo nome parameter que criou no primeiro passo.

Por exemplo, para aplicar a entrada do campo parameter no passo um, pode criar 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
  }

Escolher entre filtros baseados em modelos e parâmetros Liquid

Embora os filtros baseados em modelos e os parâmetros Liquid sejam semelhantes, existe uma diferença importante entre eles:

Em situações em que quer oferecer aos utilizadores uma entrada mais flexível (como vários tipos de intervalos de datas ou pesquisas de strings), tente usar filtros baseados em modelos sempre que possível. O Looker pode interpretar a entrada do utilizador e escrever o SQL adequado nos bastidores. Isto evita que tenha de ter em conta todos os tipos possíveis de introdução do utilizador.

Em situações em que não é possível inserir uma declaração lógica ou em que conhece um conjunto finito de opções que o utilizador pode introduzir, use parâmetros Liquid.