Personaliza los bloques de Looker

En esta página, se proporciona una descripción general de las prácticas recomendadas y los ejemplos para adaptar los siguientes bloques de Looker de Framework de Cortex a tus requisitos comerciales específicos:

• Bloque de Looker para EBS de Oracle
• Bloque de Looker para Meta
• Bloque de Looker para YouTube (con DV360)

Instalación

Puedes instalar los bloques de Looker de Cortex Framework de varias maneras, como se detalla en la documentación sobre cómo implementar bloques de Looker. Sin embargo, te recomendamos crear una bifurcación del repositorio como el método más sencillo para personalizar los bloques para que se adapten a las necesidades de tu empresa.

Los bloques de Looker del Framework de Cortex se crearon en un enfoque en capas en el que cada capa agrega una lógica incremental a la capa anterior:

• Capa base: Son vistas de LookML generadas por máquinas que hacen referencia a tablas de origen.
• Capa principal: Son cambios escritos a mano que agregan campos nuevos o modifican los campos de la capa base.
• Capa lógica: Explora las definiciones y las combinaciones en diferentes vistas.

El uso de perfeccionamientos es clave para este enfoque en capas y para la personalización. Y para seguir el principio DRY (Don't Repeat Yourself), se aprovechan las extensiones y las constantes. El contenido dinámico para las etiquetas, las instrucciones SQL, el html y las propiedades de vínculo se genera con el lenguaje de plantillas Liquid.

Prácticas recomendadas generales de Google:

• Organiza tu código LookML en capas (Google)
• Modelado de embudo (Comunidad de Google)

Organización de archivos y carpetas

Dentro del bloque de Looker, cada carpeta representa una colección de tipos de objetos (como vistas, exploraciones, paneles y otros). Y cada objeto individual se define en un archivo independiente. La raíz del proyecto contiene los siguientes archivos clave:

• Archivo .model
• Archivo de manifiesto
• Archivos README y otros archivos Markdown
• Archivos de Marketplace (si el bloque también está disponible en el mercado de Looker)

Figura 1. Ejemplo de organización de carpetas dentro del bloque de Looker.

Modelo

La administración de archivos modulares hace que el archivo model del proyecto sea más liviano con los siguientes parámetros:

1. conexión

2. include

   Los tipos de archivos incluidos son los siguientes:

   • Componentes (datagroups, named_value_formats cuando corresponda)
   • Exploraciones (las exploraciones no se definen en el archivo del modelo)
   • Paneles

Las sentencias include para las vistas que se usan en el bloque se definen dentro de cada archivo de exploración individual, en lugar de en esta ubicación, como se muestra en el siguiente ejemplo:

connection: "@{CONNECTION_NAME}"

include: "/components/**/*.lkml"
include: "/explores/**/*.explore"
include: "/dashboards/**/*.dashboard"

Manifiesto

En el archivo de manifiesto, se especifican las constantes a las que se hace referencia en todo un proyecto. Estos son algunos ejemplos de las constantes que se usan para nuestros bloques:

• Nombre de la conexión
• ID del proyecto
• Conjunto de datos de informes

Los bloques de Looker de Cortex Framework también usan constantes para definir lo siguiente:

• Ver etiquetas
• Etiquetas de campo
• Formatos HTML
• Vínculos de URL
• Nombres de los paneles

Revisa las constantes definidas para el bloque de Looker y modifica cualquiera de los valores para que coincidan con tus necesidades. Los cambios se aplican en cualquier lugar al que se haga referencia a la constante.

Atributos de usuario

Algunos de los bloques de Looker requieren que un administrador defina los atributos del usuario en la instancia de Looker. Estos atributos del usuario para el idioma o la moneda predeterminados te permiten personalizar la forma en que se muestran los paneles por usuario o grupo. Consulta la descripción general de cada bloque para obtener más información sobre los atributos de usuario obligatorios.

Vistas

Las vistas que se encuentran en la carpeta Base son aquellas que se generan automáticamente con la opción Crear vista a partir de una tabla. Estos archivos se modificaron de forma mínima:

• Se reemplazaron el ID del proyecto y el nombre del conjunto de datos por constantes.
• Se movieron las vistas basadas en registros anidados a archivos separados.
• Se quitaron las definiciones de campos de desglose innecesarias.

Se realizaron modificaciones significativas en estas vistas, como etiquetas, dimensiones y medidas nuevas, en la carpeta Core con definiciones más precisas, extensiones o tablas derivadas.

Dentro de la carpeta principal, las vistas se nombran con un sufijo que indica el tipo de vista:

• _rfn para definir mejor.
• _ext para la vista que requiere una extensión.
• _sdt para la tabla derivada basada en SQL.
• _ndt para la tabla derivada nativa
• _pdt para la tabla derivada persistente.
• _xvw para ver campos de referencia de varias vistas.

Figura 2: Ejemplo de sufijo que indica el tipo de vista.

Cada definición de vista comienza con anotaciones que proporcionan información de fondo, como descripciones, fuentes, referencias, campos extendidos y otras notas relevantes.

Figura 3. Ejemplos de anotaciones dentro de una definición de vista.

Registros repetidos anidados

En el caso de las tablas subyacentes que contienen registros repetidos anidados, Looker crea vistas independientes para desanidar estos registros. Por ejemplo, en el bloque Oracle EBS Looker, la tabla sales_orders tiene una estructura repetida anidada llamada lines. Looker las trata como dos vistas distintas: sales_orders y sales_orders__lines.

Para unir estos registros no anidados en Explorar, debes definir la unión con la propiedad sql junto con el comando UNNEST.

Figura 4. Ejemplo de unión con la propiedad "sql" junto con el comando UNNEST.

Para obtener más información, consulta Cómo modelar datos anidados de BigQuery en Looker.

Cómo navegar y comprender el código de bloque de Looker

Los bloques de Looker de Cortex Framework contienen comentarios extensos en las vistas y otros objetos. Para mejorar la navegación y la comprensión del código, se recomienda usar la opción Fold LookML disponible en el entorno de desarrollo de LookML.

Figura 5. Hacer clic en Doblar LookML.

Figura 6. Haz clic para desplegar el código LookML.

Figura 7: Haz clic para volver a contraer el modelo de LookML.

Campos

El término field se refiere a objetos como dimension, measure, filter o parameter. Dentro de estos bloques más nuevos, seguimos estos principios:

1. Las dimensiones se nombran con snake_case (minúsculas y guiones bajos entre las palabras). Por ejemplo: customer_name.
2. Los nombres de las columnas de las tablas subyacentes se usan para nombrar las dimensiones. Las etiquetas se pueden aplicar a las dimensiones para proporcionarles un nombre fácil de usar para la empresa. Por ejemplo, una dimensión llamada division_hdr_spart puede etiquetarse como "ID de división".
3. En el caso de las tablas con muchas columnas, los campos se ocultan de forma predeterminada. Con una mejora de la vista, establece la propiedad hidden en "no" para que el subconjunto de campos se muestre en una exploración. Si un campo no aparece como se esperaba, puedes editar esta propiedad para resolver el problema.
4. Las propiedades View_label y group_label se usan para organizar campos dentro de una exploración, cuando corresponda.
5. En el caso de los campos que se utilizan en varias vistas, las propiedades como la etiqueta se establecen dentro de una vista "común", que luego se extiende a otras vistas. Este enfoque centraliza la definición de la propiedad y promueve la reutilización. Las modificaciones necesarias se administran dentro de la vista "común", lo que garantiza que los cambios se reflejen en todas las vistas en las que se extiende la vista "común".
6. Los parámetros que se usan en varios Explorar o campos que hacen referencia a varias vistas se definen en una vista de solo campo con el sufijo _xvw. Para obtener más información, consulta Cómo evitar inconsistencias entre las exploraciones.

Ejemplos de edición

En esta sección, se proporcionan ejemplos de personalizaciones comunes.

Cómo mostrar un campo

La vista base abarca todas las dimensiones de una tabla subyacente. Cuando la mayoría de las dimensiones no necesitan ser visibles, se usa un perfeccionamiento para ocultar todos los campos de forma predeterminada. Para ello, se debe configurar la propiedad fields_hidden_by_default como "yes". Se desocultó el subconjunto de campos relevantes para los paneles de LookML incluidos. En el siguiente ejemplo, se considera una vista base llamada sales_orders con una dimensión llamada item_posnr.

view: sales_order {
  sql_table_name: reporting.sales_order ;;

  dimension: item_posnr {
    type: string
    sql: ${TABLE}.Item_POSNR
  }
}

La definición detallada de esta vista se define en el archivo con el sufijo _rfn. La definición más precisa configura la propiedad de vista fields_hidden_by_default en "sí", lo que significa que todos los campos están ocultos inicialmente. Para mostrar el campo item_posnr en la vista, establece la propiedad oculta en "no".

view: +sales_order {
   fields_hidden_by_default: yes

   dimension: item_posnr {
     hidden: no
   }
}

Cómo cambiar la etiqueta de la vista de parámetros

Varios bloques de Looker usan un conjunto compartido de parámetros definidos dentro de un archivo independiente. Por ejemplo, el bloque EBS de Oracle usa el archivo otc_common_parameters_xvw. Esta vista muestra la etiqueta "🔍 Filtros", que se define como una constante dentro del archivo de manifiesto.

Para modificar esta etiqueta, haz lo siguiente:

1. Ubica la constante label_view_for_filters en el archivo de manifiesto.
2. Edita el valor de la constante a la etiqueta que elegiste.
3. Guarda el archivo de manifiesto. El cambio se reflejará automáticamente en cualquier lugar donde se haga referencia a la constante label_view_for_filters.

Manifest

constant: label_view_for_filters {
  value: "My Filters"
}

Como alternativa, navega a la vista otc_common_parameters_xvw y edita la propiedad "label" al valor elegido.

view: otc_common_parameters_xvw {
  label: "My Filters"
}

Agrega una medición nueva

Se pueden agregar nuevas medidas directamente a la definición más precisa relevante. En el siguiente ejemplo, se muestra una nueva medida agregada al perfeccionamiento de los pedidos de venta:

view: +sales_orders {

  measure: customer_count {
    type: count_distinct
    sql: ${customer_id}
   }
}

Cómo agregar una segunda capa de refinamiento

Los nuevos refinamientos se pueden basar en los existentes. Considera la definición más precisa de sales_orders en el archivo sales_orders_rfn.view, que crea la medición average_sales, como en el siguiente ejemplo:

include: "/views/base/sales_orders"
view: +sales_orders {
  measure: average_sales {
    type: average
    sql: ${order_value}
  }
}

Para crear un segundo archivo de perfeccionamiento, sigue estos pasos:

1. Crea un nuevo archivo de perfeccionamiento: Asóciale el nombre sales_orders_rfn2.view.
2. Incluir el primer archivo de perfeccionamiento: Esto incorporará todas las definiciones de sales_orders_rfn en sales_orders_rfn2.
3. Edita la propiedad de la etiqueta: Cambia la propiedad label de average_sales a "inversión promedio" o a cualquier otra etiqueta que elijas.

4. Agrega una dimensión nueva: Incluye el código de la dimensión nueva en el archivo sales_orders_rfn2.view.

   include: "/views/core/sales_orders_rfn.view"
   view: +sales_orders {
   
     measure: average_sales {
       label: "Average Spend"
     }
   
     dimension: customer_name_with_id {
       type: string
       sql: CONCAT(${customer_id},' ',${customer_name})
     }
   }
   

5. Incluir segundo archivo de perfeccionamiento en Explorar: Esto incorporará todas las definiciones y mejoras de sales_orders_rfn2 en Explorar.

   include: "/views/core/sales_orders_rfn2.view"
   explore: sales_orders {
   }
   

Cómo crear una nueva capa de refinamiento

El perfeccionamiento de cualquier vista base definida dentro del bloque de buscador de Framework de Cortex se puede reemplazar si no cumple con tus requisitos específicos. El archivo _rfn se puede editar directamente para quitar definiciones de campo innecesarias o agregar otras nuevas.

Como alternativa, crea un nuevo archivo de perfeccionamiento:

1. Crea un nuevo archivo de perfeccionamiento: Asóciale el nombre sales_invoices_rfn y guárdalo.
2. Incluye la vista base: Esto incorporará todas las definiciones de la vista base sales_invoices en sales_invoices_rfn.

3. Agrega las personalizaciones elegidas: Asegúrate de definir una dimensión como clave primaria.

   include: "/views/base/sales_invoices.view"
   
   view: +sales_invoices {
   
     fields_hidden_by_default: yes
   
     dimension: invoice_id {
       hidden: no
       primary_key: yes
       value_format_name: id
     }
   
     dimension: business_unit_name {
       hidden: no
       sql: CONCAT(${business_unit_id}, ":",${TABLE}.BUSINESS_UNIT_NAME) ;;
     }
   }
   

4. Incluye la nueva definición en Explorar: Usa el archivo nuevo en la propiedad include en lugar de la definición proporcionada en el bloque Looker de Framework de Cortex.

   include: "/views/my_customizations/sales_invoices_rfn.view"
   
   explore: sales_invoices {
   }
   

Cómo editar los filtros del panel de LookML

El conjunto común de filtros de panel que se usa en varios paneles de LookML se define en un panel con el sufijo _template y se extiende a cada panel. Una vez extendidos, los objetos de filtro se pueden modificar según sea necesario para un panel específico.

Edición para todos los paneles

Para cambiar el tipo de filtro de todos los paneles, busca el archivo de plantilla que define el filtro. Edita el tipo ui_config y muestra las propiedades en la configuración elegida. Este cambio se aplicará a todos los paneles que extiendan la plantilla. El siguiente es un ejemplo de otc_template.dashboard:

- dashboard: otc_template
  extension: required

  filters:
  - name: customer_country
    title: "Sold to Customer: Country"
    type: field_filter
    default_value: ''
    allow_multiple_values: true
    required: false
    ui_config:
      type: dropdown_menu
      display: popover
    explore: countries_md
    field: countries_md.country_name_landx

Edición de un panel específico

Para modificar un filtro en un panel específico, busca el archivo del panel y incluye el nombre del filtro junto con las propiedades seleccionadas que requieren modificación. Este cambio se limitará al panel único. Por ejemplo, para cambiar el título, el tipo de IU y la visualización del filtro customer_country para otc_order_status.dashboard, solo se incluirían estas propiedades en el archivo del panel. Las propiedades restantes se heredarían de la plantilla extendida.

- dashboard: otc_order_status
  title: Order Status
  extends: otc_template

  filters:
  - name: customer_country
    title: "Customer Country"
    ui_config:
      type: dropdown_menu
      display: inline

Para obtener más información sobre cómo crear y modificar paneles de LookML, consulta Cómo crear paneles de LookML.