Consultar estadísticas de rendimiento de las consultas

El gráfico de ejecución de una consulta es una representación visual de los pasos que sigue BigQuery para ejecutarla. En este documento se describe cómo usar el gráfico de ejecución de consultas para diagnosticar problemas y ver estadísticas del rendimiento de las consultas.

BigQuery ofrece un rendimiento de las consultas excelente, pero también es un sistema distribuido complejo con muchos factores internos y externos que pueden afectar a la velocidad de las consultas. La naturaleza declarativa de SQL también puede ocultar la complejidad de la ejecución de consultas. Esto significa que, cuando tus consultas se ejecutan más lentamente de lo previsto o más lentamente que en ejecuciones anteriores, puede ser difícil entender qué ha ocurrido.

El gráfico de ejecución de consultas proporciona una interfaz gráfica dinámica para inspeccionar el plan de consultas y los detalles del rendimiento de las consultas. Puedes consultar el gráfico de ejecución de consultas de cualquier consulta en curso o completada.

También puedes usar el gráfico de ejecución de consultas para obtener estadísticas sobre el rendimiento de las consultas. Las estadísticas de rendimiento proporcionan sugerencias para ayudarte a mejorar el rendimiento de las consultas. Como el rendimiento de las consultas tiene muchas facetas, las estadísticas de rendimiento solo pueden ofrecer una imagen parcial del rendimiento general de las consultas.

Permisos obligatorios

Para usar el gráfico de ejecución de consultas, debes tener los siguientes permisos:

• bigquery.jobs.get
• bigquery.jobs.listAll

Estos permisos están disponibles a través de los siguientes roles predefinidos de gestión de identidades y accesos (IAM) de BigQuery:

• roles/bigquery.admin
• roles/bigquery.resourceAdmin
• roles/bigquery.resourceEditor
• roles/bigquery.resourceViewer

Estructura del gráfico de ejecución

El gráfico de ejecución de consultas ofrece una vista gráfica del plan de consultas en la consola. Cada cuadro representa una fase del plan de consulta, como las siguientes:

• Entrada: leer datos de una tabla o seleccionar columnas específicas
• Unión: combina datos de dos tablas en función de la condición JOIN
• Agregación: realiza cálculos como SUM.
• Ordenar: ordenar los resultados

Las fases se componen de pasos que describen las operaciones individuales que ejecuta cada trabajador en una fase. Puedes hacer clic en una fase para abrirla y ver sus pasos. Las fases también incluyen información sobre la hora relativa y absoluta. Los nombres de las fases resumen los pasos que realizan. Por ejemplo, una fase con join en su nombre significa que el paso principal de la fase es una operación JOIN. Los nombres de las fases que terminan en + significan que realizan pasos importantes adicionales. Por ejemplo, una fase con JOIN+ en su nombre significa que la fase realiza una operación de unión y otros pasos importantes.

Las líneas que conectan las fases representan el intercambio de datos intermedios entre las fases. BigQuery almacena los datos intermedios en la memoria de aleatorización mientras se ejecutan las fases. Los números de los bordes indican el número estimado de filas intercambiadas entre las fases. La cuota de memoria de barajado está relacionada con el número de ranuras asignadas a la cuenta. Si se supera la cuota de shuffle, la memoria de shuffle puede pasar al disco y provocar que el rendimiento de las consultas se ralentice considerablemente.

Ver estadísticas de rendimiento de las consultas

Consola

Sigue estos pasos para ver las estadísticas de rendimiento de las consultas:

1. Abre la página de BigQuery en la Google Cloud consola.

   Ir a la página de BigQuery

2. En el Editor, haz clic en Historial personal o en Historial del proyecto.

3. En la lista de tareas, busca la tarea de consulta que te interese. Haz clic en Acciones y elige Abrir consulta en el editor.

4. Selecciona la pestaña Gráfico de ejecución para ver una representación gráfica de cada fase de la consulta:

   

   Para determinar si una fase de la consulta tiene estadísticas de rendimiento, fíjate en el icono que muestra. Las fases que tienen un icono de información ofrecen estadísticas de rendimiento. Las fases que tienen un icono de marca de verificación no lo tienen.

5. Haga clic en una fase para abrir el panel de detalles de la fase, donde podrá ver la siguiente información:

   • Información del plan de consulta de la fase.
   • Los pasos ejecutados en la fase.
   • Las estadísticas de rendimiento aplicables.

   

6. Opcional: Si estás inspeccionando una consulta en ejecución, haz clic en Sincronizar para actualizar el gráfico de ejecución de forma que refleje el estado actual de la consulta.

   

7. Opcional: Para destacar las fases principales por duración en el gráfico, haz clic en Destacar las fases principales por duración.

   

8. Opcional: Para destacar las fases principales por tiempo de asignación utilizado en el gráfico, haz clic en Destacar las fases principales por procesamiento.

   

9. Opcional: Para incluir las fases de redistribución aleatoria en el gráfico, haz clic en Mostrar fases de redistribución aleatoria.

   

   Usa esta opción para mostrar las fases de repartición y coalescencia que están ocultas en el gráfico de ejecución predeterminado.

   Las fases de repartición y coalescencia se introducen mientras se ejecuta la consulta y se usan para mejorar la distribución de datos entre los trabajadores que procesan la consulta. Como estas fases no están relacionadas con el texto de la consulta, se ocultan para simplificar el plan de consulta que se muestra.

En el caso de las consultas que tengan problemas de regresión del rendimiento, también se mostrarán estadísticas de rendimiento en la pestaña Información del trabajo de la consulta:

SQL

1. En la Google Cloud consola, ve a la página BigQuery.

   Ir a BigQuery

2. En el editor de consultas, introduce la siguiente instrucción:

   SELECT
     `bigquery-public-data`.persistent_udfs.job_url(
       project_id || ':us.' || job_id) AS job_url,
     query_info.performance_insights
   FROM
     `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
   WHERE
     DATE(creation_time) >= CURRENT_DATE - 30 -- scan 30 days of query history
     AND job_type = 'QUERY'
     AND state = 'DONE'
     AND error_result IS NULL
     AND statement_type != 'SCRIPT'
     AND EXISTS ( -- Only include queries which had performance insights
       SELECT 1
       FROM UNNEST(
         query_info.performance_insights.stage_performance_standalone_insights
       )
       WHERE slot_contention OR insufficient_shuffle_quota
       UNION ALL
       SELECT 1
       FROM UNNEST(
         query_info.performance_insights.stage_performance_change_insights
       )
       WHERE input_data_change.records_read_diff_percentage IS NOT NULL
     );

3. Haz clic en Ejecutar.

Para obtener más información sobre cómo ejecutar consultas, consulta Ejecutar una consulta interactiva.

API

Para obtener estadísticas sobre el rendimiento de las consultas en un formato no gráfico, llama al método de la API jobs.list e inspecciona la información JobStatistics2 que se devuelve.

Interpretar las estadísticas de rendimiento de las consultas

En esta sección encontrarás más información sobre el significado de las estadísticas de rendimiento y cómo abordarlas.

Las estadísticas de rendimiento están dirigidas a dos tipos de usuarios:

• Analistas: ejecutan consultas en un proyecto. Quieres saber por qué una consulta que has ejecutado antes se está ejecutando más lentamente de lo esperado y obtener consejos sobre cómo mejorar el rendimiento de una consulta. Tienes los permisos descritos en la sección Permisos necesarios.

• Administradores de lagos de datos o almacenes de datos: gestionan los recursos y las reservas de BigQuery de su organización. Tiene los permisos asociados al rol Administrador de BigQuery.

En cada una de las siguientes secciones se explica qué puedes hacer para abordar una estadística de rendimiento que recibas, en función del rol que tengas.

Contención de ranuras

Cuando ejecutas una consulta, BigQuery intenta dividir el trabajo necesario en tareas. Una tarea es una porción de datos que se introduce y se genera en una fase. Un solo espacio recoge una tarea y ejecuta esa porción de datos de la fase. Lo ideal es que los slots de BigQuery ejecuten estas tareas en paralelo para conseguir un alto rendimiento. La contención de espacios se produce cuando tu consulta tiene muchas tareas listas para empezar a ejecutarse, pero BigQuery no puede obtener suficientes espacios disponibles para ejecutarlas.

Qué hacer si eres analista

Para reducir los datos que procesa en su consulta, siga las indicaciones que se describen en el artículo Reducir los datos procesados en las consultas.

Qué hacer si eres administrador

Para aumentar la disponibilidad de espacios o reducir el uso de espacios, sigue estos pasos:

• Si usas los precios bajo demanda de BigQuery, tus consultas usarán un grupo de ranuras compartido. Considera la posibilidad de pasarte a los precios de análisis basados en la capacidad comprando reservas. Las reservas te permiten reservar ranuras dedicadas para las consultas de tu organización.

• Si usas reservas de BigQuery, asegúrate de que haya suficientes ranuras en la reserva asignada al proyecto que ejecutó la consulta. Es posible que la reserva no tenga suficientes espacios en los siguientes casos:

  • Hay otras tareas que están consumiendo ranuras de reserva. Puedes usar los gráficos de recursos de administrador para ver cómo está usando tu organización la reserva.
  • La reserva no tiene suficientes ranuras asignadas para ejecutar las consultas con la rapidez necesaria. Puedes usar el estimador de ranuras para obtener una estimación del tamaño que deben tener tus reservas para procesar de forma eficiente las tareas de tus consultas.

  Para solucionarlo, puedes probar una de las siguientes soluciones:

  • Añade más plazas (ya sean plazas de base o plazas máximas de reserva) a esa reserva.
  • Crea una reserva adicional y asígnala al proyecto que ejecuta la consulta.
  • Espacia las consultas que consumen muchos recursos, ya sea a lo largo del tiempo en una reserva o en diferentes reservas.

• Asegúrate de que las tablas que vas a consultar estén agrupadas en clústeres. La agrupación en clústeres ayuda a BigQuery a leer rápidamente las columnas con datos correlacionados.

• Asegúrate de que las tablas que vas a consultar tengan particiones. En el caso de las tablas sin particiones, BigQuery lee toda la tabla. Crear particiones en tus tablas te ayuda a asegurarte de que solo consultas el subconjunto de tablas que te interesa.

Cuota de aleatorización insuficiente

Antes de ejecutar una consulta, BigQuery divide la lógica de la consulta en fases. Las ranuras de BigQuery ejecutan las tareas de cada fase. Cuando una ranura completa la ejecución de las tareas de una fase, almacena los resultados intermedios en shuffle. Las fases posteriores de la consulta leen datos de la aleatorización para continuar con la ejecución de la consulta. El error de cuota de aleatorización insuficiente se produce cuando tienes más datos que deben escribirse en la aleatorización de los que tienes capacidad de aleatorización.

Qué hacer si eres analista

Al igual que con la contención de ranuras, reducir la cantidad de datos que procesa tu consulta puede reducir el uso de la aleatorización. Para ello, sigue las indicaciones que se ofrecen en el artículo Reducir los datos procesados en las consultas.

Algunas operaciones de SQL tienden a hacer un uso más intensivo del aleatorio, especialmente las operaciones JOIN y las cláusulas GROUP BY. Si es posible, reducir la cantidad de datos de estas operaciones puede reducir el uso de la aleatorización.

Qué hacer si eres administrador

Para reducir la contención de la cuota de aleatorización, haz lo siguiente:

• Al igual que con la contención de ranuras, si usas los precios bajo demanda de BigQuery, tus consultas usarán un grupo de ranuras compartido. Considera la posibilidad de pasarte a los precios de análisis basados en la capacidad comprando reservas. Las reservas te proporcionan ranuras y capacidad de Shuffle dedicadas para las consultas de tus proyectos.

• Si usas reservas de BigQuery, las ranuras incluyen capacidad de aleatorización dedicada. Si tu reserva está ejecutando algunas consultas que hacen un uso intensivo de la aleatorización, es posible que otras consultas que se ejecuten en paralelo no obtengan suficiente capacidad de aleatorización. Para identificar las tareas que usan la capacidad de orden aleatorio de forma intensiva, consulta la columna period_shuffle_ram_usage_ratio de la vista INFORMATION_SCHEMA.JOBS_TIMELINE.

  Para solucionarlo, puedes probar una o varias de las siguientes soluciones:

  • Añade más plazas a esa reserva.
  • Crea una reserva adicional y asígnala al proyecto que ejecuta la consulta.
  • Espacia las consultas que requieran muchos reordenamientos, ya sea a lo largo del tiempo en una reserva o en diferentes reservas.

Cambio de escala de entrada de datos

Si recibe esta información valiosa sobre el rendimiento, significa que su consulta está leyendo al menos un 50% más de datos de una tabla de entrada determinada que la última vez que ejecutó la consulta. Puede usar el historial de cambios de la tabla para ver si el tamaño de alguna de las tablas usadas en la consulta ha aumentado recientemente.

Qué hacer si eres analista

Para reducir los datos que procesa en su consulta, siga las indicaciones que se describen en el artículo Reducir los datos procesados en las consultas.

Combinación de alta cardinalidad

Cuando una consulta contiene una unión con claves no únicas en ambos lados de la unión, el tamaño de la tabla de salida puede ser considerablemente mayor que el tamaño de cualquiera de las tablas de entrada. Esta estadística indica que la proporción de filas de salida con respecto a las filas de entrada es alta y ofrece información sobre estos recuentos de filas.

Qué hacer si eres analista

Comprueba las condiciones de unión para confirmar que el aumento del tamaño de la tabla de salida es el esperado. Evita usar combinaciones cruzadas. Si debes usar una combinación cruzada, prueba a usar una cláusula GROUP BY para preagregar resultados o usa una función de ventana. Para obtener más información, consulta Reducir los datos antes de usar una JOIN.

Desviación de partición

Vista previa

Esta función está sujetas a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Las funciones previas a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

Para enviar comentarios o solicitar asistencia con esta función, envía un correo a [e-mail].

Una distribución de datos sesgada puede provocar que las consultas se ejecuten lentamente. Cuando se ejecuta una consulta, BigQuery divide los datos en particiones pequeñas. No puedes compartir particiones entre ranuras. Por lo tanto, si los datos no están distribuidos de forma uniforme, algunas particiones se vuelven muy grandes, lo que provoca que falle la ranura que procesa la partición de gran tamaño.

El sesgo se produce en JOIN fases. Cuando ejecutas una operación JOIN, BigQuery divide los datos de la derecha y la izquierda de la operación JOIN en particiones. Si una partición es demasiado grande, los datos se reequilibran mediante fases de repartición. Si la asimetría es demasiado grande y BigQuery no puede reequilibrar más, se añade una estadística de asimetría de partición a la fase "JOIN". Este proceso se conoce como fases de repartición. Si BigQuery detecta alguna partición grande que no se puede dividir más, se añade una estadística de sesgo de partición a la fase JOIN.

Qué hacer si eres analista

Para evitar el sesgo de partición, filtre sus datos lo antes posible.

Interpretar la información de las fases de las consultas

Además de usar las estadísticas del rendimiento de las consultas, también puedes seguir estas directrices cuando revises los detalles de las fases de las consultas para determinar si hay algún problema con una consulta:

• Si el valor de Espera (ms) de una o varias fases es alto en comparación con las ejecuciones anteriores de la consulta:
  • Comprueba si tienes suficientes espacios disponibles para tu carga de trabajo. Si no es así, equilibra la carga cuando ejecutes consultas que consuman muchos recursos para que no compitan entre sí.
  • Si el valor de Espera (ms) es más alto que en una sola fase, consulta la fase anterior para ver si se ha introducido un cuello de botella. Los cambios sustanciales en los datos o el esquema de las tablas implicadas en la consulta pueden afectar al rendimiento de la consulta.
• Si el valor de Bytes de salida de la aleatorización de una fase es alto en comparación con las ejecuciones anteriores de la consulta o con una fase anterior, evalúa los pasos procesados en esa fase para ver si alguno crea cantidades de datos inesperadamente grandes. Una causa habitual de este problema es que un paso procese un INNER JOIN en el que haya claves duplicadas en ambos lados de la unión. Esto puede devolver una cantidad de datos inesperadamente grande.
• Usa el gráfico de ejecución para ver las fases principales por duración y procesamiento. Ten en cuenta la cantidad de datos que generan y si es proporcional al tamaño de las tablas a las que se hace referencia en la consulta. Si no es así, revisa los pasos de esas fases para ver si alguno de ellos puede generar una cantidad inesperada de datos provisionales.

Siguientes pasos

• Consulta las directrices de optimización de consultas para obtener consejos sobre cómo mejorar el rendimiento de las consultas.