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 Service Health 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 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.

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 raw access permissions 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:

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.

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.

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.

Este error ocurre cuando ejecutas una consulta sin el permiso bigquery.jobs.create en el proyecto en el que ejecutas la consulta, sin importar los permisos en el proyecto que contiene los datos. También debes tener el permiso bigquery.tables.getData en todas las tablas y vistas a las que hace referencia la consulta.

Este error también puede ocurrir si la tabla no existe en la región consultada, como asia-south1. Para consultar las vistas, también necesitas este permiso en todas las tablas y vistas subyacentes. Para obtener más información acerca de los permisos necesarios, consulta Ejecuta una consulta.

Cuando corrijas este error, 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.

  • Roles personalizados: Los roles personalizados de IAM deben tener el permiso bigquery.jobs.create incluido de forma explícita en el rol relevante.

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

Otorga permiso para acceder a la tabla

Para otorgar a un principio permiso para acceder a una tabla, sigue estos pasos:

  1. Ve a la página de BigQuery.

    Ir a BigQuery

  2. En Explorador, navega a la tabla a la que necesitas acceder, selecciona Ver acciones, selecciona Compartir. y, luego, haz clic en Administrar permisos.

  3. En Agregar principales, ingresa el nombre de los usuarios, grupos, dominios o cuentas de servicio que deseas agregar.

  4. En Asignar roles, selecciona el permiso bigquery.jobs.create. Como alternativa, otorgar el rol roles/bigquery.jobUser en el proyecto desde el que se realiza la consulta proporciona los permisos necesarios.

  5. Haz clic en Guardar.

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.

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.
  • 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.
  • No reemplaces las tablas temporales por cláusulas WITH. Es posible que la cláusula 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 ayuda con la complejidad
  • Evita usar consultas UNION ALL.

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 incluir en la lista de entidades permitidas el DNS de Google

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 de tu 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, te recomendamos que, en su lugar, incluyas en la lista de entidades permitidas los nombres de DNS de Google. Esta es 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 si el proxy o el firewall descartan paquetes

Para identificar todos los saltos de paquetes entre el cliente y Google Front End (GFE), ejecuta un comando traceroute en la máquina cliente que pueda destacar el servidor que descarta paquetes dirigidos al GFE. Este es un comando traceroute de muestra:

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 de Google, verás que la solicitud llega hasta el GFE.

Si ves que los paquetes nunca llegan a la GFE, comunícate con el 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 paquetes a las IP de Google y permitan que los paquetes lleguen a la 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 intermitente

Hay situaciones en las que los balanceadores de cargas de GFE pueden descartar conexiones de una IP de cliente, por ejemplo, si detecta 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 pierden la conexión, el cliente debe detectar la solicitud que se agotó el tiempo de espera y volver a intentarla en el extremo DNS. Asegúrate de no usar la misma dirección IP hasta que la solicitud se realice correctamente, ya que es posible que haya cambiado.

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

¿Qué sigue?