Este es un tema avanzado que supone que el lector tiene un conocimiento sólido de LookML.
Descripción general
Con los refinamientos de LookML, puedes adaptar una vista o Explorar existente sin editar el archivo LookML que lo contiene. Esto es ideal para lo siguiente:
- Proyectos con bloques de Looker, que usan piezas prediseñadas de LookML
- Proyectos que importan archivos de otros proyectos
- Proyectos en los que a menudo necesitas generar tus archivos a partir de tablas en tu base de datos
- Situaciones en las que desee compartir LookML entre modelos o proyectos mientras realiza personalizaciones en cada lugar (configuraciones de concentrador y radio)
Por ejemplo, si tienes el siguiente archivo de vista en tu proyecto:
view: flights {
sql_table_name: flightstats.accidents ;;
dimension: id {
label: "id"
primary_key: yes
type: number
sql: ${TABLE}.id ;;
}
}
Puedes refinar la vista flights
como se muestra a continuación: usa el parámetro view
con el mismo nombre de vista, pero agrega un signo más (+
) delante del nombre para indicar que es un refinamiento de una vista existente.
Este perfeccionamiento agrega una dimensión air_carrier
a la vista flights
existente:
view: +flights {
dimension: air_carrier {
type: string
sql: ${TABLE}.air_carrier ;;
}
}
Este perfeccionamiento puede incluirse en cualquier archivo LookML del proyecto, como un archivo de modelo, un archivo de vista o su propio archivo LookML. Consulta la sección Cómo definir mejor tu proyecto de LookML para ver cómo funciona.
El perfeccionamiento combinado con el LookML original tiene el resultado final como si fuera el LookML original para la vista:
view: flights {
sql_table_name: flightstats.accidents ;;
dimension: id {
label: "id"
primary_key: yes
type: number
sql: ${TABLE}.id ;;
}
dimension: air_carrier {
type: string
sql: ${TABLE}.air_carrier ;;
}
}
En la IU de Looker, los usuarios verán la dimensión Air Carrier, como si hubieran agregado la dimensión al archivo de vista original.
Consulta el ejemplo a continuación para obtener información más detallada sobre la implementación.
Mejoras en comparación con las extensiones
Looker también es compatible con la extensión de objetos LookML. Extender es útil cuando desea crear una copia nueva de una vista existente o Explorar para poder agregarle objetos nuevos. Por ejemplo, puedes crear una vista base que defina todos tus campos y, luego, crear varias vistas nuevas que extiendan la vista base. Estas vistas nuevas se pueden modificar para ocultar ciertos campos en la vista base o para cambiar las definiciones o etiquetas de los campos de la vista base.
Las mejoras son útiles cuando quieres modificar una vista existente o Explorar con algunos ajustes o ajustes en ciertos objetos, pero no quieres crear copias de ella. Las mejoras son ideales para situaciones en las que no puedes o no deseas modificar la vista base o Explorar, y para situaciones en las que crear una vista nueva o explorar requeriría grandes cambios en otras referencias de LookML. Consulta la sección Ejemplo en esta página para ver un ejemplo de este caso práctico.
En la mayoría de los casos prácticos, los perfeccionamientos son una alternativa más simple y limpia a extends
.
Es posible que los desarrolladores avanzados de LookML usen el parámetro extends
dentro de un perfeccionamiento de LookML. Para obtener más información, consulta la sección Las mejoras pueden contener extensiones en esta página.
Las mejoras anulan la mayoría de los parámetros
Es importante tener en cuenta que, en la mayoría de los casos, un perfeccionamiento anulará la configuración original de un objeto. En el siguiente ejemplo, la vista original tiene una dimensión oculta (hidden: yes
):
view: faa_flights {
dimension: carrier {
hidden: yes
}
}
En otro archivo, se define mejor esa dimensión con hidden: no
:
include: "/views/faa_flights.view.lkml"
view: +faa_flights {
dimension: carrier {
hidden: no
}
}
El último perfeccionamiento tiene prioridad, por lo que se aplica hidden: no
y la dimensión se muestra en la vista final.
En algunos casos, los perfeccionamientos son aditivos en lugar de anularse. Consulte la sección Algunos parámetros son aditivos de esta página para obtener más información.
Algunos parámetros son aditivos
En muchos casos, si el perfeccionamiento contiene el mismo parámetro que el objeto que se define mejor, el refinamiento anulará los valores del parámetro del objeto perfeccionado.
Sin embargo, los refinamientos pueden ser aditivos para algunos parámetros, lo que significa que los valores del objeto base se usan junto con los valores del objeto mejor definido.
Los siguientes parámetros son aditivos:
Para las dimensiones y medidas:
Para las vistas:
extends
(Consulta la sección Cómo definir mejorextends
son aditivos en esta página para obtener más información).
Para Explorar:
access_filter
aggregate_table
extends
(Consulta la sección Cómo definir mejorextends
son aditivos en esta página para obtener más información).join
query
Por ejemplo, esta es una vista que tiene una dimensión name
con un parámetro link
:
view: carriers {
sql_table_name: flightstats.carriers ;;
dimension: name {
sql: ${TABLE}.name ;;
type: string
link: {
label: "Google {{ value }}"
url: "http://www.google.com/search?q={{ value }}"
icon_url: "http://google.com/favicon.ico"
}
}
}
A continuación, se define mejor la vista carriers
con una dimensión name
que tiene valores diferentes para el parámetro link
:
include: "/views/carriers.view.lkml"
view: +carriers {
label: "Refined carriers"
dimension: name {
sql: ${TABLE}.name ;;
type: string
link: {
label: "Dashboard for {{ value }}"
url: "https://docsexamples.dev.looker.com/dashboards/307?Carrier={{ value }}"
icon_url: "https://www.looker.com/favicon.ico"
}
}
}
En la vista mejorada de carriers
, los dos parámetros link
son aditivos, por lo que la dimensión name
tendrá ambos vínculos. La dimensión se ve de la siguiente manera en Explorar:
Las mejoras se aplican en orden
Un objeto se puede definir mejor varias veces y en varios lugares, lo que permite a los desarrolladores de Looker usar refinamientos de muchas maneras creativas. Pero esto también significa que los desarrolladores deben ser muy conscientes del orden en el que se aplican las mejoras:
- En un proyecto, los perfeccionamientos se aplican en el orden en que se incluyen sus archivos. Los perfeccionamientos de los archivos incluidos en último lugar anularán los perfeccionamientos de los archivos incluidos anteriormente.
- Dentro de un único archivo, los perfeccionamientos se aplican línea por línea descendentes. Los perfeccionamientos con el número de línea más alto se aplican en último lugar y anularán los perfeccionamientos anteriores si hay conflictos.
Puedes usar la marca
final: yes
para verificar que tus mejoras se apliquen en el orden esperado. Consulta la sección Uso definal: yes
para evitar refinamientos para obtener más detalles.
Por ejemplo, en el siguiente archivo de vista, hay dos mejoras de la vista faa_flights
. El primer perfeccionamiento oculta una dimensión (hidden: yes
), y el segundo mejor perfeccionamiento muestra la dimensión (hidden: no
). Cuando hay conflictos como este, el perfeccionamiento más abajo en el archivo tiene prioridad:
include: "//e_faa_original/views/faa_flights.view.lkml"
view: +faa_flights {
dimension: carrier {
hidden: yes
}
}
view: +faa_flights {
dimension: carrier {
hidden: no
}
}
La lógica es similar para incluir varios archivos en un proyecto: las mejoras en el último archivo enumerado en las inclusiones tendrán prioridad. Por ejemplo, si un archivo de modelo incluye estos archivos:
include: "/refinements/distance_analysis.lkml"
include: "/refinements/finishing_touches.lkml"
Primero, se aplicará cualquier mejora en distance_analysis.lkml
y, luego, en el archivo finishing_touches.lkml
. Si hay algún conflicto, los refinamientos del último archivo, finishing_touches.lkml
, tendrán prioridad.
Debido a que los refinamientos aprovechan el orden de las inclusiones, no debes usar comodines en tus inclusiones si deseas usar refinamientos. Como práctica general, se recomienda evitar el uso de comodines con las vistas de todos modos, especialmente si tu proyecto tiene una gran cantidad de archivos de vista o si usa tablas derivadas (PDT) persistentes. Sin embargo, con los refinamientos en particular, no se recomienda usar comodines en sus inclusiones.
Usa final: yes
para evitar otras mejoras
Como se describió anteriormente, el mismo objeto se puede definir mejor varias veces en varios lugares, y el último perfeccionamiento anulará todos los perfeccionamientos anteriores.
Si defines mejor tu búsqueda para que se considere el mejor ajuste final de la vista o Explorar, puedes agregar la marca final: yes
al perfeccionamiento. El IDE de Looker mostrará un error de LookML si hay mejoras definidas que se aplicarían después de esta mejora final, o si un desarrollador intenta agregar una nueva mejora que se aplicaría después de esta mejora final. Por ejemplo, el segundo perfeccionamiento en este archivo de vista crearía un error LookML porque el perfeccionamiento anterior tiene la marca final: yes
:
include: "//e_faa_original/views/faa_flights.view.lkml"
view: +faa_flights {
final: yes
dimension: carrier {
hidden: yes
}
}
view: +faa_flights {
dimension: carrier {
hidden: no
}
}
Agregar la marca final: yes
a un perfeccionamiento es una buena manera de verificar que los perfeccionamientos se apliquen en el orden deseado.
Las mejoras pueden contener extensiones.
Los desarrolladores avanzados de LookML pueden usar un parámetro extends
dentro de un perfeccionamiento de LookML, que agrega el objeto extendido al que se define mejor.
Para resumir el comportamiento de extends
y las mejoras:
- Cuando se extiende un objeto, se crea una copia nueva y, luego, se basa en él. Por ejemplo, puedes crear una vista base que defina todos tus campos y, luego, crear varias vistas nuevas que extiendan la vista base. Cada una de estas nuevas vistas incorporará una copia de la vista base y, desde allí, un desarrollador puede agregar diferentes campos, filtros u otras propiedades para modificar lo que está en la vista base. La idea es comenzar con un objeto base y luego usarlo de diferentes maneras en muchos otros objetos. (Puedes consultar la página de documentación Cómo reutilizar código con extensiones para ver un análisis completo sobre cómo trabajar con extensiones).
- Definir mejor un objeto agrega una capa de modificaciones al objeto, pero, a diferencia de este, el perfeccionamiento no realiza varias copias del objeto. La idea es compilar sobre un objeto base sin modificar su LookML original.
A modo de ejemplo del uso estándar de las mejoras, aquí se incluye una exploración llamada orders
y la exploración +orders
que la define mejor:
explore: orders {
view_name: orders
# other Explore parameters
}
explore: +orders {
label: "Orders Information"
# other Explore parameters to build on the original Explore
}
Además de esto, puedes agregar un perfeccionamiento que incluya un extends
. Sobre la base del ejemplo, esta es la misma exploración de orders
. Además, hay un Explorar base llamado users_base
y, ahora, el perfeccionamiento de +orders
tiene un parámetro extends
que incluye el users_base
:
explore: users_base {
view_name: users
extension: required
# other Explore parameters
}
explore: orders {
view_name: orders
# other Explore parameters
}
explore: +orders {
label: "Orders Information"
extends: [users_base]
# other Explore parameters to build on the original Explore
}
Lo especial es que el refinamiento de +orders
tiene un extends
. El resultado es que la vista +orders
ahora extenderá la exploración de users_base
.
Cómo Looker implementa extends
dentro de refinamientos
Extender un objeto dentro de un perfeccionamiento es un concepto avanzado de LookML. Antes de usar extends
en un refinamiento, debes comprender lo siguiente:
- Cómo implementa Looker
extends
: Si un elemento LookML se define tanto en el objeto ed extendido como en el objeto ing, se usa la versión del objeto extensible, a menos que el parámetro sea aditivo. Consulta la página de documentación Cómo reutilizar código con extensiones para obtener más detalles. - Cómo implementa Looker mejor las definiciones: Si un elemento de LookML se define en varias mejoras, el último perfeccionamiento anula las mejoras anteriores. Consulte la sección Las refinaciones se aplican en orden en esta página para obtener más detalles.
Por último, debes comprender cómo Looker combina estos principios para implementar extends
que se usa en las mejoras. Este es el orden que implementa Looker, y cada paso anula el anterior en caso de conflictos:
- Valores de
extends
especificados en el objeto - Valores de
extends
especificados en el perfeccionamiento del objeto - Valores del objeto
- Valores de las mejoras del objeto
A continuación, se muestra un ejemplo en el que se muestra el valor del parámetro label
durante cada paso de la implementación:
explore: orders_base {
label: "Orders Base"
view_name: orders
extension: required
}
explore: users_base {
label: "Users Base"
view_name: users
extension: required
}
explore: orders {
label: "Orders"
extends: [orders_base]
}
explore: +orders {
label: "Orders Refined"
extends: [users_base]
}
A continuación, se muestra cómo Looker implementa el valor de label
para la exploración orders
en este ejemplo:
- Valores de
extends
especificados en el objeto. Dado que la exploración deorders
tiene un parámetroextends
, Looker comienza con los elementos de LookML del objeto que se extiende, que en este caso es la exploración deorders_base
. En este punto, el valorlabel
es "Orders Base". - Valores de
extends
especificados en el refinamiento del objeto. Dado queorders
tiene un refinamiento y el refinamiento tiene un parámetroextends
, Looker aplica elementos LookML de la extensión de refinamiento, que en este caso esusers_base
Explorar. En este punto, el valorlabel
es &base de usuarios". - Valores del objeto. Ahora que se abordaron todas las extensiones, Looker aplica elementos del objeto extendido, que en este caso es
orders
Explore. Si hay algún conflicto, el objeto que se extiende gana. Ahora, el valorlabel
es "Orders". - Valores de las mejoras del objeto. Por último, Looker aplica elementos de cualquier perfeccionamiento de
orders
Explorar. Si hay algún conflicto, el objeto de refinamiento gana. Ahora, el valorlabel
es "Orders Fine".
El refinamiento extends
es aditivo
Como se describe en la sección Parámetros de anulación de perfeccionamientos en esta página, los perfeccionamientos suelen anular la configuración original de un objeto. Este no es el caso del parámetro extends
. Cuando se usa extends
en un refinamiento, el valor del parámetro extends
se agrega a la lista de elementos extendidos en el objeto original o en refinamientos anteriores, si corresponde. Luego, si hay algún conflicto, se le da prioridad al último elemento de la cadena de extensiones.
Por ejemplo, aquí tienes una exploración base llamada orders_base
y una exploración orders
que extiende la base. Además, hay una exploración de users_base
y un perfeccionamiento de +orders
que extiende users_base
:
explore: orders_base {
view_name: orders
extension: required
# other Explore parameters
}
explore: users_base {
view_name: users
extension: required
# other Explore parameters
}
explore: orders {
extends: [orders_base]
# other Explore parameters to build on the base Explore
}
explore: +orders {
extends: [users_base]
# other Explore parameters to build on the base Explores
}
La exploración de orders
extiende orders_base
y, luego, los perfeccionamientos +orders
agregan users_base
a la lista extends
. El resultado es que la exploración de +orders
ahora extenderá orders_base
y users_base
, como si fuera el LookML original para la exploración:
explore: orders {
extends: [orders_base, users_base]
}
Luego, si hay algún conflicto, se le da prioridad al último elemento de la cadena de extensiones. En este ejemplo, los elementos de users_base
anularían cualquier elemento en conflicto de orders_base
.
El concepto de extender más de un objeto a la vez se analiza en la página de documentación Reutiliza código con extensiones.
Un último aspecto para tener en cuenta: en este ejemplo, no importa el orden de los parámetros explore
. Sin embargo, en los casos en los que se define mejor el mismo objeto, el orden de los perfeccionamientos sí importa. Como se describe en la sección Los perfeccionamientos se aplican en orden en esta página, el último perfeccionamiento de un archivo anula los perfeccionamientos anteriores.
Cómo definir mejor tu proyecto de LookML
Estos son los pasos generales para definir mejor las vistas y las exploraciones en tu proyecto:
- Identifica la vista o la exploración que quieres definir mejor.
- Decide dónde quieres almacenar las mejoras. Puede agregar mejoras en cualquier archivo LookML existente o puede crear archivos LookML independientes para sus mejoras. (Consulte el procedimiento para crear un archivo de prueba de datos en la página de documentación Cómo comprender otros archivos de proyecto para ver un ejemplo de cómo crear archivos genéricos de LookML).
- Usa el parámetro
include
para incorporar tus mejoras a tu modelo:- En el archivo en el que escribes los ajustes, debes incluir los archivos del LookML que estás perfeccionando. El IDE de Looker te mostrará advertencias si intentas definir mejor un objeto que no está incluido.
- En el archivo del modelo, incluye los archivos en los que se definen las mejoras. Puedes combinar archivos y usar inclusiones de formas muy creativas. Consulta la sección Uso de refinamientos para agregar capas a tu modelo en esta página para obtener más detalles.
Ejemplo
Definir mejor los objetos de LookML es una manera sencilla de adaptar las vistas y los elementos Explorar sin tener que editar el original. Esto es particularmente útil cuando las vistas y las exploraciones son de solo lectura en tu proyecto, como con los archivos importados de otros proyectos. Este es un ejemplo de cómo definir mejor una exploración.
Este es el LookML para la exploración de aircraft
:
explore: aircraft {
join: aircraft_types {
type: left_outer
sql_on: ${aircraft.id} = ${aircraft_types.id} ;;
relationship: many_to_one
}
join: aircraft_engine_types {
type: left_outer
sql_on: ${aircraft.id} = ${aircraft_engine_types.id} ;;
relationship: many_to_one
}
}
Esta pestaña Explorar contiene varias vistas, cada una de las cuales tiene muchas dimensiones.
Ahora, otro proyecto de LookML llamado e_faa_refined
importa el archivo Explorar de aircraft
. En el proyecto e_faa_refined
, puedes definir mejor la exploración de aircraft
.
Como aircraft
Explorar es un archivo importado, no puedes editarlo directamente. En su lugar, puedes definirlo mejor. Este es un ejemplo de un archivo separado llamado refinements.lkml
que contiene este LookML:
include: "//e_faa_original/Explores/aircraft.explore.lkml"
explore: +aircraft {
label: "Aircraft Simplified"
fields: [aircraft.aircraft_serial, aircraft.name, aircraft.count]
}
El archivo refinements.lkml
contiene lo siguiente:
- El parámetro
include
para incorporar el archivoaircraft.explore.lkml
original del proyecto importado (consulta la página de documentación Cómo importar archivos de otros proyectos para obtener detalles sobre cómo hacer referencia a los archivos importados del proyecto) - Mejoras en la exploración de
aircraft
:
El resultado final es como si esta fuese la vista aircraft
original y la vista aircraft
:
explore: aircraft {
label: "Aircraft Simplified"
}
view: aircraft {
sql_table_name: flightstats.aircraft ;;
dimension: aircraft_serial {
type: string
sql: ${TABLE}.aircraft_serial ;;
}
dimension: name {
type: string
sql: ${TABLE}.name ;;
}
measure: count {
type: count
}
}
Otros casos de uso para mejoras
Como se mencionó antes, los perfeccionamientos son ideales para adaptar objetos de LookML que son de solo lectura, como los bloques de Looker o los archivos importados.
Sin embargo, una vez que te familiarices con el proceso para agregar detalles a tus modelos e incluirlos en ellos, podrás hacer cosas geniales con tus proyectos, como se describe en los siguientes ejemplos.
Cómo definir mejor los análisis
Puede utilizar mejoras para agregar análisis a su modelo sin tocar los archivos originales de LookML. Por ejemplo, si hay un proyecto en el que las vistas y las exploraciones se generan a partir de tablas de tu base de datos y se almacenan en un archivo LookML llamado faa_basic.lkml
, puedes crear un archivo faa_analysis.lkml
en el que uses mejoras para agregar análisis. Este es un ejemplo de una tabla derivada nueva llamada distance_stats
que tiene un análisis de distancia. En este ejemplo, se muestra una mejora de la exploración existente flights
del archivo faa_basic.lkml
que une la tabla derivada distance_stats
con la exploración flights
. Además, en la parte inferior del ejemplo, se define mejor la vista flights
existente para agregar campos nuevos del análisis:
include: "faa_basic.lkml"
explore: +flights {
join: distance_stats {
relationship: one_to_one
type: cross
}
}
view: distance_stats {
derived_table: {
explore_source: flights {
bind_all_filters: yes
column: distance_avg {field:flights.distance_avg}
column: distance_stddev {field:flights.distance_stddev}
}
}
dimension: avg {
type:number
sql: CAST(${TABLE}.distance_avg as INT64) ;;
}
dimension: stddev {
type:number
sql: CAST(${TABLE}.distance_stddev as INT64) ;;
}
}
view: +flights {
measure: distance_avg {
type: average
sql: ${distance} ;;
}
measure: distance_stddev {
type: number
sql: STDDEV(${distance}) ;;
}
dimension: distance_tiered2 {
type: tier
sql: ${distance} ;;
tiers: [500,1300]
}
}
Cómo definir mejor las capas del modelo
Otro caso de uso interesante para definir mejor es agregar capas a tu proyecto. Puede crear varios archivos de mejoras y, luego, incluirlos estratégicamente para agregar capas.
Por ejemplo, en el proyecto de FAA, hay un archivo faa_raw.lkml
que contiene todas las vistas y exploraciones que se generaron a partir de tablas en tu base de datos. Este archivo tiene una vista para cada tabla de la base de datos, cada una con una dimensión para cada columna de la base de datos.
Además del archivo sin procesar, puedes crear un archivo faa_basic.lkml
para agregar una capa nueva con refinamientos básicos, como agregar uniones a tus exploraciones o agregar medidas a tus vistas, de la siguiente manera:
include: "faa_raw.lkml"
explore: +flights {
join: carriers {
sql_on: ${flights.carrier} = ${carriers.name} ;;
}
}
view: +flights {
measure: total_seats {
type: sum
sql: ${aircraft_models.seats} ;;
}
}
Luego, puedes agregar un archivo faa_analysis.layer.lkml
para agregar una capa nueva con los análisis (consulta la subsección Cómo definir mejor a fin de agregar análisis para ver un ejemplo de un archivo de análisis).
Desde allí, solo debe incluir todos los archivos de mejoras en el archivo del modelo. También puedes usar el archivo de modelo para agregar mejoras que apunten a tus vistas en las tablas de base de datos a las que deseas hacer referencia:
connection: "publicdata_standard_sql"
include: "faa_raw.lkml"
include: "faa_basic.lkml"
include: "faa_analysis.lkml"
view: +flights {
sql_table_name: lookerdata.faa.flights;;
}
view: +airports {
sql_table_name: lookerdata.faa.airports;;
}
view: +aircraft {
sql_table_name: lookerdata.faa.aircraft;;
}
view: +aircraft_models{
sql_table_name: lookerdata.faa.aircraft_models;;
}
view: +carriers {
sql_table_name: lookerdata.faa.carriers;;
}
Puedes duplicar este archivo de modelo y apuntar a diferentes tablas de base de datos, o puedes incluir archivos de refinamiento diferentes que hayas creado para definir otras capas que desees en tu modelo.
Cómo definir mejor las PDT
Como se describe en la sección Mejoras en comparación con las extensiones en esta página, una extensión crea una copia nueva del objeto que se extiende. En el caso de las tablas derivadas persistentes (PDT), no debes usar extensiones, ya que cada extensión de un PDT creará una copia nueva de la tabla en la base de datos.
Sin embargo, puedes agregar mejoras a la vista de PDT, ya que las mejoras no crean una copia nueva del objeto que se va a definir mejor.
Usa metadatos para ver el perfeccionamiento de un objeto
Puedes hacer clic en un parámetro explore
o view
en el IDE de Looker y usar el panel de metadatos para ver cualquier perfeccionamiento del objeto. Consulta la página de documentación Metadatos para objetos LookML a fin de obtener más información.
Aspectos para tener en cuenta
Proyectos con localización
Cuando definas mejor un objeto, ten en cuenta que también se aplican las reglas de localización. Si defines mejor un objeto y, luego, defines nuevas etiquetas o descripciones, debes proporcionar definiciones de localización en los archivos de strings de configuración regional de tu proyecto. Consulta la página de documentación Localiza tu modelo de LookML para obtener más información.