Solucionar problemas de las consultas

Este documento tiene como objetivo ayudarle a solucionar problemas habituales relacionados con la ejecución de consultas, como identificar los motivos de las consultas lentas o proporcionar pasos para resolver errores comunes devueltos por consultas fallidas.

Solucionar problemas de consultas lentas

Cuando intente solucionar problemas de rendimiento lento de las consultas, tenga en cuenta las siguientes causas habituales:

  1. Consulta la página Google Cloud Estado del servicio para ver si hay interrupciones conocidas del servicio de BigQuery que puedan afectar al rendimiento de las consultas.

  2. Consulta la cronología de la tarea de tu consulta en la página de detalles de la tarea para ver cuánto ha tardado en completarse cada fase de la consulta.

  3. Consulte el campo finalExecutionDurationMs de la JobStatistics de su tarea de consulta. Es posible que se haya reintentado la consulta. El campo finalExecutionDurationMs contiene la duración en milisegundos de la ejecución del último intento de este trabajo.

  4. Consulte los bytes procesados en la página de detalles del trabajo de consulta para ver si son más de lo esperado. Para ello, compara el número de bytes procesados por la consulta actual con otra consulta que se haya completado en un tiempo aceptable. Si hay una gran discrepancia en los bytes procesados entre las dos consultas, es posible que la consulta haya sido lenta debido a un gran volumen de datos. Para obtener información sobre cómo optimizar las consultas para gestionar grandes volúmenes de datos, consulta Optimizar las operaciones de computación de las consultas.

    También puede identificar las consultas de su proyecto que procesan una gran cantidad de datos buscando las consultas más caras en la INFORMATION_SCHEMA.JOBSvista.

Comparar la ejecución lenta y rápida de la misma consulta

Si una consulta que antes se ejecutaba rápidamente ahora lo hace lentamente, examina la salida del objeto de la API Jobs para identificar los cambios en su ejecución.

Resultados en caché

Para confirmar si la ejecución rápida del trabajo se ha debido a un acierto de caché, consulta el valor de cacheHit. Si el valor es true para la ejecución rápida de la consulta, la consulta ha usado resultados almacenados en caché en lugar de ejecutar la consulta.

Si esperas que el trabajo lento use resultados almacenados en caché, investiga por qué la consulta ya no usa resultados almacenados en caché. Si no esperas que la consulta recupere datos de la caché, busca un ejemplo de ejecución rápida de una consulta que no haya accedido a la caché para investigar el problema.

Retrasos en la cuota

Para determinar si la ralentización se ha debido a alguna prórroga de cuota, consulta el campo quotaDeferments de ambos trabajos. Compara los valores para determinar si la hora de inicio de la consulta más lenta se ha retrasado por alguna prórroga de cuota que no ha afectado al trabajo más rápido.

Duración de la ejecución

Para saber la diferencia entre la duración de la ejecución del último intento de ambos trabajos, compara sus valores del campo finalExecutionDurationMs.

Si los valores de finalExecutionDurationMs son bastante similares, pero la diferencia en el tiempo de ejecución real entre las dos consultas, calculado como startTime - endTime, es mucho mayor, significa que podría haber habido un reintento de ejecución de consulta interno para el trabajo lento debido a un posible problema transitorio. Si ves este patrón de diferencia repetidamente, ponte en contacto con el equipo de Asistencia de Cloud para obtener ayuda.

Bytes procesados

Revisa los bytes procesados en la página de detalles del trabajo de consulta o consulta el totalBytesProcessed de JobStatistics para ver si es superior al esperado. Si hay una gran discrepancia en los bytes procesados entre las dos consultas, es posible que la consulta sea lenta debido a un cambio en el volumen de datos procesados. Para obtener información sobre cómo optimizar las consultas para gestionar grandes volúmenes de datos, consulta Optimizar las operaciones de computación de las consultas. Los siguientes motivos pueden provocar un aumento del número de bytes procesados por una consulta:

  • El tamaño de las tablas a las que hace referencia la consulta ha aumentado.
  • Ahora, la consulta lee una partición más grande de la tabla.
  • La consulta hace referencia a una vista cuya definición ha cambiado.

Tablas de referencia

Comprueba si las consultas leen las mismas tablas analizando el resultado del campo referencedTables en JobStatistics2. Las diferencias en las tablas de referencia se pueden explicar de la siguiente manera:

  • Se ha modificado la consulta de SQL para leer diferentes tablas. Compara el texto de la consulta para confirmarlo.
  • La definición de la vista ha cambiado entre las ejecuciones de la consulta. Consulta las definiciones de las vistas a las que se hace referencia en esta consulta y actualízalas si es necesario.

Las diferencias en las tablas de referencia podrían explicar los cambios en totalBytesProcessed.

Uso de vistas materializadas

Si la consulta hace referencia a alguna vista materializada, las diferencias en el rendimiento pueden deberse a que se hayan elegido o rechazado vistas materializadas durante la ejecución de la consulta. Inspecciona MaterializedViewStatistics para saber si alguna de las vistas materializadas usadas en la consulta rápida se ha rechazado en la consulta lenta. Consulta los campos chosen y rejectedReason del objeto MaterializedView.

Estadísticas de almacenamiento en caché de metadatos

En el caso de las consultas que implican tablas de BigLake de Amazon S3 o tablas de BigLake de Cloud Storage con el almacenamiento de metadatos en caché habilitado, compara el resultado de MetadataCacheStatistics para comprobar si hay alguna diferencia en el uso de la caché de metadatos entre la consulta lenta y la rápida, así como los motivos correspondientes. Por ejemplo, la caché de metadatos puede estar fuera de la ventana maxStaleness de la tabla.

Comparar estadísticas de BigQuery BI Engine

Si la consulta usa BigQuery BI Engine, analiza la salida de BiEngineStatistics para determinar si se han aplicado los mismos modos de aceleración a la consulta lenta y a la rápida. Consulta el campo BiEngineReason para conocer el motivo general de la aceleración parcial o de la falta de aceleración, como la falta de memoria, la ausencia de una reserva o que la entrada sea demasiado grande.

Revisar las diferencias en las estadísticas de rendimiento de las consultas

Compara las estadísticas de rendimiento de las consultas de cada una de las consultas consultando el gráfico de ejecución de la Google Cloud consola o el objeto StagePerformanceStandaloneInsight para identificar los siguientes problemas:

Presta atención tanto a las estadísticas proporcionadas para el trabajo lento como a las diferencias entre las estadísticas generadas para el trabajo rápido para identificar los cambios en las fases que afectan al rendimiento.

Para analizar los metadatos de ejecución de una tarea de forma más exhaustiva, es necesario examinar las fases de ejecución de la consulta comparando los objetos ExplainQueryStage de las dos tareas.

Para empezar, consulta las métricas Wait ms y Shuffle output bytes descritas en la sección Interpretar la información de la fase de consulta.

Advertencias de recursos de la vista INFORMATION_SCHEMA.JOBS

Consulta el campo query_info.resource_warning de la vista INFORMATION_SCHEMA.JOBS para ver si hay alguna diferencia en las advertencias analizadas por BigQuery con respecto a los recursos utilizados.

Análisis de estadísticas de cargas de trabajo

Los recursos de ranura disponibles y la contención de ranuras pueden afectar al tiempo de ejecución de las consultas. En las siguientes secciones se explica el uso y la disponibilidad de las ranuras en una ejecución concreta de una consulta.

Promedio de ranuras por segundo

Para calcular el número medio de ranuras usadas por la consulta por milisegundo, divide el valor de ranura-milisegundo de la tarea, totalSlotMs de JobStatistics2, entre la duración en milisegundos de la ejecución del último intento de esta tarea, finalExecutionDurationMs de JobStatistics.

También puede calcular el número medio de ranuras por milisegundo que usa un trabajo consultando la vista INFORMATION_SCHEMA.JOBS.

Un trabajo que realice una cantidad de trabajo similar con una mayor cantidad de ranuras medias por segundo se completará más rápido. Un uso medio de las ranuras por segundo inferior puede deberse a lo siguiente:

  1. No había recursos adicionales disponibles debido a un conflicto de recursos entre diferentes tareas. La reserva se había agotado.
  2. La tarea no ha solicitado más slots durante una gran parte de la ejecución. Por ejemplo, esto puede ocurrir cuando hay una asimetría de datos.

Modelos de gestión de cargas de trabajo y tamaño de la reserva

Si usas el modelo de facturación bajo demanda, el número de espacios que puedes usar por proyecto es limitado. En ocasiones, es posible que tu proyecto tenga menos ranuras disponibles si hay una gran cantidad de contención en función de la capacidad bajo demanda de una ubicación específica.

El modelo basado en la capacidad es más predecible y te permite especificar un número garantizado de espacios publicitarios básicos.

Ten en cuenta estas diferencias al comparar la ejecución de una consulta a petición con la de una consulta que usa una reserva.

Se recomienda usar una reserva para disfrutar de un rendimiento de ejecución de consultas estable y predecible. Para obtener más información sobre las diferencias entre las cargas de trabajo bajo demanda y las basadas en la capacidad, consulta el artículo Introducción a la gestión de cargas de trabajo.

Simultaneidad de tareas

La simultaneidad de los trabajos representa la competencia entre los trabajos por los recursos de ranura durante la ejecución de las consultas. Una mayor simultaneidad de los trabajos suele provocar una ejecución más lenta de los trabajos, ya que estos tienen acceso a menos ranuras.

Puede consultar la vista INFORMATION_SCHEMA.JOBS para averiguar el número medio de trabajos simultáneos que se están ejecutando al mismo tiempo que una consulta concreta en un proyecto.

Si hay más de un proyecto asignado a una reserva, modifique la consulta para usar JOBS_BY_ORGANIZATION en lugar de JOBS_BY_PROJECT para obtener datos precisos a nivel de reserva.

Una simultaneidad media más alta durante la ejecución lenta del trabajo en comparación con la del trabajo rápido es un factor que contribuye a la lentitud general.

Intenta reducir la simultaneidad en el proyecto o la reserva distribuyendo las consultas que consumen muchos recursos a lo largo del tiempo en una reserva o un proyecto, o bien en diferentes reservas o proyectos.

Otra solución es comprar una reserva o aumentar el tamaño de una que ya tengas. Te recomendamos que permitas que la reserva use las ranuras inactivas.

Para saber cuántas ranuras debes añadir, consulta el artículo sobre cómo estimar los requisitos de capacidad de ranuras.

Las tareas que se ejecutan en reservas con más de un proyecto asignado pueden experimentar resultados de asignación de ranuras diferentes con la misma simultaneidad media de tareas en función del proyecto que las ejecute. Consulta más información sobre la programación justa.

Utilización de reservas

Los gráficos de recursos de administrador y BigQuery Cloud Monitoring se pueden usar para monitorizar la utilización de las reservas. Para obtener más información, consulta Monitorizar reservas de BigQuery.

Para saber si un trabajo ha solicitado ranuras adicionales, consulta la métrica de unidades ejecutables estimadas, que es estimatedRunnableUnits de la respuesta de la API Job o period_estimated_runnable_units en la vista INFORMATION_SCHEMA.JOBS_TIMELINE. Si el valor de esta métrica es superior a 0, significa que el trabajo podría haber aprovechado más ranuras en ese momento. Para estimar el porcentaje del tiempo de ejecución de la tarea en el que se habría beneficiado de ranuras adicionales, ejecuta la siguiente consulta en la vista INFORMATION_SCHEMA.JOBS_TIMELINE:

SELECT
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS execution_duration_percentage
FROM `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_id = 'my_job_id'
GROUP BY job_id;
 El resultado es similar al siguiente: 
+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

Un porcentaje bajo significa que la disponibilidad de recursos de la ranura no es un factor importante que contribuya a la lentitud de la consulta en este caso.

Si el porcentaje es alto y la reserva no se ha utilizado por completo durante este tiempo, ponte en contacto con el equipo de Asistencia de Google Cloud para investigar el problema.

Si la reserva se ha utilizado por completo durante la ejecución lenta del trabajo y el porcentaje es alto, significa que el trabajo se ha limitado por los recursos. Puedes reducir la simultaneidad, aumentar el tamaño de la reserva, permitir que la reserva use ranuras inactivas o comprar una reserva si el trabajo se ha ejecutado bajo demanda.

Los metadatos de las tareas y los resultados del análisis de la carga de trabajo no son concluyentes

Si sigues sin encontrar el motivo de que el rendimiento de las consultas sea más lento de lo esperado, ponte en contacto con el equipo de Asistencia de Cloud para obtener ayuda.

Resolución de esquemas Avro

Error string: Cannot skip stream

Este error puede producirse al cargar varios archivos Avro con esquemas diferentes, lo que provoca un problema de resolución de esquemas y hace que el trabajo de importación falle en un archivo aleatorio.

Para solucionar este error, asegúrese de que el último archivo alfabético del trabajo de carga contenga el superconjunto (unión) de los esquemas diferentes. Este es un requisito basado en cómo gestiona Avro la resolución de esquemas.

Consultas simultáneas en conflicto

Error string: Concurrent jobs in the same session are not allowed

Este error puede producirse cuando se ejecutan varias consultas simultáneamente en una sesión, lo que no se admite. Consulta las limitaciones de las sesiones.

Declaraciones DML en conflicto

Error string: Could not serialize access to table due to concurrent update

Este error puede producirse cuando las instrucciones de lenguaje de manipulación de datos (DML) que modifican datos y se ejecutan simultáneamente en la misma tabla entran en conflicto entre sí o cuando la tabla se trunca durante una instrucción de DML que modifica datos. Para obtener más información, consulta Conflictos de instrucciones DML.

Para solucionar este error, ejecuta operaciones de DML que afecten a una sola tabla de forma que no se solapen.

Subconsultas correlacionadas

Error string: Correlated subqueries that reference other tables are not supported unless they can be de-correlated

Este error puede producirse cuando tu consulta contiene una subconsulta que hace referencia a una columna de fuera de esa subconsulta, llamada columna de correlación. La subconsulta correlacionada se evalúa mediante una estrategia de ejecución anidada ineficiente, en la que la subconsulta se evalúa para cada fila de la consulta externa que produce las columnas de correlación. A veces, BigQuery puede reescribir internamente las consultas con subconsultas correlacionadas para que se ejecuten de forma más eficiente. El error de subconsultas correlacionadas se produce cuando BigQuery no puede optimizar la consulta lo suficiente.

Para solucionar este error, prueba lo siguiente:

  • Elimina las cláusulas ORDER BY, LIMIT, EXISTS, NOT EXISTS o IN de tu subconsulta.
  • Usa una consulta con varias instrucciones para crear una tabla temporal a la que hacer referencia en tu subconsulta.
  • Vuelve a escribir la consulta para usar CROSS JOIN.

Permisos de control de acceso a nivel de columna insuficientes

Error string: Requires fineGrainedGet permission on the read columns to execute the DML statements

Este error se produce cuando intentas ejecutar una instrucción DML DELETE, UPDATE o MERGE sin tener el permiso de lector pormenorizado en las columnas analizadas que usan el control de acceso a nivel de columna para restringir el acceso a nivel de columna. Para obtener más información, consulta Impacto en las escrituras del control de acceso a nivel de columna.

Credenciales no válidas para consultas programadas

Cadenas de error:

  • Error code: INVALID_USERID
  • Error code 5: Authentication failure: User Id not found
  • PERMISSION_DENIED: BigQuery: Permission denied while getting Drive credentials

Este error puede producirse cuando una consulta programada falla porque tiene credenciales obsoletas, sobre todo al consultar datos de Google Drive.

Para solucionar este error, siga estos pasos:

Credenciales de cuenta de servicio no válidas

Error string: HttpError 403 when requesting returned: The caller does not have permission

Este error puede aparecer cuando intentes configurar una consulta programada con una cuenta de servicio. Para solucionar este error, consulta los pasos que se indican en Problemas de autorización y permisos.

Hora de la captura no válida

Error string: Invalid snapshot time

Este error puede producirse al intentar consultar datos históricos que están fuera del periodo de tiempo del conjunto de datos. Para solucionar este error, cambia la consulta para acceder al historial de datos dentro del periodo de viaje en el tiempo del conjunto de datos.

Este error también puede aparecer si se elimina una de las tablas usadas en la consulta y se vuelve a crear después de que se inicie la consulta. Comprueba si hay una consulta o una aplicación programada que realice esta operación y que se haya ejecutado al mismo tiempo que la consulta fallida. Si es así, prueba a mover el proceso que realiza la operación de eliminación y recreación para que se ejecute en un momento que no entre en conflicto con las consultas que leen esa tabla.

El trabajo ya existe

Error string: Already Exists: Job <job name>

Este error puede producirse en tareas de consulta que deben evaluar arrays grandes, de modo que se tarda más de lo habitual en crear una tarea de consulta. Por ejemplo, una consulta con una cláusula WHERE como WHERE column IN (<2000+ elements array>).

Para solucionar este error, siga estos pasos:

Este error también puede producirse cuando asignas manualmente un ID de trabajo, pero el trabajo no devuelve un resultado correcto en un periodo de tiempo de espera. En este caso, puedes añadir un controlador de excepciones para comprobar si existe el trabajo. Si es así, puedes extraer los resultados de la consulta del trabajo.

no se ha encontrado la tarea

Error string: Job not found

Este error puede producirse en respuesta a una llamada getQueryResults en la que no se especifica ningún valor para el campo location. Si es así, vuelve a intentarlo y proporciona un valor de location.

Para obtener más información, consulta Evitar varias evaluaciones de las mismas expresiones de tabla comunes (CTEs).

Ubicación no encontrada

Error string: Dataset [project_id]:[dataset_id] was not found in location [region]

Este error se devuelve cuando haces referencia a un recurso de conjunto de datos que no existe o cuando la ubicación de la solicitud no coincide con la del conjunto de datos.

Para solucionar este problema, especifique la ubicación del conjunto de datos en la consulta o confirme que el conjunto de datos está disponible en la misma ubicación.

La consulta supera el límite de tiempo de ejecución

Error string: Query fails due to reaching the execution time limit

Si tu consulta alcanza el límite de tiempo de ejecución de consultas, consulta el tiempo de ejecución de las ejecuciones anteriores de la consulta. Para ello, consulta la vista INFORMATION_SCHEMA.JOBS con una consulta similar a la del siguiente ejemplo:

SELECT TIMESTAMP_DIFF(end_time, start_time, SECOND) AS runtime_in_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE statement_type = 'QUERY'
AND query = "my query string";

Si las ejecuciones anteriores de la consulta han tardado mucho menos tiempo, utiliza las estadísticas de rendimiento de las consultas para determinar y solucionar el problema subyacente.

La respuesta de la consulta es demasiado grande

Error string: responseTooLarge

Este error se produce cuando los resultados de la consulta superan el tamaño máximo de respuesta.

Para solucionar este error, sigue las instrucciones que se indican en el mensaje de error responseTooLarge.

No se ha encontrado la reserva o faltan franjas horarias

Error string: Cannot run query: project does not have the reservation in the data region or no slots are configured

Este error se produce cuando la reserva asignada al proyecto en la región de la consulta tiene cero ranuras asignadas. Puedes añadir espacios a la reserva, permitir que la reserva use espacios inactivos, usar otra reserva o quitar la asignación y ejecutar la consulta bajo demanda.

No se ha encontrado la tabla

Error string: Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

Este error se produce cuando no se encuentra una tabla de su consulta en el conjunto de datos o en la región que ha especificado. Para solucionar este error, siga estos pasos:

  • Comprueba que tu consulta contiene el nombre del proyecto, del conjunto de datos y de la tabla correctos.
  • Comprueba que la tabla exista en la región en la que has ejecutado la consulta.
  • Asegúrate de que la tabla no se haya eliminado y vuelto a crear durante la ejecución del trabajo. De lo contrario, la propagación incompleta de los metadatos puede provocar este error.

Demasiadas instrucciones DML

Error string: Too many DML statements outstanding against <table-name>, limit is 20

Este error se produce cuando se supera el límite de 20 instrucciones DML en estado PENDING en una cola de una sola tabla. Este error suele producirse cuando envías tareas de DML a una sola tabla más rápido de lo que BigQuery puede procesar.

Una posible solución es agrupar varias operaciones DML más pequeñas en trabajos más grandes, pero menos numerosos. Por ejemplo, puedes agrupar actualizaciones e inserciones. Cuando agrupas tareas más pequeñas en tareas más grandes, el coste de ejecutar las tareas más grandes se amortiza y la ejecución es más rápida. Consolidar las instrucciones de DML que afectan a los mismos datos suele mejorar la eficiencia de los trabajos de DML y es menos probable que se supere el límite de la cuota de tamaño de la cola. Para obtener más información sobre cómo optimizar las operaciones de DML, consulta Evitar las instrucciones de DML que actualizan o insertan filas individuales.

Otras soluciones para mejorar la eficiencia de las DMLs podrían ser particionar o agrupar en clústeres tus tablas. Para obtener más información, consulta las prácticas recomendadas.

Se ha abortado la transacción debido a una actualización simultánea

Error string: Transaction is aborted due to concurrent update against table [table_name]

Este error puede producirse cuando dos instrucciones DML de mutación diferentes intentan actualizar la misma tabla simultáneamente. Por ejemplo, supongamos que inicias una transacción en una sesión que contiene una instrucción DML de mutación seguida de un error. Si no hay ningún controlador de excepciones, BigQuery revierte automáticamente la transacción cuando finaliza la sesión, lo que tarda hasta 24 horas. Durante este tiempo, los demás intentos de ejecutar una instrucción DML mutadora en la tabla fallarán.

Para solucionar este error, enumera tus sesiones activas y comprueba si alguna de ellas contiene una tarea de consulta con el estado ERROR que haya ejecutado una instrucción DML de mutación en la tabla. A continuación, finaliza esa sesión.

El usuario no tiene permiso

Cadenas de error:

  • Access Denied: Project [project_id]: User does not have bigquery.jobs.create permission in project [project_id].
  • User does not have permission to query table project-id:dataset.table.
  • Access Denied: User does not have permission to query table or perhaps it does not exist.

Estos errores pueden producirse cuando ejecutas una consulta sin el permiso bigquery.jobs.create en el proyecto desde el que la ejecutas, independientemente de los permisos que tengas en el proyecto que contiene los datos.

También puedes recibir estos errores si tu cuenta de servicio, usuario o grupo no tiene el permiso bigquery.tables.getData en todas las tablas y vistas a las que hace referencia tu consulta. Para obtener más información sobre los permisos necesarios para ejecutar una consulta, consulta la sección Roles necesarios.

Estos errores también se pueden producir si la tabla no existe en la región consultada, como asia-south1. Para verificar la región, consulte la ubicación del conjunto de datos.

Cuando abordes estos errores, ten en cuenta lo siguiente:

  • Cuentas de servicio: las cuentas de servicio deben tener el permiso bigquery.jobs.create en el proyecto desde el que se ejecutan y el permiso bigquery.tables.getData en todas las tablas y vistas a las que haga referencia la consulta.

  • Roles personalizados: los roles de gestión de identidades y accesos personalizados deben tener el permiso bigquery.jobs.create incluido explícitamente en el rol correspondiente y el permiso bigquery.tables.getData en todas las tablas y vistas a las que haga referencia la consulta.

  • Conjuntos de datos compartidos: cuando trabajas con conjuntos de datos compartidos en otro proyecto, es posible que necesites el permiso bigquery.jobs.create en el proyecto para ejecutar consultas o trabajos en ese conjunto de datos.

Para dar permiso para acceder a una tabla o una vista, consulta Dar acceso a una tabla o una vista.

Problemas por superar el límite de recursos

Los siguientes problemas se producen cuando BigQuery no tiene suficientes recursos para completar la consulta.

La consulta supera los recursos de CPU

Error string: Query exceeded resource limits

Este error se produce cuando las consultas bajo demanda usan demasiada CPU en relación con la cantidad de datos analizados. Para obtener información sobre cómo resolver estos problemas, consulta el artículo Solucionar problemas de recursos superados.

La consulta supera los recursos de memoria

Error string: Resources exceeded during query execution: The query could not be executed in the allotted memory

En el caso de las instrucciones SELECT, este error se produce cuando la consulta usa demasiados recursos. Para solucionar este error, consulta Solucionar problemas por haber superado los recursos.

No hay espacio en la pila

Error string: Out of stack space due to deeply nested query expression during query resolution.

Este error puede producirse cuando una consulta contiene demasiadas llamadas a funciones anidadas. A veces, algunas partes de una consulta se traducen a llamadas de funciones durante el análisis. Por ejemplo, una expresión con operadores de concatenación repetidos, como A || B || C || ..., se convierte en CONCAT(A, CONCAT(B, CONCAT(C, ...))).

Para solucionar este error, reescribe la consulta para reducir la cantidad de anidación.

Recursos excedidos durante la ejecución de la consulta

Error string: Resources exceeded during query execution: The query could not be executed in the allotted memory. Peak usage: [percentage]% of limit. Top memory consumer(s): ORDER BY operations.

Esto puede ocurrir con las consultas de ORDER BY ... LIMIT ... OFFSET .... Debido a los detalles de la implementación, la ordenación puede producirse en una sola unidad de computación, que puede quedarse sin memoria si tiene que procesar demasiadas filas antes de que se apliquen LIMIT y OFFSET, sobre todo si OFFSET es grande.

Para solucionar este error, evite usar valores de OFFSET grandes en las consultas ORDER BY ... LIMIT. También puedes usar la función de ventana escalable ROW_NUMBER() para asignar rangos en función del orden elegido y, a continuación, filtrar estos rangos en una cláusula WHERE. Por ejemplo:

SELECT ...
FROM (
  SELECT ROW_NUMBER() OVER (ORDER BY ...) AS rn
  FROM ...
)
WHERE rn > @start_index AND rn <= @page_size + @start_index  -- note that row_number() starts with 1

La consulta supera los recursos de aleatorización

Error string: Resources exceeded during query execution: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations

Este error se produce cuando una consulta no puede acceder a suficientes recursos de aleatorización.

Para solucionar este error, aprovisione más ranuras o reduzca la cantidad de datos que procesa la consulta. Para obtener más información sobre cómo hacerlo, consulta Cuota de Shuffle insuficiente.

Para obtener más información sobre cómo resolver estos problemas, consulta el artículo Solucionar problemas de recursos excedidos.

La consulta es demasiado compleja

Error string: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

Este error se produce cuando una consulta es demasiado compleja. Las causas principales de la complejidad son las siguientes:

  • WITH que estén anidadas en profundidad o que se usen repetidamente.
  • Vistas que están anidadas en profundidad o que se usan repetidamente.
  • Uso repetido del operador UNION ALL.

Para solucionar este error, prueba con las siguientes opciones:

  • Divide la consulta en varias consultas y, a continuación, usa el lenguaje de procedimiento para ejecutar esas consultas en una secuencia con un estado compartido.
  • Usa tablas temporales en lugar de cláusulas WITH.
  • Reescribe la consulta para reducir el número de objetos y comparaciones a los que se hace referencia.

Para monitorizar de forma proactiva las consultas que se acercan al límite de complejidad, puede usar el campo query_info.resource_warning de la vista INFORMATION_SCHEMA.JOBS. En el siguiente ejemplo se devuelven las consultas con un uso elevado de recursos de los últimos tres días:

SELECT
  ANY_VALUE(query) AS query,
  MAX(query_info.resource_warning) AS resource_warning
FROM
  <your_project_id>.`region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 DAY)
  AND query_info.resource_warning IS NOT NULL
GROUP BY
  query_info.query_hashes.normalized_literals
LIMIT
  1000

Para obtener más información sobre cómo resolver estos problemas, consulta el artículo Solucionar problemas de recursos excedidos.

Solucionar problemas de recursos superados

Para las tareas de consulta:

Para optimizar tus consultas, prueba a seguir estos pasos:

  • Prueba a eliminar una cláusula ORDER BY.
  • Si tu consulta usa JOIN, asegúrate de que la tabla más grande se encuentre en el lado izquierdo de la cláusula. Asegúrese también de que sus datos no contengan claves de combinación duplicadas.
  • Si tu consulta usa FLATTEN, determina si es necesario para tu caso práctico. Para obtener más información, consulta datos anidados y repetidos.
  • Si tu consulta usa EXACT_COUNT_DISTINCT, te recomendamos que uses COUNT(DISTINCT) en su lugar.
  • Si tu consulta usa COUNT(DISTINCT <value>, <n>) con un valor de <n> grande, considera usar GROUP BY en su lugar. Para obtener más información, consulta COUNT(DISTINCT).
  • Si tu consulta usa UNIQUE, te recomendamos que uses GROUP BY o una función de ventana dentro de una subselección.
  • Si tu consulta materializa muchas filas mediante una cláusula LIMIT, considera la posibilidad de filtrar por otra columna, por ejemplo, ROW_NUMBER(), o de eliminar la cláusula LIMIT por completo para permitir la paralelización de escritura.
  • Si tu consulta usaba vistas anidadas y una cláusula WITH, esto puede provocar un crecimiento exponencial de la complejidad y, por lo tanto, alcanzar los límites.
  • Usa tablas temporales en lugar de cláusulas WITH. Es posible que una cláusula WITH tenga que recalcularse varias veces, lo que puede hacer que la consulta sea compleja y, por lo tanto, lenta. Almacenar los resultados intermedios en tablas temporales se reduce la complejidad.
  • Evita usar consultas UNION ALL.
  • Si tu consulta usa MATCH_RECOGNIZE, modifica la cláusula PARTITION BY para reducir el tamaño de las particiones o añade una cláusula PARTITION BY si no existe.

Para obtener más información, consulta los siguientes recursos:

Para las tareas de carga:

Si vas a cargar archivos Avro o Parquet, reduce el tamaño de las filas de los archivos. Consulta las restricciones de tamaño específicas del formato de archivo que vas a subir:

Si recibes este error al cargar archivos ORC, ponte en contacto con el equipo de Asistencia.

Para la API Storage:

Error string: Stream memory usage exceeded

Durante una llamada ReadRows de la API Storage Read, es posible que algunas transmisiones con un uso elevado de memoria reciban un error RESOURCE_EXHAUSTED con este mensaje. Esto puede ocurrir al leer tablas anchas o tablas con un esquema complejo. Para solucionar este problema, reduce el tamaño de las filas de resultados seleccionando menos columnas para leer (con el parámetro selected_fields) o simplificando el esquema de la tabla.

Solucionar problemas de conectividad

En las siguientes secciones se describe cómo solucionar problemas de conectividad al intentar interactuar con BigQuery:

Incluir en la lista de permitidos los DNS de Google

Usa la herramienta Dig de IP de Google para resolver el endpoint DNS de BigQuery bigquery.googleapis.com en una sola IP de registro "A". Asegúrate de que esta IP no esté bloqueada en la configuración de tu cortafuegos.

En general, recomendamos incluir en la lista de permitidos los nombres de DNS de Google. Los intervalos de IP compartidos en los archivos https://www.gstatic.com/ipranges/goog.json y https://www.gstatic.com/ipranges/cloud.json cambian con frecuencia, por lo que recomendamos incluir en una lista de permitidos los nombres de DNS de Google. A continuación, se muestra una lista de nombres de DNS habituales que recomendamos añadir a la lista de permitidos:

  • *.1e100.net
  • *.google.com
  • *.gstatic.com
  • *.googleapis.com
  • *.googleusercontent.com
  • *.appspot.com
  • *.gvt1.com

Identificar el proxy o el cortafuegos que descarta paquetes

Para identificar todos los saltos de paquetes entre el cliente y el frontend de Google (GFE), ejecuta el comando traceroute en tu máquina cliente. Este comando puede destacar el servidor que está descartando paquetes dirigidos al GFE. Aquí tienes un ejemplo de comando traceroute:

traceroute -T -p 443 bigquery.googleapis.com

También es posible identificar los saltos de paquetes de direcciones IP de GFE específicas si el problema está relacionado con una dirección IP concreta:

traceroute -T -p 443 142.250.178.138

Si hay un problema de tiempo de espera del lado de Google, verás que la solicitud llega hasta GFE.

Si ves que los paquetes nunca llegan a GFE, ponte en contacto con el administrador de tu red para resolver este problema.

Generar un archivo PCAP y analizar el cortafuegos o el proxy

Genera un archivo de captura de paquetes (PCAP) y analízalo para asegurarte de que el cortafuegos o el proxy no estén filtrando paquetes a las IPs de Google y de que permitan que los paquetes lleguen al GFE.

A continuación se muestra un ejemplo de comando que se puede ejecutar con la herramienta tcpdump:

tcpdump -s 0 -w debug.pcap -K -n host bigquery.googleapis.com

Configurar reintentos para problemas de conectividad intermitentes

Hay situaciones en las que los balanceadores de carga de GFE pueden descartar conexiones de una IP de cliente. Por ejemplo, si detectan patrones de tráfico de DDoS o si la instancia del balanceador de carga se está reduciendo, lo que puede provocar que se recicle la IP del endpoint. Si los balanceadores de carga de GFE interrumpen la conexión, el cliente debe detectar la solicitud que ha agotado el tiempo de espera y volver a enviar la solicitud al endpoint de DNS. Asegúrate de no usar la misma dirección IP hasta que la solicitud se complete correctamente, ya que la dirección IP puede haber cambiado.

Si has detectado un problema con los tiempos de espera del lado de Google, donde los reintentos no ayudan, ponte en contacto con el equipo de Atención al Cliente de Cloud e incluye un archivo PCAP actualizado generado al ejecutar una herramienta de captura de paquetes como tcpdump.

Siguientes pasos