Obtén estadísticas de rendimiento de las consultas

En este documento se describe cómo usar el gráfico de ejecución de consultas para diagnosticar problemas de rendimiento de consultas y ver estadísticas de rendimiento de las consultas.

BigQuery ofrece un rendimiento de consultas sólido, pero también es un sistema distribuido con muchos factores internos y externos que pueden afectar la velocidad de consulta. La naturaleza declarativa del lenguaje SQL también puede ocultar la complejidad de la ejecución de consultas. Esto significa que cuando las consultas se ejecutan de forma más lenta de lo previsto o más lento que las ejecuciones anteriores, comprender lo que sucedió puede ser un desafío.

El gráfico de ejecución de consultas proporciona una interfaz intuitiva para inspeccionar los detalles de rendimiento de las consultas. Cuando la usas, puedes revisar la información del plan de consultas en formato gráfico para cualquier consulta, ya sea en ejecución o completada.

También puedes usar el gráfico de ejecución de consultas a fin de obtener estadísticas de rendimiento para las consultas. Las estadísticas de rendimiento proporcionan las mejores sugerencias posibles para ayudarte a mejorar el rendimiento de las consultas. Dado que el rendimiento de las consultas es de varias facetas, es posible que las estadísticas de rendimiento solo proporcionen un panorama parcial del rendimiento general de la consulta.

Nota: Es posible que las estadísticas de rendimiento no se generen para los trabajos de consulta que se ejecutaron antes del 1 de octubre de 2022.

Permisos necesarios

Para usar el grafo 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 las siguientes funciones predefinidas de Identity and Access Management (IAM) de BigQuery:

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

Visualiza las 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 BigQuery en la consola de Google Cloud.

   Ir a la página de BigQuery

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

3. En la lista de trabajos, identifica el trabajo de consulta que te interesa. Haz clic en Acciones y selecciona Abrir consulta en el editor.

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

   

   Para determinar si una etapa de consulta tiene estadísticas de rendimiento, observa el ícono que muestra. Las etapas que tienen un ícono de información tienen estadísticas de rendimiento. Las etapas que tienen un ícono de verificación no lo hacen.

5. Haz clic en una etapa para abrir el panel de detalles de la etapa, en el que podrás ver la siguiente información:

   • Información del plan de consulta para la etapa.
   • Los pasos ejecutados en la etapa
   • Cualquier estadística de rendimiento aplicable

   

6. Opcional: Si inspeccionas una consulta en ejecución, haz clic en Sincronizar para actualizar el gráfico de ejecución a fin de que refleje el estado actual de la consulta.

   

7. Opcional: Para destacar las etapas principales por duración de la etapa del gráfico, haz clic en Destacar las etapas principales por duración.

   

8. Opcional: Para destacar las etapas principales por tiempo de ranura que se usa en el gráfico, haz clic en Destacar las etapas principales por procesamiento.

   

9. Opcional: Para incluir etapas de redistribución aleatoria en el grafo, haz clic en Mostrar etapas de redistribución aleatorias.

   

   Usa esta opción para mostrar las etapas de repetición y fusión para ocultar en el grafo de ejecución predeterminado.

   Las etapas de partición y fusión se ingresan mientras se ejecuta la consulta y se usan para mejorar la distribución de datos en los trabajadores que procesan la consulta. Debido a que estas etapas no están relacionadas con el texto de tu consulta, están ocultas para simplificar el plan de consulta que se muestra.

Para cualquier consulta que tenga problemas de regresión de rendimiento, también se muestran estadísticas de rendimiento en la pestaña Información del trabajo de la consulta:

SQL

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

   Ir a BigQuery

2. En el editor de consultas, ingresa la siguiente sentencia:

   
   SELECT
     `bigquery-public-data`.persistent_udfs.job_url(
       project_id || ':us.' || job_id) AS job_url,
     query_info.performance_insights
   FROM
     `region-us`.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, visita Ejecuta una consulta interactiva.

API

Puedes obtener estadísticas de rendimiento de las consultas en un formato no gráfico si llamas al método de la API jobs.list y, luego, inspeccionas la información de JobStatistics2 que se muestra.

Interpreta las estadísticas de rendimiento de las consultas

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

Las estadísticas de rendimiento están destinadas a dos públicos:

• Analistas: Ejecuta consultas en un proyecto. Te interesa descubrir por qué una consulta que ejecutaste antes se ejecuta de forma inesperada y obtener sugerencias para mejorar el rendimiento de una consulta. Tienes los permisos descritos en Permisos necesarios.

• Administradores de data lakes o almacenes de datos: Administra los recursos y las reservas de BigQuery de tu organización. Tienes los permisos asociados con el rol de administrador de BigQuery.

En cada una de las siguientes secciones, se proporciona orientación sobre lo que puedes hacer para abordar las estadísticas de rendimiento que recibes, según los roles que ocupes.

Contención de ranuras

Cuando ejecutas una consulta, BigQuery intenta dividir el trabajo que necesita tu consulta en tareas. Una tarea es una sola porción de datos que entra y sale de una etapa. Una sola ranura toma una tarea y ejecuta esa porción de datos para la etapa. Lo ideal es que las ranuras de BigQuery ejecuten estas tareas en paralelo para lograr un alto rendimiento. La contención de ranuras se produce cuando tu consulta tiene muchas tareas listas para comenzar a ejecutarse, pero BigQuery no puede obtener suficientes ranuras disponibles para ejecutarlas.

Qué hacer si eres analista

Sigue los pasos que se indican en Reduce los datos procesados en las consultas para reducir los datos que procesas en la consulta.

Qué hacer si eres administrador

Para aumentar la disponibilidad de las ranuras o disminuir su uso, realiza las siguientes acciones:

• Si usas los precios según demanda de BigQuery, tus consultas usan un grupo compartido de ranuras. Considera cambiar a precios de análisis basados en la capacidad mediante la compra de 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 que esté asignada al proyecto que ejecutaba la consulta. Es posible que la reserva no tenga suficientes ranuras en estas situaciones:

  • Hay otros trabajos que consumen ranuras de reserva. Puedes usar los gráficos de recursos de administrador para ver cómo la organización usa la reserva.
  • La reserva no tiene suficientes ranuras asignadas para ejecutar consultas lo suficientemente rápido. Puedes usar el estimador de ranuras para obtener una estimación de cuánto deberían ser tus reservas a fin de procesar las tareas de tus consultas de manera eficiente.

  Para solucionar este problema, puedes probar una de las siguientes soluciones:

  • Agrega más ranuras a esa reserva.
  • Crea una reserva adicional y asígnala al proyecto que ejecuta la consulta.
  • Distribuye las consultas que hacen un uso intensivo de los recursos, ya sea a lo largo del tiempo en una reserva o en diferentes reservas.

• Asegúrate de que las tablas que consultas estén agrupadas. El agrupamiento en clústeres ayuda a garantizar que BigQuery pueda leer con rapidez las columnas con datos correlacionados.

• Asegúrate de que las tablas que consultas estén particionadas. Para tablas no particionadas, BigQuery lee la tabla completa. La partición de tus tablas ayuda a garantizar que solo consultes el subconjunto de tus tablas que te interesan.

Cuota aleatoria insuficiente

Antes de ejecutar la consulta, BigQuery divide la lógica de la consulta en etapas. Las ranuras de BigQuery ejecutan las tareas para cada etapa. Cuando una ranura completa la ejecución de las tareas de una etapa, almacena los resultados intermedios en distribución. Las etapas posteriores de la consulta leen datos de redistribución para continuar con la ejecución de la consulta. La cuota con Shuffle no es suficiente cuando tienes más datos que deben escribirse en Shuffle que la capacidad que tienes.

Qué hacer si eres analista

Al igual que con la contención de ranuras, reducir la cantidad de datos que procesa los procesos de las consultas puede reducir el uso de redistribución. Para hacer esto, sigue las instrucciones en Reduce los datos procesados en consultas.

Algunas operaciones en SQL tienden a realizar un uso más extenso de la redistribución, en especial las operaciones JOIN y cláusulas GROUP BY. Siempre que sea posible, la reducción de la cantidad de datos en estas operaciones puede reducir el uso de la redistribución.

Qué hacer si eres administrador

Reduce la contención de cuota aleatoria mediante las siguientes acciones:

• Al igual que la contención de ranuras, si usas los precios según demanda de BigQuery, tus consultas usan un grupo compartido de ranuras. Considera cambiar a precios de análisis basados en la capacidad mediante la compra de reservas. Las reservas te brindan ranuras dedicadas y capacidad de redistribución para las consultas de tus proyectos.

• Si usas reservas de BigQuery, las ranuras incluyen capacidad aleatoria dedicada. Si tu reserva ejecuta algunas consultas que hacen un uso extensivo de la redistribución, esto puede hacer que otras consultas que se ejecutan en paralelo no obtengan suficiente capacidad de redistribución. Puedes identificar qué trabajos usan la capacidad de redistribución de forma exhaustiva si consultas la columna period_shuffle_ram_usage_ratio en la vista INFORMATION_SCHEMA.JOBS_TIMELINE.

  Para solucionar este problema, puedes probar una o más de las siguientes soluciones:

  • Agrega más ranuras a esa reserva.
  • Crea una reserva adicional y asígnala al proyecto que ejecuta la consulta.
  • Distribuye las consultas intensivas de forma aleatoria, ya sea a lo largo del tiempo dentro de una reserva o a través de diferentes reservas.

Cambio en el ajuste de la entrada de datos

La obtención de esta estadística de rendimiento indica que tu consulta lee al menos un 50% más de datos en una tabla de entrada determinada que la última vez que ejecutaste la consulta. Puedes usar el historial de cambios de tabla para ver si el tamaño de cualquiera de las tablas usadas en la consulta aumentó recientemente.

Qué hacer si eres analista

Sigue los pasos que se indican en Reduce los datos procesados en las consultas para reducir los datos que procesas en la consulta.

Unió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 filas de entrada es alta y ofrece información sobre estos recuentos de filas.

Qué hacer si eres analista

Verifica las condiciones de unión para confirmar que se espera el aumento del tamaño de la tabla de salida. Evita usar uniones cruzadas. Si debes usar una unión cruzada, intenta usar una cláusula GROUP BY para agregar previamente los resultados o usar una función analítica. Para obtener más información, consulta Reduce los datos antes de usar una JOIN.

Sesgo de partición

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

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

La distribución de datos sesgada puede hacer que las consultas se ejecuten con lentitud. 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 están distribuidos de manera desigual, algunas particiones se vuelven muy grandes, lo que falla en la ranura que procesa la partición de gran tamaño.

El sesgo ocurre en las etapas de JOIN. Cuando ejecutas una operación JOIN, BigQuery divide los datos en el lado derecho y el lado izquierdo de la operación JOIN en particiones. Si una partición es demasiado grande, los datos se vuelven a equilibrar con etapas de repartición. Si el sesgo es demasiado malo y BigQuery no puede volver a balancear, se agrega una estadística de sesgo de partición a la etapa “JOIN”. Este proceso se conoce como etapas de repartición. Si BigQuery detecta particiones grandes que no se pueden dividir, se agrega una estadística de sesgo de partición a la etapa JOIN.

Qué hacer si eres analista

Para evitar sesgos de partición, filtra tus datos lo antes posible. Para obtener más información sobre cómo evitar sesgos de partición, consulta Filtra datos para datos sesgados.

Interpreta la información de la etapa de consulta

Además de usar las estadísticas del rendimiento de las consultas, también puedes usar los siguientes lineamientos cuando revises los detalles de la etapa de consulta para ayudar a determinar si hay un problema con una consulta:

• Si el valor Esperar ms de una o más etapas es alto en comparación con las ejecuciones anteriores de la consulta:
  • Verifica si tienes suficientes ranuras disponibles para adaptar tu carga de trabajo. De lo contrario, balancea las cargas cuando ejecutes consultas que requieren muchos recursos para que no compitan entre sí.
  • Si el valor Esperar ms es superior al de solo una etapa, observa la etapa antes de esta para ver si se ingresó un cuello de botella. Los cambios sustanciales en los datos o el esquema de las tablas involucradas en la consulta pueden afectar el rendimiento de la consulta.
• Si el valor de Bytes de salida de Shuffle para una etapa es alto en comparación con ejecuciones anteriores de la consulta o en comparación con una etapa anterior, evalúa los pasos procesados en esa etapa para ver si alguna. crean grandes cantidades de datos inesperadas. Una causa común es cuando un paso procesa un INNER JOIN en el que hay claves duplicadas en ambos lados de la unión. Esto puede mostrar una gran cantidad de datos.
• Usa el gráfico de ejecución para ver las etapas principales por duración y procesamiento. Considera la cantidad de datos que producen y si son proporcionales al tamaño de las tablas a las que se hace referencia en la consulta. Si no es así, revisa los pasos en esas etapas para ver si alguno de ellos puede producir una cantidad inesperada de datos provisionales.

¿Qué sigue?

• Revisa los lineamientos de optimización de consultas para obtener sugerencias sobre cómo mejorar el rendimiento de las consultas.