En esta página, se hace referencia al parámetro
typeque forma parte de una métrica.
typetambién se puede usar como parte de una dimensión o un filtro, como se describe en la página de documentación Tipos de dimensiones, filtros y parámetros.
typetambién se puede usar como parte de un grupo de dimensiones, como se describe en la página de documentación del parámetrodimension_group.
Uso
view: view_name {
measure: field_name {
type: measure_field_type
}
}
|
Jerarquía
type |
Tipos de campos posibles
Medir
Acepta
Un tipo de medida
|
En esta página, se incluyen detalles sobre los distintos tipos que se pueden asignar a una métrica. Una medida solo puede tener un tipo, y el valor predeterminado es string si no se especifica un tipo.
Algunos tipos de medidas tienen parámetros de asistencia, que se describen en la sección correspondiente.
Categorías de tipos de medición
Cada tipo de medida pertenece a una de las siguientes categorías. Estas categorías determinan si el tipo de medida realiza agregaciones, el tipo de campos a los que puede hacer referencia el tipo de medida y si puedes filtrar el tipo de medida con el parámetro filters:
- Medidas agregadas: Los tipos de medidas agregadas realizan agregaciones, como
sumyaverage. Las medidas agregadas solo pueden hacer referencia a dimensiones, no a otras medidas. Este es el único tipo de medida que funciona con el parámetrofilters. - Medidas no agregadas: Como su nombre lo indica, las medidas no agregadas son tipos de medidas que no realizan agregaciones, como
numberyyesno. Estos tipos de medidas realizan transformaciones básicas y, como no realizan agregaciones, solo pueden hacer referencia a medidas agregadas o dimensiones agregadas previamente. No puedes usar el parámetrofilterscon estos tipos de medidas. - Medidas posteriores al SQL: Las medidas posteriores al SQL son tipos de medidas especiales que realizan cálculos específicos después de que Looker genera el SQL de la consulta. Solo pueden hacer referencia a medidas o dimensiones numéricas. No puedes usar el parámetro
filterscon estos tipos de medidas.
Lista de definiciones de tipos
| Tipo | Categoría | Descripción |
|---|---|---|
average |
Agregación | Genera un promedio (media) de los valores dentro de una columna. |
average_distinct |
Agregación | Genera correctamente un promedio (media) de los valores cuando se usan datos desnormalizados. Consulta la sección average_distinct para obtener una descripción completa. |
count |
Agregación | Genera un recuento de filas |
count_distinct |
Agregación | Genera un recuento de los valores únicos dentro de una columna |
date |
Sin agregar | Para las medidas que contienen fechas |
list |
Agregación | Genera una lista de los valores únicos dentro de una columna. |
max |
Agregación | Genera el valor máximo dentro de una columna. |
median |
Agregación | Genera la mediana (valor del punto medio) de los valores dentro de una columna. |
median_distinct |
Agregación | Genera correctamente una mediana (valor del punto medio) de los valores cuando una unión causa una expansión. Consulta la sección median_distinct para obtener una descripción completa. |
min |
Agregación | Genera el valor mínimo dentro de una columna. |
number |
Sin agregar | Para las medidas que contienen números |
percent_of_previous |
Post-SQL | Genera la diferencia porcentual entre las filas mostradas |
percent_of_total |
Post-SQL | Genera el porcentaje del total para cada fila mostrada. |
percentile |
Agregación | Genera el valor en el percentil especificado dentro de una columna. |
percentile_distinct |
Agregación | Genera correctamente el valor en el percentil especificado cuando una unión causa una expansión. Consulta la sección percentile_distinct para obtener una descripción completa. |
running_total |
Post-SQL | Genera el total acumulado para cada fila que se muestra. |
period_over_period |
Agregación | Hace referencia a una agregación de un período anterior |
string |
Sin agregar | Para las medidas que contienen letras o caracteres especiales (como la función GROUP_CONCAT de MySQL) |
sum |
Agregación | Genera la suma de los valores de una columna. |
sum_distinct |
Agregación | Genera correctamente una suma de valores cuando se usan datos desnormalizados.Consulta la sección sum_distinct para obtener una descripción completa. |
yesno |
Sin agregar | Para los campos que mostrarán si algo es verdadero o falso |
int |
Sin agregar |
Se quitó la versión 5.4
Se reemplazó por type: number |
average
type: average calcula el promedio de los valores en un campo determinado. Es similar a la función AVG de SQL. Sin embargo, a diferencia de lo que sucede con el SQL sin procesar, Looker calculará correctamente los promedios, incluso si las uniones de tu consulta contienen expansiones.
El parámetro sql para las medidas type: average puede tomar cualquier expresión de SQL válida que genere una columna de tabla numérica, una dimensión de LookML o una combinación de dimensiones de LookML.
Los campos type: average se pueden formatear con los parámetros value_format o value_format_name.
Por ejemplo, el siguiente LookML crea un campo llamado avg_order promediando la dimensión sales_price y, luego, lo muestra en formato de dinero (USD 1,234.56):
measure: avg_order {
type: average
sql: ${sales_price} ;;
value_format_name: usd
}
average_distinct
type: average_distinct se usa con conjuntos de datos desnormalizados. Calcula el promedio de los valores no repetidos en un campo determinado, según los valores únicos definidos por el parámetro sql_distinct_key.
Este es un concepto avanzado que se puede explicar con mayor claridad con un ejemplo. Considera una tabla desnormalizada como esta:
| ID de artículo del pedido | ID de pedido | Envío del pedido |
|---|---|---|
| 1 | 1 | 10.00 |
| 2 | 1 | 10.00 |
| 3 | 2 | 20.00 |
| 4 | 2 | 20.00 |
| 5 | 2 | 20.00 |
En esta situación, puedes ver que hay varias filas para cada pedido. Por lo tanto, si agregaste una medida básica de type: average para la columna order_shipping, obtendrías un valor de 16.00, aunque el promedio real es de 15.00.
# Will NOT calculate the correct average
measure: avg_shipping {
type: average
sql: ${order_shipping} ;;
}
Para obtener un resultado preciso, puedes definir en Looker cómo debe identificar cada entidad única (en este caso, cada pedido único) con el parámetro sql_distinct_key. Esto calculará el importe correcto de 15.00:
# Will calculate the correct average
measure: avg_shipping {
type: average_distinct
sql_distinct_key: ${order_id} ;;
sql: ${order_shipping} ;;
}
Cada valor único de sql_distinct_key debe tener un solo valor correspondiente en sql. En otras palabras, el ejemplo anterior funciona porque cada fila con un order_id de 1 tiene el mismo order_shipping de 10.00, y cada fila con un order_id de 2 tiene el mismo order_shipping de 20.00.
Los campos type: average_distinct se pueden formatear con los parámetros value_format o value_format_name.
count
type: count realiza un recuento de tablas, de manera similar a la función COUNT de SQL. Sin embargo, a diferencia de lo que sucede con el SQL sin procesar, Looker calculará correctamente los recuentos, incluso si las uniones de tu consulta contienen expansiones.
Las medidas de type: count realizan recuentos de tablas basados en la clave primaria de la tabla, por lo que las medidas de type: count no admiten el parámetro sql.
Si deseas realizar un recuento de tablas en un campo que no sea la clave primaria de la tabla, usa una medida type: count_distinct. O bien, si no quieres usar count_distinct, puedes usar una medida de type: number (consulta la publicación de Comunidad Cómo contar una clave no principal para obtener más información).
Por ejemplo, el siguiente código LookML crea un campo number_of_products:
view: products {
measure: number_of_products {
type: count
drill_fields: [product_details*] # optional
}
}
Es muy común proporcionar un parámetro drill_fields (para los campos) cuando se define una medida type: count, de modo que los usuarios puedan ver los registros individuales que componen un recuento cuando hacen clic en él.
Cuando usas una medida de
type: counten Explorar, la visualización etiqueta los valores resultantes con el nombre de la vista en lugar de la palabra "Recuento". Para evitar confusiones, te recomendamos que uses el plural del nombre de la vista, selecciones Mostrar nombre completo del campo en Serie en la configuración de la visualización o uses unview_labelcon una versión en plural del nombre de la vista.
Puedes agregar un filtro a una medida de type: count con el parámetro filters.
count_distinct
type: count_distinct calcula la cantidad de valores distintos en un campo determinado. Utiliza la función COUNT DISTINCT de SQL.
El parámetro sql para las medidas type: count_distinct puede tomar cualquier expresión de SQL válida que genere una columna de tabla, una dimensión de LookML o una combinación de dimensiones de LookML.
Por ejemplo, el siguiente LookML crea un campo number_of_unique_customers, que cuenta la cantidad de IDs de cliente únicos:
measure: number_of_unique_customers {
type: count_distinct
sql: ${customer_id} ;;
}
Puedes agregar un filtro a una medida de type: count_distinct con el parámetro filters.
date
type: date se usa con los campos que contienen fechas.
El parámetro sql para las medidas de type: date puede tomar cualquier expresión de SQL válida que genere una fecha. En la práctica, este tipo se usa muy poco, ya que la mayoría de las funciones de agregación de SQL no devuelven fechas. Una excepción común es un MIN o un MAX de una dimensión de fecha.
Cómo crear una medida de fecha máxima o mínima con type: date
Si deseas crear una medida de una fecha máxima o mínima, es posible que, en un principio, creas que funcionaría usar una medida de type: max o de type: min. Sin embargo, estos tipos de medidas solo son compatibles con los campos numéricos. En cambio, puedes capturar una fecha máxima o mínima definiendo una medida de type: date y ajustando el campo de fecha al que se hace referencia en el parámetro sql en una función MIN() o MAX().
Supongamos que tienes un grupo de dimensiones de type: time, llamado updated:
dimension_group: updated {
type: time
timeframes: [time, date, week, month, raw]
sql: ${TABLE}.updated_at ;;
}
Puedes crear una medida de type: date para capturar la fecha máxima de este grupo de dimensiones de la siguiente manera:
measure: last_updated_date {
type: date
sql: MAX(${updated_raw}) ;;
convert_tz: no
}
En este ejemplo, en lugar de usar una medida de type: max para crear la medida last_updated_date, se aplica la función MAX() en el parámetro sql. La medida last_updated_date también tiene el parámetro convert_tz establecido en no para evitar la doble conversión de zona horaria en la medida, ya que la conversión de zona horaria ya se produjo en la definición del grupo de dimensiones updated. Para obtener más información, consulta la documentación sobre el parámetro convert_tz.
En el ejemplo de LookML para la medida last_updated_date, se podría omitir type: date y el valor se trataría como una cadena, ya que string es el valor predeterminado para type. Sin embargo, obtendrás una mejor capacidad de filtrado para los usuarios si usas type: date.
También es posible que observes que la definición de la métrica last_updated_date hace referencia al período ${updated_raw} en lugar del período ${updated_date}. Dado que el valor que se muestra de ${updated_date} es una cadena, es necesario usar ${updated_raw} para hacer referencia al valor de fecha real.
También puedes usar el parámetro datatype con type: date para mejorar el rendimiento de las consultas especificando el tipo de datos de fecha que usa tu tabla de base de datos.
Cómo crear una medida de máximo o mínimo para una columna de fecha y hora
Calcular el máximo para una columna de type: datetime es un poco diferente. En este caso, deseas crear una medida sin declarar el tipo, de la siguiente manera:
measure: last_updated_datetime {
sql: MAX(${TABLE}.datetime_string_field) ;;
}
list
type: list crea una lista de los valores distintos en un campo determinado. Es similar a la función GROUP_CONCAT de MySQL.
No es necesario que incluyas un parámetro sql para las métricas de type: list. En su lugar, puedes usar el parámetro list_field para especificar la dimensión a partir de la cual deseas crear listas.
El uso es el siguiente:
view: view_name {
measure: field_name {
type: list
list_field: my_field_name
}
}
Por ejemplo, el siguiente LookML crea una medida name_list basada en la dimensión name:
measure: name_list {
type: list
list_field: name
}
Ten en cuenta lo siguiente para list:
- El tipo de métrica
listno admite el filtrado. No puedes usar el parámetrofiltersen una medidatype: list. - No se puede hacer referencia al tipo de medida
listcon el operador de sustitución ($). No puedes usar la sintaxis${}para hacer referencia a una medidatype: list.
Dialectos de bases de datos compatibles con list
Para que Looker admita type: list en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlo. En la siguiente tabla, se muestran los dialectos que admiten type: list en la versión más reciente de Looker:
| Dialecto | ¿Es compatible? |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13+ | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |
max
type: max encuentra el valor más grande en un campo determinado. Utiliza la función MAX de SQL.
El parámetro sql para las medidas de type: max puede tomar cualquier expresión de SQL válida que genere una columna de tabla numérica, una dimensión de LookML o una combinación de dimensiones de LookML.
Dado que las medidas de type: max solo son compatibles con los campos numéricos, no puedes usar una medida de type: max para encontrar una fecha máxima. En su lugar, puedes usar la función MAX() en el parámetro sql de una medida de type: date para capturar una fecha máxima, como se mostró anteriormente en los ejemplos de la sección date.
Los campos type: max se pueden formatear con los parámetros value_format o value_format_name.
Por ejemplo, el siguiente LookML crea un campo llamado largest_order observando la dimensión sales_price y, luego, lo muestra en formato de dinero (USD 1,234.56):
measure: largest_order {
type: max
sql: ${sales_price} ;;
value_format_name: usd
}
No puedes usar medidas de type: max para cadenas o fechas, pero puedes agregar manualmente la función MAX para crear un campo de este tipo, de la siguiente manera:
measure: latest_name_in_alphabet {
type: string
sql: MAX(${name}) ;;
}
median
type: median devuelve el valor del punto medio para los valores de un campo determinado. Esto es especialmente útil cuando los datos tienen algunos valores atípicos muy grandes o pequeños que sesgarían un promedio básico (media) de los datos.
Considera una tabla como la siguiente:
| ID de artículo del pedido | Costo | ¿Punto medio? |
|---|---|---|
| 2 | 10.00 | |
| 4 | 10.00 | |
| 3 | 20.00 | Valor del punto medio |
| 1 | 80.00 | |
| 5 | 90.00 |
La tabla está ordenada por costo, pero eso no afecta el resultado. Mientras que el tipo average devolvería 42 (sumando todos los valores y dividiendo por 5), el tipo median devolvería el valor del punto medio: 20.00.
Si hay una cantidad par de valores, el valor de la mediana se calcula tomando la media de los dos valores más cercanos al punto medio. Considera una tabla como esta con una cantidad par de filas:
| ID de artículo del pedido | Costo | ¿Punto medio? |
|---|---|---|
| 2 | 10 | |
| 3 | 20 | La más cercana antes del punto medio |
| 1 | 80 | Más cercano después del punto medio |
| 4 | 90 |
La mediana, el valor medio, es (20 + 80)/2 = 50.
La mediana también es igual al valor del percentil 50.
El parámetro sql para las medidas type: median puede tomar cualquier expresión de SQL válida que genere una columna de tabla numérica, una dimensión de LookML o una combinación de dimensiones de LookML.
Los campos type: median se pueden formatear con los parámetros value_format o value_format_name.
Ejemplo
Por ejemplo, el siguiente LookML crea un campo llamado median_order promediando la dimensión sales_price y, luego, lo muestra en formato de dinero (USD 1,234.56):
measure: median_order {
type: median
sql: ${sales_price} ;;
value_format_name: usd
}
Aspectos que debes tener en cuenta para median
Si usas median para un campo que participa en una distribución, Looker intentará usar median_distinct en su lugar. Sin embargo, medium_distinct solo es compatible con ciertos dialectos. Si median_distinct no está disponible para tu dialecto, Looker mostrará un error. Dado que median se puede considerar el percentil 50, el error indica que el dialecto no admite percentiles distintos.
Dialectos de bases de datos compatibles con median
Para que Looker admita el tipo median en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlo. En la siguiente tabla, se muestran los dialectos que admiten el tipo median en la versión más reciente de Looker:
| Dialecto | ¿Es compatible? |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13+ | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |
Cuando una consulta implica una expansión, Looker intenta convertir el median en median_distinct. Esto solo funciona en dialectos que admiten median_distinct.
median_distinct
Usa type: median_distinct cuando tu unión implique una distribución masiva. Calcula el promedio de los valores no repetidos en un campo determinado, según los valores únicos definidos por el parámetro sql_distinct_key. Si la medida no tiene un parámetro sql_distinct_key, Looker intenta usar el campo primary_key.
Considera el resultado de una consulta que une las tablas de elementos de pedido y pedidos:
| ID de artículo del pedido | ID de pedido | Envío del pedido |
|---|---|---|
| 1 | 1 | 10 |
| 2 | 1 | 10 |
| 3 | 2 | 20 |
| 4 | 3 | 50 |
| 5 | 3 | 50 |
| 6 | 3 | 50 |
En esta situación, puedes ver que hay varias filas para cada pedido. Esta consulta implicó una expansión porque cada pedido se asigna a varios elementos del pedido. La función median_distinct tiene en cuenta esto y encuentra la mediana entre los valores distintos 10, 20 y 50, por lo que obtendrías un valor de 20.
Para obtener un resultado preciso, puedes definir en Looker cómo debe identificar cada entidad única (en este caso, cada pedido único) con el parámetro sql_distinct_key. Esto calculará el importe correcto:
measure: median_shipping {
type: median_distinct
sql_distinct_key: ${order_id} ;;
sql: ${order_shipping} ;;
}
Cada valor único de sql_distinct_key debe tener solo un valor correspondiente en el parámetro sql de la métrica. En otras palabras, el ejemplo anterior funciona porque cada fila con un order_id de 1 tiene el mismo order_shipping de 10, y cada fila con un order_id de 2 tiene el mismo order_shipping de 20.
Los campos type: median_distinct se pueden formatear con los parámetros value_format o value_format_name.
Aspectos que debes tener en cuenta para median_distinct
El tipo de medida medium_distinct solo es compatible con ciertos dialectos. Si median_distinct no está disponible para el dialecto, Looker muestra un error. Dado que median se puede considerar el percentil 50, el error indica que el dialecto no admite percentiles distintos.
Dialectos de bases de datos compatibles con median_distinct
Para que Looker admita el tipo median_distinct en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlo. En la siguiente tabla, se muestran los dialectos que admiten el tipo median_distinct en la versión más reciente de Looker:
| Dialecto | ¿Es compatible? |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13+ | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |
min
type: min encuentra el valor más pequeño en un campo determinado. Utiliza la función MIN de SQL.
El parámetro sql para las medidas de type: min puede tomar cualquier expresión de SQL válida que genere una columna de tabla numérica, una dimensión de LookML o una combinación de dimensiones de LookML.
Dado que las medidas de type: min solo son compatibles con los campos numéricos, no puedes usar una medida de type: min para encontrar una fecha mínima. En su lugar, puedes usar la función MIN() en el parámetro sql de una medida de type: date para capturar un mínimo, al igual que puedes usar la función MAX() con una medida de type: date para capturar una fecha máxima. Esto se mostró anteriormente en esta página en la sección date, que incluye ejemplos del uso de la función MAX() en el parámetro sql para encontrar una fecha máxima.
Los campos type: min se pueden formatear con los parámetros value_format o value_format_name.
Por ejemplo, el siguiente LookML crea un campo llamado smallest_order observando la dimensión sales_price y, luego, lo muestra en formato de dinero (USD 1,234.56):
measure: smallest_order {
type: min
sql: ${sales_price} ;;
value_format_name: usd
}
No puedes usar medidas de type: min para cadenas o fechas, pero puedes agregar manualmente la función MIN para crear un campo de este tipo, de la siguiente manera:
measure: earliest_name_in_alphabet {
type: string
sql: MIN(${name}) ;;
}
number
type: number se usa con números o enteros. Una medida de type: number no realiza ninguna agregación y está diseñada para realizar transformaciones básicas en otras medidas. Si defines una métrica basada en otra, la nueva métrica debe ser de tipo type: number para evitar errores de agregación anidada.
El parámetro sql para las medidas de type: number puede tomar cualquier expresión de SQL válida que dé como resultado un número o un número entero.
Los campos type: number se pueden formatear con los parámetros value_format o value_format_name.
Por ejemplo, el siguiente LookML crea una medida llamada total_gross_margin_percentage basada en las medidas agregadas total_sale_price y total_gross_margin, y, luego, la muestra en formato de porcentaje con dos decimales (12.34%):
measure: total_sale_price {
type: sum
value_format_name: usd
sql: ${sale_price} ;;
}
measure: total_gross_margin {
type: sum
value_format_name: usd
sql: ${gross_margin} ;;
}
measure: total_gross_margin_percentage {
type: number
value_format_name: percent_2
sql: ${total_gross_margin}/ NULLIF(${total_sale_price},0) ;;
}
En este ejemplo, también se usa la función NULLIF() de SQL para evitar la posibilidad de errores de división por cero.
Aspectos que debes tener en cuenta para type: number
Cuando uses medidas de type: number, ten en cuenta los siguientes aspectos importantes:
- Una medida de
type: numbersolo puede realizar operaciones aritméticas con otras medidas, no con otras dimensiones. - Los agregados simétricos de Looker no protegerán las funciones de agregación en el SQL de una medida
type: numbercuando se calculen en una unión. - El parámetro
filtersno se puede usar con las medidas detype: number, pero la documentación defiltersexplica una solución alternativa. - Las medidas de
type: numberno proporcionarán sugerencias a los usuarios.
percent_of_previous
type: percent_of_previous calcula la diferencia de porcentaje entre una celda y la celda anterior de su columna.
El parámetro sql para las métricas de type: percent_of_previous debe hacer referencia a otra métrica numérica.
Los campos type: percent_of_previous se pueden formatear con los parámetros value_format o value_format_name. Sin embargo, los formatos de porcentaje del parámetro value_format_name no funcionan con las métricas de type: percent_of_previous. Estos formatos de porcentaje multiplican los valores por 100, lo que sesga los resultados de un cálculo de porcentaje del valor anterior.
Este ejemplo de LookML crea una medida count_growth basada en la medida count:
measure: count_growth {
type: percent_of_previous
sql: ${count} ;;
}
Ten en cuenta que los valores de percent_of_previous dependen del orden de clasificación. Si cambias la clasificación, debes volver a ejecutar la consulta para volver a calcular los valores de percent_of_previous. En los casos en que se pivota una consulta, percent_of_previous se ejecuta a lo largo de la fila en lugar de hacia abajo en la columna. No puedes cambiar este comportamiento.
Además, las métricas de percent_of_previous se calculan después de que se devuelven los datos de tu base de datos. Esto significa que no debes hacer referencia a una medida percent_of_previous dentro de otra medida, ya que es posible que se calculen en momentos diferentes y que no obtengas resultados precisos. Esto también significa que no se pueden filtrar las métricas de percent_of_previous.
Una aplicación de este tipo de medida es el análisis comparativo de períodos (PoP), que es un patrón de análisis que mide algo en el presente y lo compara con la misma medición en un período comparable del pasado. Para obtener más información sobre el PoP, consulta los artículos de la Comunidad de Looker Cómo realizar un análisis comparativo del período actual con el anterior y Métodos para el análisis comparativo del período actual con el anterior (PoP) en Looker.
percent_of_total
type: percent_of_total calcula la proporción de una celda en el total de la columna. El porcentaje se calcula en función del total de las filas que devuelve tu búsqueda, no del total de todas las filas posibles. Sin embargo, si los datos que devuelve tu consulta superan un límite de filas, los valores del campo aparecerán como nulos, ya que se necesitan los resultados completos para calcular el porcentaje del total.
El parámetro sql para las métricas de type: percent_of_total debe hacer referencia a otra métrica numérica.
Los campos type: percent_of_total se pueden formatear con los parámetros value_format o value_format_name. Sin embargo, los formatos de porcentaje del parámetro value_format_name no funcionan con las métricas de type: percent_of_total. Estos formatos de porcentaje multiplican los valores por 100, lo que sesga los resultados de un cálculo de percent_of_total.
Este ejemplo de LookML crea una medida percent_of_total_gross_margin basada en la medida total_gross_margin:
measure: percent_of_total_gross_margin {
type: percent_of_total
sql: ${total_gross_margin} ;;
}
En los casos en que se pivota una consulta, percent_of_total se ejecuta a lo largo de la fila en lugar de hacia abajo en la columna. Si no es lo que quieres, agrega direction: "column" a la definición de la métrica.
Además, las métricas de percent_of_total se calculan después de que se devuelven los datos de tu base de datos. Esto significa que no debes hacer referencia a una medida percent_of_total dentro de otra medida, ya que es posible que se calculen en momentos diferentes y que no obtengas resultados precisos. Esto también significa que no se pueden filtrar las métricas de percent_of_total.
percentile
type: percentile devuelve el valor en el percentil especificado de los valores en un campo determinado. Por ejemplo, si se especifica el percentil 75, se devolverá el valor que es mayor que el 75% de los demás valores del conjunto de datos.
Para identificar el valor que se devolverá, Looker calcula la cantidad total de valores de datos y multiplica el percentil especificado por la cantidad total de valores de datos. Independientemente de cómo se ordenen los datos, Looker identifica el orden relativo de los valores de los datos en orden creciente. El valor de datos que devuelve Looker depende de si el cálculo da como resultado un número entero o no, como se explica en las siguientes dos secciones.
Si el valor calculado no es un número entero
Looker redondea el valor calculado hacia arriba y lo usa para identificar el valor de datos que se devolverá. En este ejemplo de 19 calificaciones de prueba, el percentil 75 se identificaría con 19 * 0.75 = 14.25, lo que significa que el 75% de los valores se encuentran en los primeros 14 valores de datos, por debajo de la posición 15. Por lo tanto, Looker devuelve el 15º valor de datos (87) como superior al 75% de los valores de datos.
Si el valor calculado es un número entero
En este caso un poco más complejo, Looker devuelve un promedio del valor de datos en esa posición y el siguiente valor de datos. Para comprender esto, considera un conjunto de 20 calificaciones de exámenes: el percentil 75 se identificaría con 20 * 0.75 = 15, lo que significa que el valor de datos en la posición 15 forma parte del percentil 75, y debemos devolver un valor que sea más alto que el 75% de los valores de datos. Al devolver el promedio de los valores en la posición 15 (82) y la posición 16 (87), Looker garantiza que el 75% de los valores sean menores o iguales que el percentil 75. Ese promedio (84.5) no existe en el conjunto de valores de datos, pero sería mayor que el 75% de los valores de datos.
Parámetros obligatorios y opcionales
Usa la palabra clave percentile: para especificar el valor fraccionario, es decir, el porcentaje de los datos que deben estar por debajo del valor devuelto. Por ejemplo, usa percentile: 75 para especificar el valor en el percentil 75 en el orden de los datos o percentile: 10 para devolver el valor en el percentil 10. Si deseas encontrar el valor en el percentil 50, puedes especificar percentile: 50 o simplemente usar el tipo mediana.
El parámetro sql para las medidas type: percentile puede tomar cualquier expresión de SQL válida que genere una columna de tabla numérica, una dimensión de LookML o una combinación de dimensiones de LookML.
Los campos type: percentile se pueden formatear con los parámetros value_format o value_format_name.
Ejemplo
Por ejemplo, el siguiente LookML crea un campo llamado test_scores_75th_percentile que devuelve el valor en el percentil 75 de la dimensión test_scores:
measure: test_scores_75th_percentile {
type: percentile
percentile: 75
sql: ${TABLE}.test_scores ;;
}
Aspectos que debes tener en cuenta para percentile
Si usas percentile para un campo que participa en una expansión, Looker intentará usar percentile_distinct en su lugar. Si percentile_distinct no está disponible para el dialecto, Looker muestra un error. Para obtener más información, consulta los dialectos admitidos para percentile_distinct.
Dialectos de bases de datos compatibles con percentile
Para que Looker admita el tipo percentile en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlo. En la siguiente tabla, se muestran los dialectos que admiten el tipo percentile en la versión más reciente de Looker:
| Dialecto | ¿Es compatible? |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13+ | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |
percentile_distinct
El type: percentile_distinct es una forma especializada del percentil y se debe usar cuando tu unión implica una expansión. Utiliza los valores no repetidos en un campo determinado, según los valores únicos definidos por el parámetro sql_distinct_key. Si la medida no tiene un parámetro sql_distinct_key, Looker intenta usar el campo primary_key.
Considera el resultado de una consulta que une las tablas de elementos de pedido y pedidos:
| ID de artículo del pedido | ID de pedido | Envío del pedido |
|---|---|---|
| 1 | 1 | 10 |
| 2 | 1 | 10 |
| 3 | 2 | 20 |
| 4 | 3 | 50 |
| 5 | 3 | 50 |
| 6 | 3 | 50 |
| 7 | 4 | 70 |
| 8 | 4 | 70 |
| 9 | 5 | 110 |
| 10 | 5 | 110 |
En esta situación, puedes ver que hay varias filas para cada pedido. Esta consulta implicó una expansión porque cada pedido se asigna a varios elementos del pedido. La función percentile_distinct tiene en cuenta esto y encuentra el valor del percentil usando los valores distintos 10, 20, 50, 70 y 110. El percentil 25 devolverá el segundo valor distinto, es decir, 20, mientras que el percentil 80 devolverá el promedio del cuarto y el quinto valor distinto, es decir, 90.
Parámetros obligatorios y opcionales
Usa la palabra clave percentile: para especificar el valor fraccionario. Por ejemplo, usa percentile: 75 para especificar el valor en el percentil 75 en el orden de los datos o percentile: 10 para devolver el valor en el percentil 10. Si intentas encontrar el valor en el percentil 50, puedes usar el tipo median_distinct.
Para obtener un resultado preciso, especifica cómo Looker debe identificar cada entidad única (en este caso, cada pedido único) con el parámetro sql_distinct_key.
A continuación, se muestra un ejemplo del uso de percentile_distinct para devolver el valor en el percentil 90:
measure: order_shipping_90th_percentile {
type: percentile_distinct
percentile: 90
sql_distinct_key: ${order_id} ;;
sql: ${order_shipping} ;;
}
Cada valor único de sql_distinct_key debe tener solo un valor correspondiente en el parámetro sql de la métrica. En otras palabras, el ejemplo anterior funciona porque cada fila con un order_id de 1 tiene el mismo order_shipping de 10, y cada fila con un order_id de 2 tiene el mismo order_shipping de 20.
Los campos type: percentile_distinct se pueden formatear con los parámetros value_format o value_format_name.
Aspectos que debes tener en cuenta para percentile_distinct
Si percentile_distinct no está disponible para el dialecto, Looker muestra un error. Para obtener más información, consulta los dialectos admitidos para percentile_distinct.
Dialectos de bases de datos compatibles con percentile_distinct
Para que Looker admita el tipo percentile_distinct en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlo. En la siguiente tabla, se muestran los dialectos que admiten el tipo percentile_distinct en la versión más reciente de Looker:
| Dialecto | ¿Es compatible? |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13+ | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |
period_over_period
En el caso de los dialectos que admiten medidas de comparación entre períodos, puedes crear una medida de LookML de type: period_over_period para crear una medida de comparación entre períodos (PoP). Una medida de PoP hace referencia a una agregación de un período anterior.
A continuación, se muestra un ejemplo de una medida de PoP que proporciona el recuento de pedidos del mes anterior:
measure: orders_last_month {
type: period_over_period
based_on: orders.count
based_on_time: orders.created_month
period: month
kind: previous
}
Las medidas con type: period_over_period también deben tener los siguientes subparámetros:
Consulta Medidas de período a período en Looker para obtener más información y ejemplos.
running_total
type: running_total calcula la suma acumulada de las celdas a lo largo de una columna. No se puede usar para calcular sumas a lo largo de una fila, a menos que la fila sea el resultado de una tabla dinámica.
El parámetro sql para las métricas de type: running_total debe hacer referencia a otra métrica numérica.
Los campos type: running_total se pueden formatear con los parámetros value_format o value_format_name.
En el siguiente ejemplo de LookML, se crea una medida cumulative_total_revenue basada en la medida total_sale_price:
measure: cumulative_total_revenue {
type: running_total
sql: ${total_sale_price} ;;
value_format_name: usd
}
Ten en cuenta que los valores de running_total dependen del orden de clasificación. Si cambias la clasificación, debes volver a ejecutar la consulta para volver a calcular los valores de running_total. En los casos en que se pivota una consulta, running_total se ejecuta a lo largo de la fila en lugar de hacia abajo en la columna. Si no es lo que quieres, agrega direction: "column" a la definición de la métrica.
Además, las métricas de running_total se calculan después de que se devuelven los datos de tu base de datos. Esto significa que no debes hacer referencia a una medida running_total dentro de otra medida, ya que es posible que se calculen en momentos diferentes y que no obtengas resultados precisos. Esto también significa que no se pueden filtrar las métricas de running_total.
string
type: string se usa con campos que contienen letras o caracteres especiales.
El parámetro sql para las métricas de type: string puede tomar cualquier expresión de SQL válida que genere una cadena. En la práctica, este tipo se usa muy poco, ya que la mayoría de las funciones de agregación de SQL no devuelven cadenas. Una excepción común es la función GROUP_CONCAT de MySQL, aunque Looker proporciona type: list para ese caso de uso.
Por ejemplo, el siguiente LookML crea un campo category_list combinando los valores únicos de un campo llamado category:
measure: category_list {
type: string
sql: GROUP_CONCAT(${category}) ;;
}
En este ejemplo, se podría omitir type: string, ya que string es el valor predeterminado de type.
sum
type: sum suma los valores de un campo determinado. Es similar a la función SUM de SQL. Sin embargo, a diferencia de lo que sucede con el SQL sin procesar, Looker calculará correctamente las sumas, incluso si las uniones de tu consulta contienen expansiones.
El parámetro sql para las medidas type: sum puede tomar cualquier expresión de SQL válida que genere una columna de tabla numérica, una dimensión de LookML o una combinación de dimensiones de LookML.
Los campos type: sum se pueden formatear con los parámetros value_format o value_format_name.
Por ejemplo, el siguiente código LookML crea un campo llamado total_revenue sumando la dimensión sales_price y, luego, lo muestra en formato de dinero (USD 1,234.56):
measure: total_revenue {
type: sum
sql: ${sales_price} ;;
value_format_name: usd
}
sum_distinct
type: sum_distinct se usa con conjuntos de datos desnormalizados. Suma los valores no repetidos en un campo determinado, según los valores únicos definidos por el parámetro sql_distinct_key.
Este es un concepto avanzado que se puede explicar con mayor claridad con un ejemplo. Considera una tabla desnormalizada como esta:
| ID de artículo del pedido | ID de pedido | Envío del pedido |
|---|---|---|
| 1 | 1 | 10.00 |
| 2 | 1 | 10.00 |
| 3 | 2 | 20.00 |
| 4 | 2 | 20.00 |
| 5 | 2 | 20.00 |
En esta situación, puedes ver que hay varias filas para cada pedido. Por lo tanto, si agregaste una medida de type: sum para la columna order_shipping, obtendrías un total de 80.00, aunque el total de envío recaudado sea de 30.00.
# Will NOT calculate the correct shipping amount
measure: total_shipping {
type: sum
sql: ${order_shipping} ;;
}
Para obtener un resultado preciso, puedes definir en Looker cómo debe identificar cada entidad única (en este caso, cada pedido único) con el parámetro sql_distinct_key. Esto calculará el importe correcto de 30.00:
# Will calculate the correct shipping amount
measure: total_shipping {
type: sum_distinct
sql_distinct_key: ${order_id} ;;
sql: ${order_shipping} ;;
}
Cada valor único de sql_distinct_key debe tener un solo valor correspondiente en sql. En otras palabras, el ejemplo anterior funciona porque cada fila con un order_id de 1 tiene el mismo order_shipping de 10.00, y cada fila con un order_id de 2 tiene el mismo order_shipping de 20.00.
Los campos type: sum_distinct se pueden formatear con los parámetros value_format o value_format_name.
yesno
type: yesno crea un campo que indica si algo es verdadero o falso. Los valores aparecen como Sí y No en la IU de Explorar.
El parámetro sql para una medida type: yesno toma una expresión SQL válida que se evalúa como TRUE o FALSE. Si la condición se evalúa como TRUE, se muestra Sí al usuario; de lo contrario, se muestra No.
La expresión de SQL para las medidas de type: yesno solo debe incluir agregaciones, lo que significa agregaciones de SQL o referencias a medidas de LookML. Si deseas crear un campo yesno que incluya una referencia a una dimensión de LookML o una expresión de SQL que no sea una agregación, usa una dimensión con type: yesno, no una medida.
Al igual que las medidas con type: number, una medida con type: yesno no realiza ninguna agregación, sino que solo hace referencia a otras agregaciones.
Por ejemplo, la siguiente medida total_sale_price es un ejemplo de la suma del precio de oferta total de los artículos del pedido. Una segunda medida llamada is_large_total es type: yesno. La métrica is_large_total tiene un parámetro sql que evalúa si el valor de total_sale_price es mayor que USD 1,000.
measure: total_sale_price {
type: sum
value_format_name: usd
sql: ${sale_price} ;;
drill_fields: [detail*]
}
measure: is_large_total {
description: "Is order total over $1000?"
type: yesno
sql: ${total_sale_price} > 1000 ;;
}
Si deseas hacer referencia a un campo type: yesno en otro campo, debes tratar el campo type: yesno como un valor booleano (en otras palabras, como si ya contuviera un valor verdadero o falso). Por ejemplo:
measure: is_large_total {
description: "Is order total over $1000?"
type: yesno
sql: ${total_sale_price} > 1000 ;;
}
# This is correct:
measure: reward_points {
type: number
sql: CASE WHEN ${is_large_total} THEN 200 ELSE 100 END ;;
}
# This is NOT correct:
measure: reward_points {
type: number
sql: CASE WHEN ${is_large_total} = 'Yes' THEN 200 ELSE 100 END ;;
}