Filtros de plantilla y parámetros líquidos

Este es un tema avanzado en el que se supone que ya posee un buen conocimiento sobre SQL y LookML.

Looker proporciona automáticamente a los usuarios la capacidad de manipular sus consultas mediante la creación de filtros, que se basan en dimensiones y medidas. Si bien este método simple satisface muchos casos de uso, no puede satisfacer todas las necesidades analíticas. Los filtros de plantilla y los parámetros líquidos amplían ampliamente los posibles casos de uso que puede admitir.

Desde la perspectiva de SQL, las dimensiones y las medidas solo pueden alterar las cláusulas WHERE o HAVING más externas en la consulta. Sin embargo, es posible que quieras permitir que los usuarios manipulen otras partes del SQL. Ajustar parte de una tabla derivada, ajustar qué tabla de base de datos se consulta o crear dimensiones y filtros multipropósito son solo algunas de las funciones que puede habilitar con los filtros basados en plantillas y los parámetros líquidos.

Los filtros de plantilla y los parámetros líquidos usan el lenguaje de plantillas Liquid para insertar entradas del usuario en consultas de SQL. Primero, usa un parámetro de LookML para crear un campo con el que los usuarios puedan interactuar. A continuación, usa una variable líquida para insertar la entrada del usuario en consultas de SQL.

Ejemplos

Veamos algunos ejemplos para demostrar el valor de los filtros de plantilla y de los parámetros líquidos.

Crea una tabla derivada dinámica con un filtro con plantilla

Considera una tabla derivada que calcula la inversión del ciclo de vida de un cliente dentro de la región noreste:

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
    ;;
  }
}

En esta consulta, puedes crear dimensiones a partir de customer_id y lifetime_spend. Sin embargo, supongamos que deseas que el usuario especifique el region, en lugar de codificarlo en "northeast". region no se puede exponer como dimensión y, por lo tanto, el usuario no puede filtrarlo como de costumbre.

Una opción sería usar un filtro con plantilla, que se vería así:

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
  }
}

Consulte más información a continuación para obtener instrucciones paso a paso.

Si una tabla derivada usa un filtro con plantilla, no puedes hacer que la tabla sea persistente.

Cómo hacer una medición dinámica con un parámetro líquido

Considere una medida filtrada que suma la cantidad de pantalones vendidos:

measure: pants_count {
  filters: [category: "pants"]
}

Esto es sencillo, pero si hubiera decenas de categorías, sería tedioso crear una medida para cada una. Además, puede afectar la experiencia de Explorar para los usuarios.

Una alternativa sería crear una medida dinámica como la siguiente:

measure: category_count {
  type: sum
  sql:
    CASE
      WHEN ${category} = '{% parameter category_to_count %}'
      THEN 1
      ELSE 0
    END
  ;;
}

parameter: category_to_count {
  type: string
}

Consulte más información a continuación para obtener instrucciones paso a paso.

Uso básico

Paso uno: Crea algo para que el usuario interactúe

• Para los filtros con plantilla, agrega un filter.
• Para los parámetros líquidos, agrega un parameter.

En cualquier caso, el usuario podrá ver los siguientes campos en la sección Campos de solo filtro del selector de campos:

Los campos filter y parameter pueden aceptar una serie de parámetros secundarios, lo que te permite personalizar su funcionamiento. Consulta la página de documentación de los parámetros de campo para obtener una lista completa. Hay dos opciones que incluyen menciones especiales en los campos parameter.

Primero, los campos parameter pueden tener un tipo especial llamado sin comillas:

parameter: table_name {
  type: unquoted
}

Este tipo de datos permite insertar valores en SQL sin comillas, como si fuera una string. Esto puede ser útil cuando necesitas insertar valores de SQL, como los nombres de tablas.

En segundo lugar, los campos parameter tienen una opción llamada valores permitidos que le permite asociar un nombre fácil de usar con el valor que desea insertar. Por ejemplo:

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

Paso dos: Aplica la entrada del usuario

El segundo paso es usar Liquid para agregar el filtro con plantilla o el parámetro Liquid como desee.

Filtros basados en plantillas

La sintaxis de los filtros con plantilla se desglosa de la siguiente manera:

{% condition filter_name %} sql_or_lookml_reference {% endcondition %}

• Las palabras condition y endcondition nunca cambian.
• Reemplaza filter_name por el nombre del filtro que creaste en el primer paso. También puede usar una dimensión si no creó un campo de solo filtro.
• Reemplaza sql_or_lookml_reference por SQL o LookML que se debe establecer"igual"a la entrada del usuario (obtén más detalles a continuación). Si usas LookML, usa la sintaxis ${view_name.field_name} de LookML.

En el ejemplo anterior usamos:

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

Es importante comprender la interacción entre las etiquetas líquidas y el SQL que escribe entre ellas. Las etiquetas de filtro con plantilla siempre se transforman en una expresión lógica. Por ejemplo, si el usuario ingresó “Noreste” en el filtro order_region, Looker convertirá las etiquetas en order.region = 'Northeast'. En otras palabras, Looker comprende la entrada del usuario y genera la expresión lógica adecuada.

A menudo, esto es un punto de confusión entre los desarrolladores de Looker. Los filtros de plantilla siempre dan como resultado una expresión lógica de algún tipo, y no del valor individual ingresado por un usuario.

Debido a que los filtros con plantilla muestran una expresión lógica, puedes usarlos con otros operadores lógicos y expresiones lógicas que sean válidas en la instrucción WHERE de SQL. En el ejemplo anterior, si deseas mostrar todos los valores excepto la región que seleccionó el usuario, puedes usar lo siguiente en la sentencia WHERE:

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

También es válido usar un campo LookML como condición del filtro. Cualquier filtro que se aplique directamente al campo LookML determinará el valor de la declaración 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

La sintaxis de los parámetros Liquid se desglosa de la siguiente manera:

{% parameter parameter_name %}

• La palabra parameter nunca cambia.
• Reemplaza parameter_name por el nombre parameter que creaste en el primer paso.

Por ejemplo, para aplicar la entrada del campo parameter en el primer paso, puedes crear una medida como la siguiente:

  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
  }

Elegir entre filtros de plantillas y parámetros líquidos

Aunque los filtros de plantilla y los parámetros líquidos son similares, hay una diferencia importante entre ellos:

• Los parámetros líquidos insertan las entradas del usuario directamente (o usan los valores que usted define con los valores permitidos).
• Los filtros con plantilla insertan valores como declaraciones lógicas, como se describió anteriormente.

Cuando quieras ofrecer a los usuarios una entrada más flexible (por ejemplo, con varios tipos de períodos o búsquedas de strings), intenta usar filtros de plantilla cuando sea posible. Looker puede interpretar las entradas del usuario y escribir el SQL apropiado en segundo plano. Esto evita que tenga que considerar cada tipo posible de entrada del usuario.

En situaciones en las que no se pueda insertar una instrucción lógica o en las que conozca un conjunto finito de opciones que podría ingresar el usuario, utilice parámetros líquidos.