Mejoras en LookML

Descripción general

Con las mejoras de LookML, puede adaptar una vista o Explorar existente sin editar el archivo LookML que lo contiene. Esto es ideal para lo siguiente:

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 definir mejor la vista de 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 una mejora 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 de LookML del proyecto, como un archivo de modelo, un archivo de vista o su propio archivo de LookML. Consulta la sección Cómo definir mejor tu proyecto de LookML para descubrir cómo funciona.

El perfeccionamiento combinado con el LookML original tiene el resultado final como si este 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 Operador de aire, como si hubiera agregado la dimensión al archivo de vista original.

Consulta el ejemplo que se incluye a continuación para obtener información más detallada de implementación.

Mejoras en comparación con las extensiones

Looker también admite la extensión de objetos LookML. La extensión es útil cuando deseas crear una copia nueva de una vista existente o Explorar para poder agregarle objetos nuevos. Por ejemplo, puede crear una vista base que defina todos sus campos y, luego, crear varias vistas nuevas que extiendan esa vista. Luego, estas vistas nuevas se pueden modificar a fin de 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 desea modificar una vista existente o Explorar con algunos ajustes o ajustes en ciertos objetos, pero no desea crear copias de la vista o Explorar. Las mejoras son ideales para situaciones en las que no puede o no desea modificar la vista base o Explorar, y para situaciones en las que la creación de una vista nueva o en 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 de uso.

En la mayoría de los casos de uso, las mejoras son una alternativa más simple y limpia a extends.

Se recomienda que los desarrolladores avanzados de LookML usen el parámetro extends dentro de un perfeccionamiento de LookML. Consulta la sección Los perfeccionamientos pueden contener extensiones en esta página para obtener más información.

Los perfeccionamientos anulan la mayoría de los parámetros

Es importante tener en cuenta que, en la mayoría de los casos, el 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
  }
}

La última mejora tiene prioridad, por lo que se aplica hidden: no, y la dimensión se mostrará 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 perfecciona, el perfeccionamiento anulará los valores del parámetro del objeto mejor definido.

Sin embargo, los perfeccionamientos 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:

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

Aquí te mostramos un perfeccionamiento para 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 mejor definida (carriers), los dos parámetros link son aditivos, por lo que la dimensión name mostrará ambos vínculos.

Las mejoras se aplican en orden

Un objeto se puede definir mejor varias veces y en varios lugares, lo que permite que los desarrolladores de Looker usen mejoras de muchas maneras creativas. Sin embargo, esto también significa que los desarrolladores deben ser muy conscientes del orden en el que se aplican las mejoras:

  • En un proyecto, las mejoras se aplican en el orden en que se incluyen sus archivos. Las mejoras de los archivos incluidos en último lugar anularán el refinamiento de los archivos incluidos anteriormente.
  • Dentro de un solo archivo, los perfeccionamientos se aplican línea por línea hacia abajo. Las mejoras con el número de línea más alto se aplican en último lugar y, si hay conflictos, anularán las anteriores.

Por ejemplo, en el siguiente archivo de vista, se definen dos mejoras de la vista faa_flights. El primer perfeccionamiento oculta una dimensión (hidden: yes), mientras que el segundo define la dimensión (hidden: no). Cuando hay conflictos como este, prevalece el perfeccionamiento en el archivo: 

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 del último archivo que figura 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 que se defina en el archivo distance_analysis.lkml y, luego, en el archivo finishing_touches.lkml. Si hay algún conflicto, prevalecerá la mejora del último archivo, finishing_touches.lkml.

Usa final: yes para evitar perfeccionamientos

Como se describió anteriormente, el mismo objeto se puede definir mejor en varias partes en varios lugares, y el último perfeccionamiento anulará todas las mejoras anteriores.

Si defines mejor tu definición para que se considere como el perfeccionamiento final de la vista o la exploración, puedes agregar la marca final: yes al perfeccionamiento. El IDE de Looker mostrará un error de LookML si hay mejoras que se aplicarían después de esta mejora final, o si un desarrollador intenta agregar una mejora nueva que se aplicaría después de esta mejora final. Por ejemplo, la segunda mejora en este archivo de vista crearía un error LookML porque la mejora 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 una mejora es una buena forma de verificar que los perfeccionamientos se apliquen en el orden que desea.

Las mejoras pueden contener extensiones

Se recomienda que los desarrolladores avanzados de LookML usen un parámetro extends dentro de un perfeccionamiento de LookML, que agrega el objeto extendido al objeto que se va a definir mejor.

Para resumir el comportamiento de extends y las mejoras, haz lo siguiente:

  • Cuando se extiende un objeto, se crea una copia nueva del objeto y, luego, se basa en él. Por ejemplo, puede crear una vista base que defina todos sus campos y, luego, crear varias vistas nuevas que extiendan esa vista. Cada una de estas vistas nuevas 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 que comience con un objeto base y, luego, lo use de diferentes maneras en varios otros objetos. (Puedes ver la página de documentación Reutilización del código con extensiones para obtener un análisis completo del trabajo con extensiones).
  • Cuando se define mejor un objeto, se agrega una capa de modificaciones a este, pero, a diferencia de lo que ocurre con extender, el perfeccionamiento no realiza varias copias del objeto. La idea es compilar un objeto base sin modificar su LookML original.

A modo de ejemplo del uso estándar de las mejoras, aquí se muestra 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, puedes agregar un perfeccionamiento que incluya un extends. Sobre la base del ejemplo, esta es la misma exploración de orders. Sin embargo, hay una exploración base llamada users_base, y ahora el perfeccionamiento +orders tiene un parámetro extends que trae 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 perfeccionamiento +orders tenga un extends. Como resultado, la vista +orders ahora extenderá la exploración de users_base.

Cómo implementa Looker extends dentro de las mejoras

Extender un objeto dentro de un perfeccionamiento es un concepto avanzado de LookML. Antes de usar extends en una mejora, debes comprender lo siguiente:

  • Cómo implementa Looker extends: Si un elemento LookML se define en el objeto extendido y en el objeto extending, se usa la versión en el objeto extendido, a menos que el parámetro sea aditivo. Consulta la página de documentación Reutilización del código con extensiones para obtener más detalles.
  • Cómo implementa Looker las optimizaciones Para obtener más información, consulta la sección Se aplican las definiciones en esta página.

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; cada paso anula el anterior en caso de conflictos:

  1. Valores del extends especificado en el objeto
  2. Valores de extends especificados en mejoras del objeto
  3. Valores del objeto
  4. Valores de las mejoras del objeto

A modo de ejemplo, a continuación se muestra un ejemplo que sigue 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 de orders en este ejemplo:

  1. Valores de extends especificados en el objeto. Dado que la exploración de orders tiene un parámetro extends, Looker comienza con los elementos de LookML del objeto que se está extendiendo, que en este caso es la de Explorar orders_base. En este punto, el valor label es "Orders Base".
  2. Valores de extends especificados en mejoras del objeto. Dado que orders tiene un perfeccionamiento, y el perfeccionamiento tiene un parámetro extends, Looker aplica elementos de LookML desde la extensión del perfeccionamiento, que en este caso es el de users_base. En este punto, el valor label es "Usuarios base".
  3. Valores del objeto. Ahora que se abordaron todas las extensiones, Looker aplica elementos del objeto que se extiende, que en este caso es orders Explore. Si hay algún conflicto, ganará el objeto extendido. Por lo tanto, el valor de label es "Pedidos".
  4. Valores de las mejoras del objeto. Por último, Looker aplica elementos de cualquier mejora de orders Explore. Si hay algún conflicto, ganará el objeto de refinamiento. Por lo tanto, el valor de label es "Pedidos refinados".

El extends de la definición es aditivo

Como se describe en la sección Anulación de los parámetros de anulación, en la 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 una mejora, el valor del parámetro extends se agrega a la lista de elementos extendidos en el objeto original o en mejoras anteriores, si las hubiera. Luego, si hay algún conflicto, se le da prioridad al último elemento de la cadena de extensiones.

Por ejemplo, aquí hay una exploración base llamada orders_base y una exploración orders que extiende la base. Además, hay un users_base de exploración y el perfeccionamiento +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 el orders_base; luego, las mejoras de +orders agregan el users_base a la lista de extends. El resultado es que la exploración de +orders ahora extenderá orders_base y users_base, como si fuera el LookML original para Explorar:

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 en orders_base.

El concepto de extender más de un objeto a la vez se analiza en la página de documentación Reutilización del 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 cambios es importante. Como se describe en la sección Las mejoras se aplican en orden de esta página, la última mejora de un archivo anula las anteriores.

Cómo definir mejor tu proyecto de LookML

Estos son los pasos generales para definir mejor las vistas y exploraciones en tu proyecto:

  1. Identifica la vista o la exploración que quieres definir mejor.
  2. Decide dónde quieres guardar las mejoras. Puedes agregar mejoras en cualquier archivo LookML existente o puedes crear archivos LookML independientes para tus definiciones. (Consulta el procedimiento para crear un archivo de prueba de datos en la página de documentación Comprende otros archivos del proyecto a fin de ver un ejemplo de cómo crear archivos genéricos de LookML).
  3. Usa el parámetro include para incorporar las mejoras a tu modelo:
    • En el archivo en el que escribes tus mejoras, 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 tu archivo de modelo, incluye los archivos en los que están definidos tus mejoras. Puedes combinar archivos y usar inclusiones de formas muy creativas. Consulta la sección Cómo definir mejor para agregar capas a tu modelo en esta página a fin de obtener más información.

Ejemplo

Definir mejor los objetos LookML es una forma fácil de adaptar las vistas y Exploras sin tener que editar el LookML original. Esto es muy útil cuando tus vistas y exploraciones son de solo lectura en tu proyecto, como sucede 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 exploración contiene varias vistas, cada una de las cuales tiene muchas dimensiones.

Ahora, otro proyecto de LookML llamado e_faa_refined importa el archivo Explorar aircraft. En el proyecto e_faa_refined, puedes usar un perfeccionamiento para simplificar drásticamente la exploración de aircraft.

Debido a que aircraft es un archivo importado, no puedes editarlo directamente. En su lugar, puedes definir mejor la búsqueda. 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 ingresar el archivo aircraft.explore.lkml original del proyecto importado (consulta la página de documentación Importa archivos de otros proyectos a fin de obtener detalles sobre cómo hacer referencia a archivos de proyectos importados)
  • Perfeccionamientos de aircraft Explore:
    • El signo + delante del nombre de Explorar indica que se debe definir mejor una exploración existente.
    • El parámetro label cambia la etiqueta de Explorar a "Avión simplificada".
    • El parámetro fields especifica que solo se mostrarán tres campos en Explorar.

El resultado final es como si esta fuese la vista original aircraft Explorar y 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
  }
}

Si deseas ver un ejemplo de cómo definir mejor una sola vista para casos de uso múltiples, consulta la receta de la guía de soluciones Maximizar la reutilización de código con DRY LookML: Cómo personalizar una sola vista base para varios casos de uso.

Otros casos de uso para el perfeccionamiento

Como se mencionó antes, las mejoras son ideales para adaptar objetos LookML que son de solo lectura, como Blocks Blocks o archivos importados.

Sin embargo, una vez que se acostumbre a agregar mejoras a su modelo y a incluirlo en sus modelos, puede hacer cosas geniales con sus proyectos, como se describe en los siguientes ejemplos.

Cómo usar mejoras para agregar 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 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 un perfeccionamiento de la exploración flights existente del archivo faa_basic.lkml que une la tabla derivada distance_stats a 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 para agregar a su modelo

Otro caso de uso interesante para las mejoras es agregar capas al proyecto. Puede crear varios archivos de mejoras y, luego, incluirlos de manera estratégica 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 de 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 nueva capa con mejoras básicas, 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 nueva capa con análisis (consulta la subsección Cómo definir mejor para agregar análisis si quieres ver un ejemplo de un archivo de análisis).

A partir de ahí, solo debe incluir todos los archivos de mejoras en el archivo del modelo. También puedes usar el archivo de modelo para agregar mejoras a fin de apuntar tus vistas a las tablas de la 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;;
}

Puede duplicar este archivo de modelo y apuntar a diferentes tablas de base de datos, o puede incluir diferentes archivos de definición que haya creado para definir otras capas que desee en su modelo.

Cómo definir mejor las PDT

Como se describe en la sección Mejoras en comparación con 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 debe usar extensiones, ya que cada extensión de PDT creará una copia nueva de la tabla en la base de datos.

Sin embargo, puede agregar mejoras a la vista de la PDT, ya que estas 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 las mejoras en el 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 las reglas de localización también se aplican a él. Si estás definiendo mejor un objeto y, luego, definiendo etiquetas o descripciones nuevas, debes proporcionar definiciones de localización en los archivos de strings de configuración regional del proyecto. Consulta la página de documentación Localiza tu modelo de LookML para obtener más información.