Práctica recomendada: escribir código LookML sostenible y fácil de mantener

Estas prácticas recomendadas reflejan las sugerencias de un equipo multidisciplinar de Lookers experimentados. Estas estadísticas se han obtenido a lo largo de años de experiencia trabajando con clientes de Looker, desde la implementación hasta el éxito a largo plazo. Estas prácticas están pensadas para la mayoría de los usuarios y las situaciones, pero, como siempre, le recomendamos que aplique su mejor criterio a la hora de implementar las sugerencias de esta página.

En esta página se ofrecen recomendaciones para escribir código LookML sostenible y fácil de mantener. Estas recomendaciones se describen con más detalle en las siguientes secciones:

Usar operadores de sustitución

Los operadores de sustitución se deben usar en todos los archivos LookML. Un modelo de LookML solo debe tener un punto de referencia para cualquier objeto del modelo de datos físico. Las definiciones posteriores que necesiten hacer referencia a ese objeto deben hacerlo apuntando al objeto LookML ya definido.

Usa la sintaxis ${TABLE}.field_name cuando hagas referencia a la tabla de la base de datos subyacente para todas las dimensiones base que extraigan datos directamente de las columnas de la base de datos subyacente. Si cambia el nombre de un esquema o de una tabla, el desarrollador puede actualizarlo en un solo lugar (en el parámetro sql_table_name) y se propagará al resto del código.

Usa la sintaxis ${field_name} cuando hagas referencia a dimensiones o medidas que ya se hayan definido en LookML. Si cambia el nombre de una columna, solo tendrá que actualizarlo en el parámetro sql de la dimensión o las métricas base. Ese cambio se propagará automáticamente a todos los demás campos que hagan referencia a la columna. Por ejemplo, si el nombre de una columna de tu base de datos cambia de usersid a users_id, tendrás que cambiar la referencia en Looker. Si usas ${field_name}, solo tienes que actualizar una línea.

Cuando varias dimensiones y medidas hacen referencia a un campo de LookML con ${TABLE}.field_name, es necesario hacer muchos cambios. Por ejemplo, considere las medidas this_week_count y this_month_count en el siguiente código de LookML:

dimension: usersid {
  type: number
  sql: ${TABLE}.usersid ;; # Change here
}

measure: this_week_count {
  type: count_distinct
  sql: ${TABLE}.usersid ;; # Change here
  filters: [created_date: "7 days"]
}

measure: this_month_count {
  type: count_distinct
  sql: ${TABLE}.usersid ;; # Change here
  filters: [created_date: "1 month"]
}

Como tanto this_week_count como this_month_count usan la sintaxis ${TABLE}.usersid en el parámetro sql, será necesario actualizar el parámetro sql de los tres campos.

Con la referencia ${field_name}, solo hay que hacer un cambio:

dimension: usersid {
  type: number
  sql: ${TABLE}.usersid ;; # Change here
}

measure: this_week_count {
  type: count_distinct
  sql: ${usersid} ;;       #Using ${field_name} to reference the LookML field `usersid`
  filters: [created_date: "7 days"]
}

measure: this_month_count {
  type: count_distinct
  sql: ${usersid} ;;       #Using ${field_name} to reference the LookML field `usersid`
  filters: [created_date: "1 month"]
}

Para ver más usos de los operadores de sustitución, consulta nuestra página de documentación Incorporar SQL y hacer referencia a objetos LookML.

Definir conjuntos de campos

Usa conjuntos para mantener listas de campos reutilizables en el modelo. Las listas de campos que se repitan, ya sea con el parámetro fields o en los campos de desglose, deben incorporarse a conjuntos para crear un único lugar en el modelo donde se pueda actualizar esa lista de campos o se puedan cambiar las referencias de los campos. Puede consultar más información sobre los conjuntos en la página de documentación del parámetro set.

Evitar repetir código

Piensa en los objetos de LookML como bloques de creación y usa el parámetro extends para combinar objetos de diferentes formas sin repetir código. Puede consultar información detallada y ejemplos sobre cómo reutilizar código en la página de documentación Reutilizar código con extends. Puedes ver más ejemplos en las páginas de documentación de los parámetros extends (para vistas) y extends (para Exploraciones), así como en la publicación de la comunidad Usar extensiones para definir uniones.

Mantener la coherencia en las exploraciones sin repetir código en varios lugares. Para obtener más ideas sobre cómo hacerlo, consulta la publicación de la comunidad de Looker sobre cómo evitar incoherencias en las Exploraciones.

Consolidar elementos como capas de mapa y formatos de valor

Define capas de mapa personalizadas de forma centralizada en un archivo LookML llamado map_layers.lkml, que puedes crear siguiendo la documentación de Looker sobre archivos de proyecto. Este archivo se puede incluir según sea necesario en los modelos. También puede añadir archivos JSON directamente al repositorio arrastrando y soltando archivos de datos en su proyecto de LookML y haciendo referencia a ellos en el modelo.

Por ejemplo, supongamos que tiene un archivo de capas de mapa, map_layers.base.lkml, que contiene el siguiente código LookML:

map_layer: example_africa {
  file: "africa_file_name.json"
  property_key: "geounit"
}

map_layer: example_asia {
  file: "asia_file_name.json"
  property_key: "geounit"
}

map_layer: example_europe {
  file: "europe_file_name.json"
  property_key: "geounit"
}

Puede incluir el archivo de capas del mapa map_layers.base.lkml en cualquier modelo del proyecto añadiendo el código LookML include: "map_layers.base.lkml" al archivo de modelo que quiera.

Definir formatos de valor personalizado de forma centralizada en el modelo. Usa el parámetro named_value_format para definir cualquier formato personalizado en el modelo y, a continuación, haz referencia a él con el parámetro value_format_name en las dimensiones y las medidas.

Crear directrices de desarrollo

Define directrices de desarrollo para facilitar el desarrollo y la escalabilidad de un modelo de LookML. Consulta la publicación de la comunidad de Looker sobre las directrices de desarrollo de LookML de ejemplo para ver una guía de una lista de directrices de desarrollo de ejemplo. Entre las directrices habituales se incluyen los requisitos de:

  • Organizar los archivos LookML de forma clara para que sean coherentes y fáciles de usar
  • Usar comentarios en las vistas y los modelos para añadir contexto al LookML escrito
  • Crear documentación en Looker con archivos Markdown