Este es un tema avanzado dirigido a usuarios que tienen un buen conocimiento previo de SQL y LookML.
Looker les brinda a los usuarios la capacidad de manipular sus consultas automáticamente mediante la creación de filtros, que se basan en dimensiones y medidas. Si bien este método cumple con muchos casos de uso, no puede habilitar todas las necesidades analíticas. Los filtros con plantillas y los parámetros de Liquid expanden enormemente los posibles casos de uso que puedes admitir.
Desde una perspectiva de SQL, las dimensiones y las medidas solo pueden alterar las cláusulas WHERE
o HAVING
más externas de tu consulta. Sin embargo, es posible que desees permitir que los usuarios manipulen otras partes de la SQL. Ajustar parte de una tabla derivada, ajustar la tabla de base de datos a la que se consulta o crear dimensiones y filtros multipropósito son solo algunas de las funciones que puedes habilitar con los filtros de plantillas y los parámetros de Liquid.
Los filtros con plantillas y los parámetros de Liquid usan el lenguaje de plantillas de Liquid para insertar entradas del usuario en las consultas de SQL. Primero, debes usar un parámetro de LookML para crear un campo con el que los usuarios puedan interactuar. A continuación, usas una variable Liquid para insertar la entrada del usuario en las consultas de SQL.
Ejemplos
Veamos algunos ejemplos para demostrar el valor de los filtros de plantillas y los parámetros de Liquid.
Cómo crear una tabla derivada dinámica con un filtro de plantilla
Considera una tabla derivada que calcula la inversión total de un cliente en 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 quieres que el usuario pueda especificar el region
, en lugar de codificarlo de forma fija como "nordeste". region
no se puede exponer como una dimensión y, por lo tanto, el usuario no puede filtrar por ella como de costumbre.
Una opción sería usar un filtro de plantilla, que se vería de la siguiente manera:
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
}
}
Obtén más información en la sección de uso básico para obtener instrucciones paso a paso.
Cómo crear una medición dinámica con un parámetro de Liquid
Considera una métrica 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 desordenar la experiencia de Explorar para los usuarios.
Una alternativa sería crear una medición 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
}
Obtén más información en la sección de uso básico para obtener instrucciones paso a paso.
Uso básico
Paso uno: Crea algo con lo que el usuario pueda interactuar
- Para los filtros con plantillas, agrega un
filter
. - Para los parámetros de Liquid, agrega un
parameter
.
En cualquier caso, estos campos aparecerán para el usuario en la sección Campos solo de filtro del selector de campos.
Tanto los campos filter
como parameter
pueden aceptar una serie de parámetros secundarios, lo que te permite personalizar su funcionamiento. Consulta la página de documentación Parámetros de campo para obtener una lista completa. Hay dos opciones que se mencionan de forma especial para los campos parameter
.
En primer lugar, los campos parameter
pueden tener un tipo especial llamado sin comillas:
parameter: table_name {
type: unquoted
}
Este tipo permite que los valores se inserten en SQL sin encerrarse entre comillas, como lo haría una cadena. Esto puede ser útil cuando necesitas insertar valores de SQL, como nombres de tablas.
En segundo lugar, los campos parameter
tienen una opción llamada valores permitidos que te permite asociar un nombre fácil de usar con el valor que deseas 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 de plantilla o el parámetro Liquid según sea necesario.
Filtros con plantillas
La sintaxis de los filtros con plantillas se desglosa de la siguiente manera:
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}
- Las palabras
condition
yendcondition
nunca cambian. - Reemplaza
filter_name
por el nombre del filtro que creaste en el primer paso. También puedes usar una dimensión si no creaste un campo solo de filtro. - Reemplaza
sql_or_lookml_reference
por la SQL o LookML que debe establecerse como "igual" a la entrada del usuario (esto se explica con más detalle más adelante en esta sección). Si usas LookML, usa la sintaxis de LookML de${view_name.field_name}
.
En el ejemplo anterior, Cómo crear una tabla derivada dinámica con un filtro de plantilla, usamos lo siguiente:
{% condition order_region %} order.region {% endcondition %}
Es importante comprender la interacción entre las etiquetas Liquid y el SQL que escribes entre ellas. Estas etiquetas de filtro con plantillas siempre se transforman en una expresión lógica. Por ejemplo, si el usuario ingresó "Noreste" en el filtro order_region
, Looker convertiría estas etiquetas en lo siguiente:
order.region = 'Northeast'
En otras palabras, Looker interpreta la entrada del usuario y genera la expresión lógica adecuada.
Debido a que los filtros con plantillas muestran una expresión lógica, puedes usarlos con otros operadores lógicos y expresiones lógicas que sean válidas en la sentencia WHERE
de SQL. En el ejemplo anterior, si quisieras mostrar todos los valores excepto la región que seleccionó el usuario, podrías usar lo siguiente en la sentencia WHERE
:
NOT ({% condition order_region %} order.region {% endcondition %})
También es válido usar un campo de LookML como condición del filtro. Cualquier filtro que se aplique directamente al campo de LookML determinará el valor de la sentencia 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 de Liquid
La sintaxis de los parámetros de Liquid se desglosa de la siguiente manera:
{% parameter parameter_name %}
- La palabra
parameter
nunca cambia. - Reemplaza
parameter_name
por el nombreparameter
que creaste en el primer paso.
Por ejemplo, para aplicar la entrada del campo parameter
en el paso uno, puedes crear una 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
}
Elige entre filtros con plantillas y parámetros de Liquid
Aunque los filtros con plantillas y los parámetros de Liquid son similares, existe una diferencia importante entre ellos:
- Los parámetros líquidos insertan la entrada del usuario directamente (o usan los valores que defines con los valores permitidos).
- Los filtros con plantillas insertan valores como sentencias lógicas, como se describe en la sección Filtros con plantillas.
En situaciones en las que quieras ofrecer a los usuarios una entrada más flexible (como con varios tipos de períodos o búsquedas de cadenas), intenta usar filtros de plantillas siempre que sea posible. Looker puede interpretar la entrada del usuario y escribir el código SQL adecuado en segundo plano. Esto evita que tengas que tener en cuenta todos los tipos posibles de entradas del usuario.
En situaciones en las que no se puede insertar una sentencia lógica o en las que conoces un conjunto finito de opciones que el usuario podría ingresar, usa los parámetros de Liquid.