Soluciona problemas de consultas

El objetivo de este documento es ayudarte a solucionar problemas habituales relacionados con la ejecución de consultas, como identificar los motivos de las consultas lentas o proporcionar pasos de resolución para los errores habituales que muestran las consultas con errores.

Soluciona problemas de consultas lentas

Cuando soluciones problemas de rendimiento de las consultas lentas, ten en cuenta las siguientes causas comunes:

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

  2. Revisa el cronograma de trabajos para la consulta en la página de detalles del trabajo para ver cuánto tiempo tardó en ejecutarse cada etapa de la consulta.

    • Si la mayor parte del tiempo transcurrido se debió a tiempos de creación largos, comunícate con Atención al cliente de Cloud para obtener ayuda.

    • Si la mayor parte del tiempo transcurrido se debió a tiempos de ejecución largos, revisa las estadísticas de rendimiento de las consultas. Las estadísticas de rendimiento de las consultas pueden informarte si tu consulta se ejecutó más tiempo que el tiempo de ejecución promedio y sugerir posibles causas. Entre las posibles causas, se incluye la contención de ranuras de consultas o una cuota de Shuffle insuficiente. Para obtener más información acerca de cada problema de rendimiento de las consultas y las posibles resoluciones, consulta Interpreta las estadísticas de rendimiento de las consultas.

  3. Revisa el campo finalExecutionDurationMs en JobStatistics para tu trabajo de búsqueda. Es posible que se haya reintentado la consulta. El campo finalExecutionDurationMs contiene la duración en milisegundos de la ejecución del intento final de este trabajo.

  4. Revisa los bytes procesados en la página de detalles del trabajo de consulta para ver si es mayor de lo esperado. Para ello, compara la cantidad de bytes que procesa la consulta actual con otro trabajo de consulta que se completó en un tiempo aceptable. Si hay una gran discrepancia de bytes procesados entre las dos consultas, es posible que la consulta haya sido lenta debido a un gran volumen de datos. Si deseas obtener información acerca de cómo optimizar tus consultas para controlar grandes volúmenes de datos, consulta Optimiza el procesamiento de las consultas.

    También puedes identificar las consultas de tu proyecto que procesan una gran cantidad de datos; para ello, busca las consultas más costosas con la vista INFORMATION_SCHEMA.JOBS.

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

Si una consulta que antes se ejecutaba rápidamente ahora se ejecuta con lentitud, examina el resultado del objeto de la API de Job para identificar los cambios en su ejecución.

Aciertos de caché

Para confirmar si la ejecución rápida del trabajo fue un acierto de caché, consulta el valor de cacheHit. Si el valor es true para la ejecución rápida de la consulta, significa que la consulta usó 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 de consulta rápida que no haya alcanzado la caché para la investigación.

Retrasos en las cuotas

Para determinar si la ralentización se debió a aplazamientos de cuota, verifica el campo quotaDeferments de ambos trabajos. Compara los valores para determinar si la hora de inicio de la consulta más lenta se retrasó debido a alguna postergación de cuota que no afectó el trabajo más rápido.

Duración de la ejecución

Para comprender la diferencia entre la duración de la ejecución del último intento de ambos trabajos, compara sus valores para el 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, esto significa que podría haber habido un reintento interno de ejecución de la consulta para el trabajo lento debido a un posible problema transitorio. Si ves este patrón de diferencia de forma reiterada, comunícate con Atención al cliente 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 mayor de lo esperado. Si hay una gran discrepancia de bytes procesados entre las dos consultas, es posible que la consulta sea lenta debido a un cambio en el volumen de datos procesados. Si deseas obtener información para optimizar las consultas y controlar grandes volúmenes de datos, consulta Optimiza el procesamiento de las consultas. Los siguientes motivos pueden provocar un aumento en la cantidad de bytes que procesa una consulta:

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

Tablas a las que se hace referencia

Analiza el resultado del campo referencedTables en JobStatistics2 para verificar si las consultas leen las mismas tablas. Las diferencias en las tablas a las que se hace referencia se pueden explicar de la siguiente manera:

  • Se modificó la consulta en SQL para leer diferentes tablas. Compara el texto de la búsqueda para confirmarlo.
  • La definición de la vista cambió entre las ejecuciones de la consulta. Verifica 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 a las que se hace 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 eligen o rechazan vistas materializadas durante la ejecución de la consulta. Inspecciona MaterializedViewStatistics para comprender si se rechazó alguna vista materializada que se usó en la consulta rápida en la consulta lenta. Observa los campos chosen y rejectedReason en el objeto MaterializedView.

Estadísticas de almacenamiento en caché de metadatos

Para las consultas que involucran tablas de BigLake de Amazon S3 o tablas de BigLake de Cloud Storage con el almacenamiento en caché de metadatos habilitado, compara el resultado de MetadataCacheStatistics para verificar si hay una diferencia en el uso de la caché de metadatos entre la consulta lenta y la rápida, y los motivos correspondientes. Por ejemplo, es posible que la caché de metadatos esté fuera de la ventana maxStaleness de la tabla.

Comparación de las estadísticas de BigQuery BI Engine

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

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

Compara las estadísticas de rendimiento de las consultas para cada una de las consultas. Para ello, consulta el gráfico de ejecución en la consola de Google Cloud o el objeto StagePerformanceStandaloneInsight para comprender los siguientes problemas posibles:

Presta atención a las estadísticas proporcionadas para el trabajo lento, así como a las diferencias entre las estadísticas producidas para el trabajo rápido, para identificar los cambios en las etapas que afectan el rendimiento.

Un análisis más exhaustivo de los metadatos de ejecución del trabajo requiere comparar los objetos ExplainQueryStage de los dos trabajos y revisar las etapas individuales de la ejecución de la consulta.

Para comenzar, consulta las métricas Wait ms y Shuffle output bytes que se describen en la sección Cómo interpretar la información de la etapa de la 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 una 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 ranuras disponibles y la contención de ranuras pueden afectar el tiempo de ejecución de la consulta. En las siguientes secciones, se explica el uso y la disponibilidad de las ranuras para una ejecución en particular de una búsqueda.

Promedio de ranuras por segundo

Para calcular la cantidad promedio de ranuras que usa la consulta por milisegundo, divide el valor de milisegundos de ranura del trabajo, totalSlotMs de JobStatistics2, entre la duración en milisegundos de la ejecución del intento final de este trabajo, finalExecutionDurationMs de JobStatistics.

También puedes calcular la cantidad promedio de ranuras por milisegundo que usa un trabajo consultando la vista INFORMATION_SCHEMA.JOBS.

Un trabajo que realiza una cantidad similar de trabajo con una mayor cantidad de ranuras promedio por segundo se completa más rápido. Un uso promedio de ranuras por segundo más bajo puede deberse a lo siguiente:

  1. No había recursos adicionales disponibles debido a una contención de recursos entre diferentes trabajos: la reserva estaba al máximo.
  2. El trabajo no solicitó más ranuras durante gran parte de la ejecución. Por ejemplo, esto puede suceder cuando hay sesgo en los datos.

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

Si usas el modelo de facturación a pedido, la cantidad de ranuras que puedes usar por proyecto es limitada. Es posible que, en ocasiones, tu proyecto también tenga menos ranuras disponibles si hay una gran cantidad de contención para la capacidad según demanda en una ubicación específica.

El modelo basado en la capacidad es más predecible y te permite especificar una cantidad garantizada de ranuras del modelo de referencia.

Ten en cuenta estas diferencias cuando compares una ejecución de consulta a pedido con una ejecución de consulta que usa una reserva.

Se recomienda usar una reserva para tener un rendimiento estable y predecible en la ejecución de consultas. Para obtener más información sobre las diferencias entre las cargas de trabajo según demanda y las basadas en la capacidad, consulta Introducción a la administración de cargas de trabajo.

Simultaneidad de trabajos

La simultaneidad de los trabajos representa la competencia entre los trabajos por los recursos de ranuras durante la ejecución de la consulta. En general, una mayor simultaneidad de trabajos provoca una ejecución más lenta de los trabajos, ya que estos tienen acceso a menos ranuras.

Puedes consultar la vista INFORMATION_SCHEMA.JOBS para encontrar la cantidad promedio de trabajos simultáneos que se ejecutan al mismo tiempo que una consulta específica dentro de un proyecto.

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

Un promedio de simultaneidad más alto durante la ejecución lenta del trabajo en comparación con la ejecución rápida es un factor que contribuye a la lentitud general.

Considera reducir la simultaneidad dentro del proyecto o la reserva distribuyendo las consultas que requieren muchos recursos, ya sea a lo largo del tiempo dentro de una reserva o un proyecto, o en diferentes reservas o proyectos.

Otra solución es comprar una reserva o aumentar el tamaño de una reserva existente. Considera permitir que la reserva use ranuras inactivas.

Para saber cuántas ranuras agregar, consulta cómo estimar los requisitos de capacidad de ranuras.

Los trabajos que se ejecutan en reservas con más de un proyecto asignado pueden experimentar diferentes resultados de asignación de ranuras con la misma simultaneidad promedio de trabajos, según el proyecto que los ejecute. Obtén más información sobre la programación justa.

Uso de reservas

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

Para saber si un trabajo solicitó ranuras adicionales, consulta la métrica de unidades ejecutables estimadas, que es estimatedRunnableUnits en la respuesta de la API de Job o period_estimated_runnable_units en la vista de INFORMATION_SCHEMA.JOBS_TIMELINE. Si el valor de esta métrica es superior a 0, el trabajo podría haberse beneficiado de ranuras adicionales en ese momento. Para estimar el porcentaje del tiempo de ejecución del trabajo en el que el trabajo 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 contribuye a la lentitud de la búsqueda en esta situación.

Si el porcentaje es alto y la reserva no se utilizó por completo durante este período, comunícate con Atención al cliente de Cloud para investigar el problema.

Si la reserva se usó por completo durante la ejecución lenta del trabajo y el porcentaje es alto, significa que el trabajo se vio limitado por los recursos. Considera 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 ejecutó a pedido.

Los hallazgos del análisis de la carga de trabajo y los metadatos del trabajo no son concluyentes

Si aún no encuentras el motivo que explique el rendimiento de las consultas más lento de lo esperado, comunícate con Atención al cliente de Cloud para obtener ayuda.

Resolución de esquema de Avro

Cadena del error: Cannot skip stream

Este error puede ocurrir cuando se cargan varios archivos de Avro con diferentes esquemas, lo que genera un problema de resolución del esquema y hace que el trabajo de importación falle en un archivo aleatorio.

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

Consultas simultáneas en conflicto

Cadena del error: Concurrent jobs in the same session are not allowed

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

Declaraciones DML en conflicto

Cadena del error: Could not serialize access to table due to concurrent update

Este error puede ocurrir cuando las mutaciones de declaraciones de lenguaje de manipulación de datos (DML) que se ejecutan en simultáneo en la misma tabla entran en conflicto entre sí o cuando la tabla se trunca durante una mutación de DML. Para obtener más información, consulta Conflictos de declaraciones DML.

Para abordar este error, ejecuta operaciones DML que afecten a una sola tabla, de modo que no se superpongan.

Subconsultas correlacionadas

Cadena del error: Correlated subqueries that reference other tables are not supported unless they can be de-correlated

Este error puede ocurrir cuando tu consulta contiene una subconsulta que hace referencia a una columna desde el exterior de esa subconsulta, llamada columna de correlación. La subconsulta correlacionada se evalúa con una estrategia de ejecución anidada y poco eficiente, en la que se evalúa la subconsulta para cada fila de la consulta externa que produce las columnas de correlación. A veces, BigQuery puede volver a escribir internamente las consultas con subconsultas correlacionadas para que se ejecuten de manera más eficiente. El error de subconsultas correlacionadas ocurre cuando BigQuery no puede optimizar la consulta de forma suficiente.

Para resolver este error, prueba lo siguiente:

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

Permisos insuficientes de control de acceso a nivel de columna

Cadena del error: Requires fineGrainedGet permission on the read columns to execute the DML statements

Este error se produce cuando intentas realizar una declaración DELETE, UPDATE o MERGE de DML, sin tener el permiso detallado de lector 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 operaciones de escritura del control de acceso a nivel de columna.

Las credenciales no son válidas para las 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 ocurrir cuando una consulta programada falla debido a credenciales desactualizadas, en especial cuando se consultan datos de Google Drive.

Para abordar este error, sigue estos pasos:

Las credenciales de la cuenta de servicio no son válidas.

Cadena del error: HttpError 403 when requesting returned: The caller does not have permission

Este error puede aparecer cuando intentas configurar una consulta programada con una cuenta de servicio. Para resolver este error, consulta los pasos para solucionar problemas en Problemas de autorización y permisos.

El tiempo de la instantánea no es válido

Cadena del error: Invalid snapshot time

Este error puede ocurrir cuando intentas consultar datos históricos que están fuera del período de viaje en el tiempo del conjunto de datos. Para abordar este error, cambia la consulta a fin de acceder a los datos históricos dentro del período de viaje en el tiempo del conjunto de datos.

Este error también puede aparecer si una de las tablas usadas en la consulta se descarta y se vuelve a crear después de que comienza la consulta. Verifica si hay una consulta programada o una aplicación que realice esta operación que se ejecutó al mismo tiempo que la consulta con errores. Si es así, intenta mover el proceso que realiza la operación de descarte 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

Cadena del error: Already Exists: Job <job name>

Este error puede ocurrir en los trabajos de consulta que deben evaluar arrays grandes, de modo que la creación de un trabajo de consulta tome más tiempo que el promedio. Por ejemplo, una consulta con una cláusula WHERE como WHERE column IN (<2000+ elements array>).

Para abordar este error, sigue estos pasos:

Este error también puede ocurrir cuando estableces manualmente un ID de trabajo, pero el trabajo no devuelve un resultado exitoso dentro de un período de espera. En este caso, puedes agregar un controlador de excepciones para verificar si existe el trabajo. Si es así, puedes extraer los resultados de la consulta del trabajo.

Trabajo no encontrado

Cadena del error: Job not found

Este error puede ocurrir en respuesta a una llamada getQueryResults, en la que no se especifica ningún valor para el campo location. Si ese es el caso, vuelve a intentar la llamada y proporciona un valor location.

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

No se encontró la ubicación

Cadena del error: Dataset [project_id]:[dataset_id] was not found in location [region]

Se muestra este error 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 ubicación del conjunto de datos.

Para solucionar este problema, especifica la ubicación del conjunto de datos en la consulta o confirma que el conjunto de datos esté disponible en la misma ubicación.

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

Cadena del error: Query fails due to reaching the execution time limit

Si tu consulta llega al límite de tiempo de ejecución de la consulta, verifica el tiempo de ejecución de las ejecuciones anteriores de la consulta mediante una consulta a la vista INFORMATION_SCHEMA.JOBS con una consulta similar al 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 tomaron mucho menos tiempo, usa las estadísticas de rendimiento de las consultas para determinar y abordar el problema subyacente.

La respuesta de la consulta es demasiado grande

Cadena del error: responseTooLarge

Este error ocurre cuando los resultados de tu consulta son más grandes que el tamaño máximo de respuesta.

A fin de abordar este error, sigue las instrucciones proporcionadas para el mensaje de error responseTooLarge.

No se encontró la reserva o faltan ranuras

Cadena del error: 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 agregar ranuras a la reserva, permitir que la reserva use ranuras inactivas, usar otra reserva o quitar la asignación y ejecutar la consulta bajo demanda.

No se encontró la tabla

Cadena del error: Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

Este error ocurre cuando no se puede encontrar una tabla de tu consulta en el conjunto de datos o la región que especificaste. Para resolver este error, haz lo siguiente:

  • Verifica que tu consulta contenga el proyecto, el conjunto de datos y el nombre de la tabla correctos.
  • Verifica que la tabla exista en la región en la que ejecutaste la consulta.
  • Asegúrate de que la tabla no se haya descartado ni vuelto a crear durante la ejecución del trabajo. De lo contrario, la propagación incompleta de metadatos puede causar este error.

Demasiadas declaraciones DML

Cadena del error: Too many DML statements outstanding against <table-name>, limit is 20

Este error se produce cuando superas el límite de 20 declaraciones DML en el estado PENDING en una cola para una sola tabla. Por lo general, este error ocurre cuando envías trabajos DML en una sola tabla más rápido de lo que puede procesar BigQuery.

Una solución posible es agrupar varias operaciones DML más pequeñas en trabajos más grandes, pero menos numerosos, por ejemplo, si agrupas en lotes las actualizaciones y las inserciones. Cuando agrupas trabajos más pequeños en trabajos más grandes, el costo de ejecutar los trabajos más grandes se amortiza y la ejecución es más rápida. Por lo general, la consolidación de declaraciones DML que afectan a los mismos datos mejora la eficiencia de los trabajos DML y es menos probable que exceda el límite de cuota de tamaño de las colas. Para obtener más información acerca de cómo optimizar tus operaciones DML, consulta Evita declaraciones DML que actualizan o insertan filas individuales.

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

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

Cadena del error: Transaction is aborted due to concurrent update against table [table_name]

Este error puede ocurrir cuando dos declaraciones DML de mutación diferentes intentan actualizar la misma tabla de forma simultánea. 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 un controlador de excepciones, BigQuery revierte automáticamente la transacción cuando finaliza la sesión, lo que tarda hasta 24 horas. Durante este período, fallarán otros intentos de ejecutar una declaración DML de mutación en la tabla.

Para abordar este error, enumera tus sesiones activas y verifica si alguna de ellas contiene un trabajo de consulta con el estado ERROR que ejecutó una declaración DML de mutación en la tabla. Luego, 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 ocurrir cuando ejecutas una consulta sin el permiso bigquery.jobs.create en el proyecto desde el que ejecutas la consulta, independientemente de los permisos que tengas en el proyecto que contiene los datos.

También es posible que recibas 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 Roles requeridos.

Estos errores también pueden ocurrir si la tabla no existe en la región consultada, como asia-south1. Para verificar la región, examina 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 hace referencia la consulta.

  • Roles personalizados: Los roles personalizados de IAM deben tener el permiso bigquery.jobs.create incluido de forma explícita en el rol pertinente y deben tener el permiso bigquery.tables.getData en todas las tablas y vistas a las que hace referencia la consulta.

  • Conjuntos de datos compartidos: Cuando trabajas con conjuntos de datos compartidos en un proyecto independiente, es posible que aún necesites el permiso bigquery.jobs.create en el proyecto para ejecutar consultas o trabajos en ese conjunto de datos.

Para otorgar permiso para acceder a una tabla o vista, consulta Otorga acceso a una tabla o vista.

Problemas de recursos excedidos

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

La consulta supera los recursos de CPU

Cadena del error: Query exceeded resource limits

Este error ocurre cuando las consultas a pedido usan demasiada CPU en relación con la cantidad de datos analizados. Si deseas obtener información para resolver estos problemas, consulta Soluciona problemas de recursos excedidos.

La consulta excede los recursos de memoria

Cadena del error: Resources exceeded during query execution: The query could not be executed in the allotted memory

En las sentencias SELECT, este error se produce cuando la consulta usa demasiados recursos. Para abordar este error, consulta Soluciona problemas de recursos excedidos.

Se agotó el espacio de la pila

Cadena del error: Out of stack space due to deeply nested query expression during query resolution.

Este error puede ocurrir cuando una consulta contiene demasiadas llamadas a funciones anidadas. A veces, durante el análisis, se traducen partes de una consulta a llamadas a funciones. 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, vuelve a escribir tu consulta para reducir la cantidad de anidamiento.

Se excedieron los recursos durante la ejecución de la consulta

Cadena del error: 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 búsquedas de ORDER BY ... LIMIT ... OFFSET .... Debido a los detalles de implementación, la clasificación puede ocurrir en una sola unidad de procesamiento, que puede quedarse sin memoria si necesita procesar demasiadas filas antes de que se apliquen LIMIT y OFFSET, en especial con un OFFSET grande.

Para abordar este error, evita valores grandes de OFFSET en las consultas de ORDER BY … LIMIT. Como alternativa, usa la función analítica escalable ROW_NUMBER() para asignar rangos según el orden elegido y, luego, filtra 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 excede los recursos de Shuffle

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

Este error ocurre cuando una consulta no puede acceder a suficientes recursos de Shuffle.

Para abordar este error, aprovisiona más ranuras o reduce la cantidad de datos que procesa la consulta. Para obtener más información sobre las formas de hacerlo, consulta Cuota de Shuffle insuficiente.

Si deseas obtener información adicional para resolver estos problemas, consulta Soluciona problemas de recursos excedidos.

La consulta es demasiado compleja

Cadena del error: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

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

  • Cláusulas WITH que se anidan de forma profunda o se usan de forma repetida.
  • Vistas que se anidan de forma profunda o se usan de manera repetida.
  • Uso reiterado del operador UNION ALL.

Para resolver este error, prueba las siguientes opciones:

  • Divide la consulta en varias consultas y, luego, usa el lenguaje de procedimiento para ejecutar esas consultas en una secuencia con estado compartido.
  • Usa tablas temporales en lugar de cláusulas WITH.
  • Vuelve a escribir tu consulta para reducir la cantidad de objetos a los que se hace referencia y las comparaciones.

Puedes supervisar de forma proactiva las consultas que se acercan al límite de complejidad con el campo query_info.resource_warning en la vista INFORMATION_SCHEMA.JOBS. En el siguiente ejemplo, se muestran las consultas con un alto uso de recursos durante 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

Si deseas obtener información adicional para resolver estos problemas, consulta Soluciona problemas de recursos excedidos.

Soluciona problemas de recursos excedidos

Para los trabajos de consulta, haz lo siguiente:

Para optimizar tus consultas, prueba los siguientes pasos:

  • Intenta quitar 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. También asegúrate de que tus datos no contengan claves de unión duplicadas.
  • Si tu consulta usa FLATTEN, determina si es necesario para tu caso práctico. A fin de obtener más información, consulta los datos anidados y repetidos.
  • Si tu consulta usa EXACT_COUNT_DISTINCT, considera reemplazar este valor por COUNT(DISTINCT).
  • Si tu consulta usa COUNT(DISTINCT <value>, <n>) con un valor <n> grande, considera usar GROUP BY en su lugar. Para obtener más información, consulta COUNT(DISTINCT):
  • Si tu consulta usa UNIQUE, considera usar GROUP BY en su lugar, o una función analítica dentro de una subselección.
  • Si tu consulta materializa muchas filas mediante una cláusula LIMIT, te recomendamos filtrar en otra columna, por ejemplo, ROW_NUMBER(), o quitar la cláusula LIMIT por completo para permitir la paralelización de escritura.
  • Si tu consulta usó vistas anidadas de manera profunda y una cláusula WITH, esto puede causar 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 deba volver a calcularse varias veces, lo que puede hacer que la consulta sea compleja y, por lo tanto, lenta. Conservar los resultados intermedios en tablas temporales 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 agrega una cláusula PARTITION BY si no existe.

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

Para los trabajos de carga, haz lo siguiente:

Si cargas archivos Avro o Parquet, reduce el tamaño de las filas en los archivos. Comprueba si hay restricciones de tamaño específicas para el formato de archivo que cargas:

Si recibes este error cuando cargas archivos ORC, comunícate con el equipo de asistencia.

Para la API de Storage:

Cadena del error: Stream memory usage exceeded

Durante una llamada ReadRows a la API de lectura de almacenamiento, algunas transmisiones con uso de memoria alto pueden recibir un error RESOURCE_EXHAUSTED con este mensaje. Esto puede suceder cuando se lee desde tablas anchas o con tablas con un esquema complejo. Como resolución, reduce el tamaño de la fila resultante. Para ello, selecciona menos columnas para leer (con el parámetro selected_fields) o simplifica el esquema de la tabla.

Soluciona problemas de conectividad

En las siguientes secciones, se describe cómo solucionar problemas de conectividad cuando intentas interactuar con BigQuery:

Cómo agregar el DNS de Google a la lista de entidades permitidas

Usa la herramienta Google IP Dig para resolver el extremo 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 del firewall.

En general, recomendamos incluir en la lista de entidades permitidas los nombres de DNS de Google. Los rangos de IP que se comparten en los archivos https://www.gstatic.com/ipranges/goog.json y https://www.gstatic.com/ipranges/cloud.json cambian con frecuencia. Por lo tanto, recomendamos que agregues los nombres de DNS de Google a la lista de entidades permitidas. A continuación, se incluye una lista de nombres de DNS comunes que recomendamos agregar a la lista de entidades permitidas:

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

Identifica el proxy o el firewall que descarta paquetes

Para identificar todos los saltos de paquetes entre el cliente y Google Front End (GFE), ejecuta un comando traceroute en tu máquina cliente que pueda destacar el servidor que descarta los paquetes dirigidos al GFE. A continuación, se muestra un ejemplo de un comando traceroute:

traceroute -T -p 443 bigquery.googleapis.com

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

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 el GFE.

Si ves que los paquetes nunca llegan al GFE, comunícate con tu administrador de red para resolver este problema.

Genera un archivo PCAP y analiza tu firewall o proxy

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

Este es un comando de muestra que se puede ejecutar con la herramienta tcpdump:

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

Configura reintentos para problemas de conectividad intermitentes

En algunas situaciones, los balanceadores de cargas de GFE pueden descartar conexiones de una IP de cliente, por ejemplo, si detectan patrones de tráfico de DDoS o si se reduce la escala de la instancia del balanceador de cargas, lo que puede provocar que se recicle la IP del extremo. Si los balanceadores de cargas de GFE interrumpen la conexión, el cliente debe detectar la solicitud con tiempo de espera agotado y volver a intentarla en el extremo de DNS. Asegúrate de no usar la misma dirección IP hasta que la solicitud se realice correctamente, ya que es posible que la dirección IP haya cambiado.

Si identificaste un problema con los tiempos de espera constantes del lado de Google en los que los reintentos no ayudan, comunícate con Atención al cliente de Cloud y asegúrate de incluir un archivo PCAP nuevo generado con una herramienta de captura de paquetes como tcpdump.

¿Qué sigue?