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 multifacético, las estadísticas de rendimiento solo pueden proporcionar un panorama parcial del rendimiento general de las consultas.

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

Console

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 la 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 que se ejecutan en la etapa.
   • Todas las estadísticas de rendimiento aplicables.

   

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 en el gráfico, haz clic en Destacar 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 etapas principales por procesamiento.

   

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

   

   Usa esta opción para mostrar las etapas de repartición y la función COALESCE que están ocultas en el grafo de ejecución predeterminado.

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

En el caso de cualquier consulta que tenga problemas de regresión de rendimiento, las estadísticas de rendimiento también se muestran 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, escribe 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: Ejecutas 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: Administras los recursos y as 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 tasks. Una tarea es una porción única de datos que ingresa 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 ocurre 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

Realiza las siguientes acciones para aumentar la disponibilidad de las ranuras o disminuir su uso:

• 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 hayan suficientes ranuras en la reserva que se asignaron al proyecto que ejecutaba la consulta. Es posible que la reserva no tenga suficientes ranuras en estas situaciones:

  • Existen otros trabajos que consumen ranuras de reserva. Puedes usar los gráficos de recursos del administrador para ver cómo tu organización usa la reserva.
  • La reserva no tiene suficientes ranuras asignadas para ejecutar consultas con la suficiente rapidez. Puedes usar el estimador de ranuras para obtener una estimación del tamaño que deben tener tus reservas y procesar de manera eficiente las tareas de tus consultas.

  Para abordar esto, puedes probar una de las siguientes soluciones:

  • Agrega más ranuras (ya sean ranuras del modelo de referencia o ranuras máximas de reserva) a esa reserva.
  • Crea una reserva adicional y asígnala al proyecto que ejecuta la consulta.
  • Distribuye las consultas que requieren muchos recursos, ya sea a lo largo del tiempo dentro de una reserva o en diferentes reservas.

• Asegúrate de que las tablas que consultas estén agrupadas en clústeres. 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 las tablas no particionadas, BigQuery lee la tabla completa. Particionar tus tablas ayuda a garantizar que consultes solo el subconjunto de las tablas que te interesan.

Cuota de Shuffle insuficiente

Antes de ejecutar la consulta, BigQuery divide la lógica de tu 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 Shuffle. Las etapas posteriores de tu consulta leen datos desde Shuffle para continuar con la ejecución de tu consulta. La cuota de Shuffle es insuficiente cuando tienes más datos que se deben escribir en Shuffle que la capacidad de Shuffle que tienes.

Qué hacer si eres analista

De manera similar a la contención de ranuras, reducir la cantidad de datos que procesa la consulta puede reducir el uso aleatorio. Para ello, sigue las instrucciones en Reduce los datos procesados en las consultas.

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

Qué hacer si eres administrador

Realiza las siguientes acciones para reducir la contención de cuota aleatoria:

• 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 tienen capacidad Shuffle exclusiva. Si tu reserva ejecuta algunas consultas que hacen un uso extensivo de Shuffle, esto puede provocar que otras consultas que se ejecutan en paralelo no tengan suficiente capacidad de Shuffle. Puedes identificar qué trabajos usan la capacidad de redistribución ampliamente si consultas la columna period_shuffle_ram_usage_ratio en la vista INFORMATION_SCHEMA.JOBS_TIMELINE.

  Para abordar esto, 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 redistribución, ya sea a lo largo del tiempo dentro de una reserva o en 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 de rendimiento de las consultas, también puedes usar los siguientes lineamientos cuando revises los detalles de la etapa de consulta para 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.