Optimiza el rendimiento de Looker

Estas prácticas recomendadas reflejan las recomendaciones que compartió un equipo multidisciplinario de Lookers experimentados. Estas estadísticas provienen de años de experiencia trabajando con clientes de Looker, desde la implementación hasta el éxito a largo plazo. Las prácticas se escriben para que funcionen en la mayoría de los usuarios y las situaciones, pero debes usar tu mejor criterio cuando las implementes.

Optimiza el rendimiento de las consultas

Puedes asegurarte de que las consultas se compilen y ejecuten de forma óptima en tu base de datos con las siguientes sugerencias para el frontend y el backend:

• Crea exploraciones con uniones many_to_one siempre que sea posible. Cuando se unen vistas desde el nivel de detalle más particular hasta el más general (many_to_one), se suele obtener el mejor rendimiento de las consultas.
• Maximiza el almacenamiento en caché para sincronizarlo con tus políticas de ETL siempre que sea posible para reducir el tráfico de las consultas de bases de datos. De forma predeterminada, Looker almacena en caché las consultas durante una hora. Puedes controlar la política de almacenamiento en caché y sincronizar las actualizaciones de datos de Looker con tu proceso de ETL aplicando grupos de datos en las exploraciones con el parámetro persist_with. Esta opción permite que Looker se integre más estrechamente con la canalización de datos de backend para que el uso de la caché se pueda maximizar sin el riesgo de analizar datos obsoletos. Las políticas de almacenamiento en caché con nombre se pueden aplicar a un modelo completo o a exploraciones y tablas derivadas persistentes (PDT) individuales.
• Usa la funcionalidad de reconocimiento de agregaciones de Looker para crear tablas de resumen o integraciones que Looker pueda usar para las consultas siempre que sea posible, en especial para las consultas comunes de bases de datos grandes. También puedes aprovechar el reconocimiento de agregaciones para mejorar drásticamente el rendimiento de paneles completos. Consulta el instructivo de reconocimiento de agregados para obtener más información.
• Usa PDT para realizar consultas más rápidas. Convierte las exploraciones con muchas uniones complejas o de bajo rendimiento, o las dimensiones con subconsultas o subselecciones, en PDT para que las vistas se unan previamente y estén listas antes del tiempo de ejecución.
• Si el dialecto de tu base de datos admite PDT incrementales, configura PDT incrementales para reducir el tiempo que Looker dedica a volver a compilar PDT.
• Evita unir vistas en exploraciones en claves primarias concatenadas que se definen en Looker. En su lugar, únelos en los campos base que conforman la clave primaria concatenada de la vista. Como alternativa, vuelve a crear la vista como una PDT con la clave primaria concatenada predefinida en la definición de SQL de la tabla, en lugar de en el LookML de una vista.
• Usa la herramienta Explicar en el Ejecutor de SQL para realizar comparativas. EXPLAIN produce una descripción general del plan de ejecución de consultas de tu base de datos para una consulta en SQL determinada, lo que te permite detectar componentes de consulta que se pueden optimizar. Obtén más información en la publicación de Comunidad Cómo optimizar SQL con EXPLAIN.
• Declarar índices Puedes consultar los índices de cada tabla directamente en Looker desde el Ejecutor de SQL. Para ello, haz clic en el ícono de ajustes de una tabla y, luego, selecciona Mostrar índices.
  Las columnas más comunes que pueden beneficiarse de los índices son las fechas importantes y las claves externas. Agregar índices a estas columnas aumentará el rendimiento de casi todas las consultas. Esto también se aplica a las PDT. Los parámetros de LookML, como indexes, sort keys y distribution, se pueden aplicar de forma adecuada.
• Aumenta la memoria, los núcleos y la E/S (entrada/salida) de las bases de datos con hardware insuficiente o recursos aprovisionados necesarios (como AWS) para procesar conjuntos de datos grandes, con el objetivo de aumentar el rendimiento de las consultas.

Optimiza el rendimiento del servidor de Looker

También puedes tomar medidas para asegurarte de que el servidor y la aplicación de Looker funcionen de manera óptima:

• Limita la cantidad de elementos dentro de un panel individual. No existe una regla precisa para definir la cantidad, ya que el diseño de cada elemento afecta el consumo de memoria en función de diversos factores. Sin embargo, los paneles con 25 o más tarjetas suelen tener problemas de rendimiento.
• Usa la función de actualización automática del panel de forma estratégica. Si un panel usa la actualización automática, asegúrate de que no se actualice más rápido que los procesos de ETL que se ejecutan en segundo plano.
• Usa las tablas dinámicas de forma estratégica y evita usarlas en exceso en las tarjetas de los paneles y en las vistas. Las consultas con dimensiones dinámicas consumirán más memoria. Cuantas más dimensiones se dinamizan, más memoria se consume cuando se carga el contenido (una exploración, una vista o un panel).
• Usa funciones como campos personalizados y cálculos basados en tablas con moderación. Estas funciones están diseñadas para usarse como pruebas de concepto que te ayuden a diseñar tu modelo. La práctica recomendada es codificar de forma fija los cálculos y las funciones que se usan con frecuencia en LookML, lo que generará SQL para procesar en tu base de datos. Los cálculos excesivos pueden competir por la memoria de Java en la instancia de Looker, lo que hace que esta responda con mayor lentitud.
• Para las consultas de resultados combinados, usa consultas de combinación en la base de datos siempre que sea posible. Las consultas de combinación en la base de datos se procesan en tu base de datos, en lugar de en la memoria de Looker.
• Limitar la cantidad de vistas incluidas en un modelo cuando hay una gran cantidad de archivos de vista Incluir todas las vistas en un solo modelo puede ralentizar el rendimiento. Cuando hay una gran cantidad de vistas en un proyecto, considera incluir solo los archivos de vista que se necesitan en cada modelo. Considera usar convenciones de nomenclatura estratégicas para los nombres de los archivos de vista, de modo que se puedan incluir grupos de vistas dentro de un modelo. Se describe un ejemplo en la documentación del parámetro includes.
• Evita que se devuelva una gran cantidad de datos de forma predeterminada en las tarjetas de los paneles y en las vistas. Las consultas que devuelven miles de datos consumirán más memoria. Asegúrate de que los datos estén limitados siempre que sea posible aplicando filtros de frontend a los paneles, las vistas y las exploraciones, y en el nivel de LookML con los parámetros required filters, conditionally_filter y sql_always_where.
• Descarga o entrega consultas con la opción Todos los resultados con moderación, ya que algunas consultas pueden ser muy grandes y sobrecargar el servidor de Looker cuando se procesan.
• Comprender el impacto del rendimiento de la conexión en toda la instancia de Looker Looker usa recursos compartidos para procesar consultas de todas las conexiones de bases de datos. Estos recursos incluyen pods de Kubernetes, colas de consultas y grupos de subprocesos. Debido a esta infraestructura compartida, una sola conexión de base de datos lenta o sobrecargada puede afectar negativamente el rendimiento de las consultas en todas las demás conexiones. Si notas una degradación generalizada del rendimiento, investiga el estado de todas las conexiones de la base de datos, no solo las que están directamente relacionadas con los paneles o las exploraciones lentas.
• Distribuye las entregas programadas y evita la ejecución simultánea de trabajos. Cuando se programan varios Looks o paneles para que se ejecuten exactamente en el mismo minuto (en particular, al comienzo de la hora), la ráfaga repentina de solicitudes de consultas simultáneas puede sobrecargar los recursos de la instancia, aumentar la profundidad de la cola y agotar los grupos de conexiones de la base de datos. Este cuello de botella de simultaneidad puede hacer que las entregas programadas y las consultas interactivas de Explorar se detengan durante la fase de inicialización de la consulta. Usa las siguientes estrategias para evitar cuellos de botella de simultaneidad:
  • Escalona los trabajos programados en intervalos de 15 o 30 minutos (o en minutos que no sean al comienzo de la hora, como :15, :30 o :45) en lugar de programar todas las entregas al comienzo de la hora.
  • Siempre que sea posible, usa grupos de datos para activar entregas que se basen en la finalización de ETL en lugar de programaciones basadas en el tiempo, lo que evita consultas innecesarias en datos no actualizados.
  • Agrupa por lotes o limita las secuencias de comandos externas y las llamadas a la API automatizadas que ejecutan consultas o activan entregas.
  • Si una ráfaga repentina de consultas hace que tu instancia deje de responder o que las consultas se ejecuten de forma indefinida, puedes borrar las tareas en proceso reiniciando la instancia (consulta Reinicia una instancia de Looker (Google Cloud Core) para las instancias de Looker (Google Cloud Core)).

Para obtener más ayuda para identificar el origen de los problemas de rendimiento, consulta la página de prácticas recomendadas de la Descripción general del rendimiento.