Soluciona problemas de cuota y de límite

BigQuery tiene varias cuotas y límites que limitan la tasa y el volumen de diferentes solicitudes y operaciones. Existen para proteger la infraestructura y ayudar a proteger contra el uso inesperado del cliente. En este documento, se describe cómo diagnosticar y mitigar errores específicos que surgen de las cuotas y los límites.

Algunos mensajes de error especifican cuotas o límites que puedes aumentar, mientras que otros especifican cuotas o límites que no puedes aumentar. Alcanzar un límite estricto significa que debes implementar soluciones alternativas temporales o permanentes, o prácticas recomendadas para tu carga de trabajo. Hacerlo es una práctica recomendada, incluso para las cuotas o los límites que se pueden aumentar.

En este documento, se organizan los mensajes de error y sus soluciones según estas categorías, y en la sección "Descripción general" que aparece más adelante en este documento, se explica cómo leer un mensaje de error y aplicar la solución correcta para tu problema.

Si tu mensaje de error no aparece en este documento, consulta la lista de mensajes de error, que tiene información más genérica sobre el error.

Descripción general

Si una operación de BigQuery falla debido a que se excede una cuota, la API muestra el código de estado HTTP 403 Forbidden. En el cuerpo de la respuesta, se incluye más información sobre la cuota que se alcanzó. El cuerpo de la respuesta es similar al siguiente:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "global",
    "message" : "Quota exceeded: ...",
    "reason" : "quotaExceeded"
  } ],
  "message" : "Quota exceeded: ..."
}

En el campo message de la carga útil, se describe qué límite se superó. Por ejemplo, el campo message podría decir Exceeded rate limits: too many table update operations for this table.

En general, los límites de cuota se dividen en dos categorías que se indican con el campo reason de la carga útil de la respuesta.

  • rateLimitExceeded: Este valor indica un límite a corto plazo. Para resolver estos problemas de límite, vuelve a intentar la operación después de unos segundos. Usa la retirada exponencial entre los reintentos. Es decir, aumenta de forma exponencial el tiempo entre cada reintento.

  • quotaExceeded: Este valor indica un límite a largo plazo. Si alcanzas un límite de cuota a largo plazo, debes esperar 10 minutos o más antes de intentar realizar la operación. Si alcanzas uno de estos límites de cuota a largo plazo con regularidad, debes analizar la carga de trabajo para descubrir cómo mitigar el problema. Las mitigaciones pueden incluir la optimización de la carga de trabajo o la solicitud de un aumento de cuota.

En el caso de los errores quotaExceeded, examina el mensaje de error para comprender qué límite de cuota se superó. Luego, analiza la carga de trabajo para ver si puedes evitar alcanzar la cuota.

En algunos casos, para aumentar la cuota, puedes comunicarte con el equipo de asistencia de BigQuery o con el equipo de Ventas de Google Cloud , pero te recomendamos que primero pruebes las sugerencias de este documento.

Diagnóstico

Para diagnosticar problemas, haz lo siguiente:

  • Usa las vistas INFORMATION_SCHEMA junto con un calificador de región para analizar el problema subyacente. Estas vistas contienen metadatos sobre tus recursos de BigQuery, como trabajos, inserciones de transmisión y reservas.

    Por ejemplo, en la siguiente consulta, se usa la vista INFORMATION_SCHEMA.JOBS para enumerar todos los errores del día anterior relacionados con la cuota:

    SELECT
job_id,
creation_time,
error_result
FROM  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND
    error_result.reason IN ('rateLimitExceeded', 'quotaExceeded')

    Reemplaza REGION_NAME por la región del proyecto. Debe ir precedido por region-. Por ejemplo, para la multirregión US, usa region-us.

  • Visualiza los errores en los Registros de auditoría de Cloud.

    Por ejemplo, si usas el explorador de registros, en la siguiente consulta, se muestran errores Quota exceeded o limit en la string del mensaje:

    resource.type = ("bigquery_project" OR "bigquery_dataset")
protoPayload.status.code ="7"
protoPayload.status.message: ("Quota exceeded" OR "limit")

    En este ejemplo, el código de estado 7 indica PERMISSION_DENIED, que corresponde al código de estado HTTP 403.

    Para obtener más muestras de consultas de los Registros de auditoría de Cloud, visita Consultas de BigQuery.

Soluciona problemas de cuotas o límites que se pueden aumentar

Puedes aumentar las siguientes cuotas y límites. Sin embargo, es mejor que primero pruebes las soluciones alternativas o las prácticas recomendadas que se sugieren.

Tu proyecto superó la cuota gratuita de análisis de bytes de consultas

BigQuery devuelve este error cuando ejecutas una consulta en el nivel de uso gratuito y la cuenta alcanza el límite mensual de consultas. Para obtener más información sobre los precios de las consultas, consulta Nivel de uso gratuito.

Mensaje de error 

Your project exceeded quota for free query bytes scanned

Solución

Para seguir usando BigQuery, debes actualizar la cuenta a una cuenta de Facturación de Cloud pagada.

Errores de cuota relacionados con la inserción de transmisión

En esta sección, se proporcionan sugerencias para solucionar problemas de errores de cuota relacionados con la transmisión de datos a BigQuery.

En ciertas regiones, las inserciones de transmisión tienen una cuota más alta si no propagas el campo insertId de cada fila. Si deseas obtener más información sobre las cuotas de las inserciones de transmisión, consulta Inserciones de transmisión. Los errores relacionados con la cuota de transmisión de BigQuery dependen de la presencia o ausencia de insertId.

Mensaje de error

Si el campo insertId está vacío, es posible que surja el siguiente error de cuota:

Límite de cuota Mensaje de error
Bytes por segundo por proyecto La entidad con gaia_id GAIA_ID, del proyecto PROJECT_ID en la región REGION superó la cuota de inserción de bytes por segundo.

Si se propaga el campo insertId, es posible que surjan los siguientes errores de cuota:

Límite de cuota Mensaje de error
Filas por segundo por proyecto El proyecto PROJECT_ID en la región REGION superó la cuota de inserción de transmisión de filas por segundo.
Filas por segundo por tabla La tabla TABLE_ID superó la cuota de inserción de transmisión de filas por segundo.
Bytes por segundo por tabla La tabla TABLE_ID superó la cuota de inserción de transmisión de bytes por segundo.

El propósito del campo insertId es anular la duplicación de las filas insertadas. Si varias inserciones con el mismo insertId llegan dentro de un período de pocos minutos, BigQuery escribe una sola versión del registro. Sin embargo, esta anulación automática de duplicación no está garantizada. Para obtener la máxima capacidad de procesamiento de transmisión, recomendamos que no incluyas insertId y, en su lugar, uses la anulación manual de duplicación. Para obtener más información, consulta Garantiza la coherencia de los datos.

Cuando encuentres este error, diagnostica el problema y, luego, sigue los pasos recomendados para resolverlo.

Diagnóstico

Usa las vistas STREAMING_TIMELINE_BY_* para analizar el tráfico de transmisión. Estas vistas agregan estadísticas de transmisión en intervalos de un minuto, agrupadas por error_code. Los errores de cuota aparecen en los resultados con error_code igual a RATE_LIMIT_EXCEEDED o QUOTA_EXCEEDED.

Según el límite de cuota específico que se haya alcanzado, observa total_rows o total_input_bytes. Si el error se produjo en una cuota a nivel de tabla, filtra por table_id.

Por ejemplo, en la siguiente consulta, se muestra el total de bytes transferidos por minuto y la cantidad total de errores de cuota:

SELECT
 start_timestamp,
 error_code,
 SUM(total_input_bytes) as sum_input_bytes,
 SUM(IF(error_code IN ('QUOTA_EXCEEDED', 'RATE_LIMIT_EXCEEDED'),
     total_requests, 0)) AS quota_error
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.STREAMING_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
GROUP BY
 start_timestamp,
 error_code
ORDER BY 1 DESC

Solución

Para resolver este error, haz lo siguiente:

  • Si usas el campo insertId para la anulación de duplicación, y tu proyecto está en una región que admite la cuota de transmisión más alta, te recomendamos que quites el campo insertId. Esta solución puede requerir algunos pasos adicionales para anular manualmente la duplicación de los datos. Para obtener más información, consulta Quita los duplicados manualmente.

  • Si no usas insertId o si no es viable quitarlo, supervisa el tráfico de transmisión durante un período de 24 horas y analiza los errores de cuota:

    • Si ves sobre todo errores RATE_LIMIT_EXCEEDED, en lugar de errores QUOTA_EXCEEDED, y el tráfico total es inferior al 80% de la cuota, es probable que los errores indiquen aumentos de tráfico temporales. Puedes abordar estos errores si reintentas la operación mediante una retirada exponencial entre los reintentos.

    • Si usas un trabajo de Dataflow para insertar datos, considera usar trabajos de carga en lugar de inserciones de transmisión. Para obtener más información, consulta Configura el método de inserción. Si usas Dataflow con un conector de E/S personalizado, considera usar un conector de E/S integrado en su lugar. Para obtener más información, consulta Patrones de E/S personalizados.

    • Si ves errores QUOTA_EXCEEDED o si el tráfico total supera el 80% de la cuota de forma constante, envía una solicitud de aumento de cuota. Para obtener más información, consulta Solicita un ajuste de cuota.

    • También puedes considerar reemplazar las inserciones de transmisión con la API de Storage Write más reciente, que tiene una capacidad de procesamiento mayor, un precio más bajo y muchas funciones útiles.

Para obtener más información sobre las inserciones de transmisión, consulta Transmite datos a BigQuery.

Cantidad máxima de consultas simultáneas que contienen funciones remotas

BigQuery muestra este error cuando la cantidad de consultas simultáneas que contienen funciones remotas supera el límite.

Para obtener más información sobre los límites de las funciones remotas, consulta Funciones remotas.

Mensaje de error

Exceeded rate limits: too many concurrent queries with remote functions for
this project

Este límite se puede aumentar. Primero, prueba las soluciones alternativas y las prácticas recomendadas.

Diagnóstico

Para ver los límites de las consultas simultáneas que contienen funciones remotas, consulta Límites de funciones remotas.

Solución

  • Cuando uses funciones remotas, cumple con las prácticas recomendadas para las funciones remotas.
  • Para solicitar un aumento de cuota, comunícate con el equipo de asistencia o el de Ventas. La revisión y el procesamiento de la solicitud pueden tardar varios días. Recomendamos indicar la prioridad, el caso de uso y el ID del proyecto en la solicitud.

Cantidad máxima de declaraciones CREATE MODEL

Este error significa que superaste la cuota de las declaraciones CREATE MODEL.

Mensaje de error

Quota exceeded: Your project exceeded quota for CREATE MODEL queries per
 project.

Solución

Si superas la cuota de las declaraciones CREATE MODEL, envía un correo electrónico a bqml-feedback@google.com y solicita un aumento de la cuota.

Errores de cuota de la cantidad máxima de trabajos de copia por día por errores

BigQuery muestra este error cuando la cantidad de trabajos de copia que se ejecutan en un proyecto superó el límite diario. Para obtener más información sobre el límite de trabajos de copia por día, consulta Trabajos de copia.

Mensaje de error

Your project exceeded quota for copies per project

Diagnóstico

Si deseas recopilar más datos sobre el origen de los trabajos de copia, puedes probar lo siguiente:

  • Si tus trabajos de copia se encuentran en una sola región o en pocas regiones, puedes intentar consultar la tabla INFORMATION_SCHEMA.JOBS para regiones específicas. Por ejemplo:

    SELECT
creation_time, job_id, user_email, destination_table.project_id, destination_table.dataset_id, destination_table.table_id
FROM `PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 2 DAY) AND CURRENT_TIMESTAMP()
AND job_type = "COPY"
order by creation_time DESC

    También puedes ajustar el intervalo según el rango de tiempo que te interese.

  • Para ver todos los trabajos de copia en todas las regiones, puedes usar el siguiente filtro en Cloud Logging: 

    resource.type="bigquery_resource"
protoPayload.methodName="jobservice.insert"
protoPayload.serviceData.jobInsertRequest.resource.jobConfiguration.tableCopy:*

Solución

  • Si el objetivo de las operaciones de copia frecuentes es crear una instantánea de datos, considera usar instantáneas de tabla en su lugar. Las instantáneas de tablas son una alternativa más económica y rápida para copiar tablas completas.
  • Para solicitar un aumento de cuota, comunícate con el equipo de asistencia o el de Ventas. La revisión y el procesamiento de la solicitud pueden tardar varios días. Recomendamos indicar la prioridad, el caso de uso y el ID del proyecto en la solicitud.

Error de cuota de bytes de extracción por día excedida

BigQuery devuelve este error cuando la extracción supera el límite diario predeterminado de 50 TiB en un proyecto. Para obtener más información sobre los límites de los trabajos de extracción, consulta Trabajos de extracción.

Mensaje de error

Your usage exceeded quota for ExtractBytesPerDay

Diagnóstico

Si exportas una tabla que supera los 50 TiB, la exportación fallará porque supera el límite de extracción. Si deseas exportar datos de tablas para particiones de tablas específicas, puedes usar un decorador de particiones para identificar las particiones que se exportarán.

Si quieres recopilar los usos de los datos de exportación de los últimos días, puedes probar lo siguiente:

  • Consulta las cuotas de tu proyecto con criterios de filtro, como Name: Extract bytes per day o Metric: bigquery.googleapis.com/quota/extract/bytes, junto con el gráfico Mostrar uso para ver tu tendencia de uso durante algunos días.

  • Como alternativa, puedes consultar INFORMATION_SCHEMA.JOBS_BY_PROJECT para ver el total de bytes extraídos durante unos días. Por ejemplo, la siguiente consulta devuelve el total de bytes diarios procesados por los trabajos de EXTRACT en los últimos siete días.

    SELECT
TIMESTAMP_TRUNC(creation_time, DAY) AS day,
SUM ( total_bytes_processed ) / POW(1024, 3) AS total_gibibytes_processed
FROM
`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
AND job_type = "EXTRACT"
GROUP BY 1
ORDER BY 2 DESC

  • Luego, puedes definir mejor los resultados identificando los trabajos específicos que consumen más bytes de lo esperado. En el siguiente ejemplo, se muestran los 100 trabajos de EXTRACT principales que consumen más de 100 GB procesados en los últimos siete días.

    SELECT
creation_time,
job_id,
total_bytes_processed/POW(1024, 3) AS total_gigabytes_processed
FROM
`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
AND job_type="EXTRACT"
AND total_bytes_processed > (POW(1024, 3) * 100)
ORDER BY
total_bytes_processed DESC
LIMIT 100

Como alternativa, puedes usar el explorador de trabajos con filtros como Bytes processed more than para filtrar los trabajos de procesamiento alto durante un período específico.

Solución

Un método para resolver este error de cuota es crear una reserva de ranuras y asignar tu proyecto a la reserva con el tipo de trabajo PIPELINE. Este método puede omitir la verificación de límites, ya que usa tus reservas dedicadas en lugar de un grupo de ranuras compartido gratuito. Si es necesario, la reserva se puede borrar si deseas usar un grupo de ranuras compartidas más adelante.

Para conocer enfoques alternativos que permitan exportar más de 50 TiB, consulta la sección de notas en Trabajos de extracción.

Errores de cuota máxima de bytes por segundo por proyecto de tabledata.list

BigQuery muestra este error cuando el número de proyecto mencionado en el mensaje de error alcanza el tamaño máximo de datos que se pueden leer a través de la llamada a la API tabledata.list en un proyecto por segundo. Para obtener más información, consulta Cantidad máxima de bytes de tabledata.list por minuto.

Mensaje de error

Your project:[project number] exceeded quota for tabledata.list bytes per second per project

Solución

Para resolver este error, haz lo siguiente:

  • En general, recomendamos que intentes mantenerte por debajo de este límite. Por ejemplo, mediante el espaciado de solicitudes durante un período más largo con retrasos. Si el error no ocurre con frecuencia, la implementación de reintentos con retirada exponencial resuelve este problema.
  • Si el caso de uso espera una lectura rápida y frecuente de una gran cantidad de datos de una tabla, recomendamos usar la API de lectura de almacenamiento de BigQuery en lugar de la API de tabledata.list.

  • Si las sugerencias anteriores no funcionan, puedes solicitar un aumento de cuota desde el panel de la API de la consola deGoogle Cloud . Para ello, haz lo siguiente:

    1. Ve al panel de la API de la consola deGoogle Cloud .
    2. En el panel, filtra por cuota: Tabledata list bytes per minute (default quota).
    3. Selecciona la cuota y sigue las instrucciones que aparecen en Solicita un ajuste de cuota.

    La revisión y el procesamiento de la solicitud pueden tardar varios días.

Cantidad máxima de errores de límite de solicitudes a la API

BigQuery devuelve este error cuando alcanzas el límite de frecuencia para la cantidad de solicitudes a la API a una API de BigQuery por usuario por método (por ejemplo, las llamadas al método tables.get desde una cuenta de servicio, o las llamadas al método jobs.insert desde un correo electrónico de usuario diferente).

La mayoría de los métodos principales de la API de BigQuery tienen un máximo de 100 solicitudes a la API por usuario y por método. Sin embargo, algunos de estos métodos principales pueden tener diferentes límites de frecuencia, por ejemplo:

Además, los límites de frecuencia de la API de BigQuery no se aplican a las inserciones de transmisión.

Para obtener más información sobre los límites de frecuencia individuales, consulta el límite de frecuencia de la cantidad máxima de solicitudes a la API por segundo por usuario y por método.

Mensaje de error 

Quota exceeded: Your user_method exceeded quota for concurrent api requests
per user per method.

Cuando encuentres este error, diagnostica el problema y, luego, sigue los pasos recomendados para resolverlo.

Si el error tiene el motivo apiLimitExceeded, consulta Errores de límite de evaluación de metadatos y tasa de API o, para errores de réplica de conjuntos de datos, Errores de límite de creación de réplicas de conjuntos de datos entre regiones.

Diagnóstico

Si no identificaste el método que alcanzó este límite de frecuencia, haz lo siguiente:

Para la cuenta de servicio

  1. Ve al proyecto que aloja la cuenta de servicio.

  2. En la consola de Google Cloud , ve al Panel de la API.

    Si deseas obtener instrucciones para ver la información de uso detallada de una API, consulta Usa el panel de la API.

  3. En el panel de la API, selecciona API de BigQuery.

  4. Para ver información de uso más detallada, selecciona Métricas y, luego, haz lo siguiente:

    1. En Seleccionar gráficos, selecciona Tráfico por método de API.

    2. Filtra el gráfico por las credenciales de la cuenta de servicio. Es posible que veas aumentos repentinos en un método en el período en el que detectaste el error.

Para las llamadas a la API

Algunas llamadas a la API registran errores en los registros de auditoría de BigQuery en Cloud Logging. Para identificar el método que alcanzó el límite, haz lo siguiente:

  1. En la consola de Google Cloud , ve al menú de navegación de Google Cloud y, luego, selecciona Logging > Explorador de registros para tu proyecto:

    Ir al Explorador de registros.

  2. Ejecuta la siguiente consulta para filtrar registros:

     resource.type="bigquery_resource"
 protoPayload.authenticationInfo.principalEmail="<user email or service account>"
 "Too many API requests per user per method for this user_method"
 In the log entry, you can find the method name under the property protoPayload.method_name.

    Para obtener más información, consulta la descripción general de los registros de auditoría de BigQuery.

Solución

Para resolver este error, haz lo siguiente:

  • Reduce la cantidad de solicitudes a la API o agrega un retraso entre las solicitudes para que la cantidad de solicitudes permanezca por debajo de este límite.

  • Si el límite solo se excede en ocasiones, puedes implementar reintentos en este error específico con una retirada exponencial.

  • Si insertas datos con frecuencia, considera usar la API de BigQuery Storage Write (gRPC). La transmisión de datos con esta API no se ve afectada por la cuota de la API de BigQuery.

  • Mientras cargas datos en BigQuery con Dataflow y el conector de E/S de BigQuery, es posible que encuentres este error para el método tables.get. Para solucionar este problema, haz lo siguiente:

    • Establece la disposición de creación de la tabla de destino en CREATE_NEVER. Para obtener más información, consulta Crea la disposición.

    • Usa la versión 2.24.0 o una superior del SDK de Apache Beam. En las versiones anteriores del SDK, la disposición CREATE_IF_NEEDED llama al método tables.get para verificar si la tabla existe.

    • Si deseas obtener una cuota adicional, consulta Solicita un aumento de la cuota. Una solicitud de aumento de cuota puede tardar varios días en procesarse. Para proporcionar más información sobre tu solicitud, te recomendamos que incluya la prioridad del trabajo, el usuario que ejecuta la consulta y el método afectado.

Errores de límite de evaluación de metadatos y frecuencia de la API

BigQuery devuelve un error de HTTP 403 Forbidden con el motivo apiLimitExceeded cuando una solicitud supera los límites de frecuencia de la API o los límites de evaluación de acceso y metadatos simultáneos.

Mensajes de error

  • Quota exceeded for the project...
  • API limit exceeded: Quota exceeded for quota metric 'Read requests'...

Diagnóstico

Este error puede ocurrir en las siguientes situaciones:

  • Gran volumen de solicitudes a la API simultáneas Una aplicación envía una ráfaga de llamadas a la API simultáneas (como jobs.insert, tables.get o un sondeo rápido del estado del trabajo) que supera los límites de solicitudes a la API de BigQuery.
  • Simultaneidad de BigLake Metastore. Las consultas en tablas externas respaldadas por BigLake Metastore generan un gran volumen de solicitudes de lectura de metadatos simultáneas.
  • Evaluación compleja de IAM o de seguridad a nivel de la fila. Las consultas simultáneas hacen referencia a una gran cantidad de conjuntos de datos, tablas o políticas de seguridad a nivel de fila (RLS), lo que agota los límites de evaluación de acceso del backend.

Si el mensaje de error es Quota exceeded: Your user_method exceeded quota for concurrent api requests per user per method, consulta Cantidad máxima de errores de límite de solicitudes a la API.

Solución

Para resolver este error, haz lo siguiente:

  • Vuelve a intentarlo con una retirada exponencial truncada. Configura tu aplicación cliente o secuencia de comandos para volver a intentar las solicitudes con errores mediante la retirada exponencial truncada.
  • Agrupa por lotes y consolida las operaciones de la API. Carga o consulta datos en lotes más grandes y menos frecuentes, en lugar de emitir llamadas a la API de alta frecuencia de una sola fila o por tabla, y reduce la frecuencia de las llamadas de sondeo de jobs.get.
  • Simplifica la IAM y los parámetros de configuración de seguridad. Prefiere los Grupos de Google y las vinculaciones de roles de IAM a nivel de conjunto de datos en lugar de grandes cantidades de vinculaciones de IAM detalladas por tabla o políticas de seguridad superpuestas a nivel de fila para reducir la sobrecarga de la verificación de acceso.
  • Verifica el uso de la cuota en la consola de Google Cloud . Revisa la página Cuotas y límites del sistema para identificar si se está alcanzando una cuota ajustable de la API de BigQuery o BigLake. Si necesitas más capacidad de forma sostenida, solicita un ajuste de cuota.

Cantidad máxima de bytes de almacenamiento de imágenes de UDF de Python por proyecto y por región

El tamaño total de todas las imágenes de contenedor almacenadas que usan las UDF de Python activas no puede superar los 10 GiB por proyecto y por región. Este límite se aplica cuando creas o actualizas una UDF de Python. Si el tamaño total supera el límite regional, la solicitud falla de inmediato y se devuelve el siguiente error.

Mensaje de error

Resources exceeded during query execution: Quota exceeded: Your project: PROJECT_ID exceeded quota for Python UDF image storage usage per region per project.

Solución

Para resolver este error, haz lo siguiente:

  1. Solicita un aumento: ve a la página Cuotas y límites del sistema, busca el límite de Python UDF image storage bytes per project per region y, luego, solicita un aumento.

  2. Optimiza el almacenamiento: borra las UDF de Python sin usar con la sentencia DROP FUNCTION para liberar espacio. Después de borrar una UDF, el tamaño de su imagen ya no se tiene en cuenta para la cuota. Puedes encontrar el tamaño de la imagen con el método RoutineBuildStatus de la API. Para obtener más información sobre cómo ver el estado de la compilación, consulta Estado de la compilación del contenedor.

Cantidad máxima de UDF de Python simultáneas

Tienes un límite de 10 UDF de Python simultáneas por proyecto. Si ejecutas más de 10, recibirás el siguiente error.

Mensaje de error

Exceeded rate limits: too many concurrent queries with Python UDFs in this project. Your project: PROJECT_ID exceeded quota for maximum concurrent Python UDFs per project.

Para ver todas las cuotas de las UDF de Python, consulta Rutinas en la referencia de cuotas y límites.

Solución

Para resolver este error, puedes solicitar un aumento de cuota comunicándote con el equipo de asistencia o el de ventas. La revisión y el procesamiento de la solicitud pueden tardar varios días. Recomendamos indicar la prioridad, el caso de uso y el ID del proyecto en la solicitud.

Límites de frecuencia de ejecución de UDF de Python o errores de capacidad

Este error ocurre cuando una consulta que invoca una UDF de Python supera los límites de frecuencia o la capacidad máxima de escalamiento de contenedores para la UDF. Por lo general, este problema ocurre en las siguientes situaciones:

  • Una consulta procesa un gran volumen de datos con un alto paralelismo.
  • Cada instancia de contenedor está configurada para controlar una pequeña cantidad de solicitudes simultáneas.
  • Las invocaciones de UDF individuales tardan mucho tiempo en completarse.

Mensaje de error

Resources exceeded during query execution: Python user-defined function execution exceeded rate limits or capacity. Check https://docs.cloud.google.com/bigquery/docs/troubleshoot-quotas for more details.

Solución

Para resolver este error, intenta lo siguiente:

  • Ajusta los límites de los contenedores: Verifica las métricas de las UDF de Python en Cloud Monitoring para inspeccionar el uso de CPU, el uso de memoria y las solicitudes simultáneas. Si container_request_concurrency se establece en un valor bajo, auméntalo para que cada instancia de contenedor pueda procesar más solicitudes en paralelo. Si container_cpu se establece en menos de 1.0 CPU virtual sin un valor de container_request_concurrency explícito, la simultaneidad se establece de forma predeterminada en 1 en el entorno de ejecución. Para obtener más información, consulta Configura límites de contenedores para las UDF de Python.
  • Optimiza la ejecución de las UDF y la estructura de las consultas: Sigue las prácticas recomendadas para las UDF de Python con el objetivo de reducir el tiempo de ejecución y el volumen de solicitudes por consulta. Por ejemplo, filtra tus datos antes de invocar la UDF, mantén pequeñas las cargas útiles de las filas de entrada y estructura tu consulta para que admita el procesamiento por lotes.
  • Solicita un aumento de capacidad: Si el error persiste después de optimizar la UDF, comunícate con el equipo de asistencia o ventas para solicitar un límite de escalamiento de contenedores más alto. Incluye la prioridad, el caso de uso y el ID del proyecto en tu solicitud.

Soluciona problemas de cuotas o límites que no se pueden aumentar

No puedes aumentar las siguientes cuotas o límites, pero puedes aplicar las soluciones alternativas o las prácticas recomendadas que se sugieren para mitigarlos.

Se superó el límite de instantáneas de la tabla

Este error se produce cuando una tabla de BigQuery supera la cantidad máxima de instantáneas de tabla permitidas en un período de 24 horas. Este es un límite a nivel de tabla, lo que significa que se aplica a cada tabla individual de tu proyecto.

Para obtener más información sobre los límites de las operaciones de tabla por día, consulta Tablas estándar.

Este límite no se puede aumentar.

Mensaje de error

Your table exceeded quota for SNAPSHOT operations per table

Solución

Para resolver este error, considera las siguientes acciones:

  • Reduce la cantidad de operaciones de instantánea realizadas en la tabla afectada en un período de 24 horas.
  • Si no puedes reducir la frecuencia de las instantáneas, comunícate con el equipo de Atención al cliente de Cloud o con tu administrador técnico de cuentas.

Errores de cantidad máxima de trabajos pendientes

Este límite no se puede aumentar.

Mensaje de error

Quota exceeded: concurrent number of jobs that can be in the pending state

Solución

No se puede aumentar esta cuota.

Para resolver este error, haz lo siguiente:

  • Reduce la tasa de envío: Reduce la tasa con la que envías trabajos a BigQuery.
  • Limita la simultaneidad: Evita enviar una gran cantidad de trabajos en paralelo que puedan quedar bloqueados en el estado pendiente.

Errores de límite de colas de consultas

Es posible que aparezca este error si un proyecto pone en cola más consultas interactivas o por lotes de lo que permite su límite de colas.

Mensaje de error

Quota exceeded: Your project and region exceeded quota for max number of jobs
that can be queued per project.

Solución

Este límite no se puede aumentar. Para resolver este error, consulta la siguiente guía general. Para las consultas interactivas de gran volumen, consulta Evita los límites para las consultas interactivas de gran volumen.

  • Pausa el trabajo. Si identificas un proceso o una canalización responsable de un aumento en las consultas, pausa ese proceso o canalización.
  • Distribuye los tiempos de ejecución. Distribuye la carga en un período más largo. Si tu solución de informes necesita ejecutar muchas consultas, intenta incorporar aleatoriedad para cuando comiencen las consultas. Por ejemplo, no inicies todos los informes al mismo tiempo.

  • Optimiza las consultas y el modelo de datos. A menudo, una consulta se puede reescribir para que se ejecute de manera más eficiente.

    Por ejemplo, si tu consulta contiene una expresión de tabla común (CTE), una cláusula WITH, a la que se hace referencia en más de un lugar en la consulta, este cálculo se realiza varias veces. Es mejor conservar los cálculos que realiza la CTE en una tabla temporal y, luego, hacer referencia a ella en la consulta.

    Las uniones múltiples también pueden ser la fuente de falta de eficiencia. En este caso, es posible que quieras considerar el uso de columnas anidadas y repetidas. Usar esto a menudo mejora la localidad de los datos, elimina la necesidad de algunas uniones y, en general, reduce el consumo de recursos y el tiempo de ejecución de la consulta.

    La optimización de las consultas las hace más económicas, por lo que, cuando usas precios basados en la capacidad, puedes ejecutar más consultas con las ranuras. Para obtener más información, consulta Introducción a la optimización del rendimiento de las consultas.

  • Optimiza el modelo de consulta. BigQuery no es una base de datos relacional. No está optimizado para una cantidad infinita de consultas pequeñas. Si ejecutas una gran cantidad de consultas pequeñas, se agotan rápidamente tus cuotas. Estas consultas no se ejecutan de la manera tan eficiente como lo hacen con los productos de base de datos más pequeños. BigQuery es un almacén de datos grande y este es su caso práctico principal. El rendimiento es mejor con consultas analíticas sobre grandes cantidades de datos.

    Usa las recomendaciones de la siguiente lista para optimizar el modelo de consulta y evitar alcanzar el límite de la cola de consultas.

    • Conserva datos (tablas guardadas). Procesa de manera previa los datos en BigQuery y almacénalos en tablas adicionales. Por ejemplo, si ejecutas muchas consultas similares con procesamiento intensivo con diferentes condiciones WHERE, sus resultados no se almacenarán en caché. Estas consultas también consumen recursos cada vez que se ejecutan. Puedes mejorar el rendimiento de esas consultas y disminuir su tiempo de procesamiento si procesas con anterioridad los datos y los almacenas en una tabla. Estos datos procesados con anterioridad en la tabla se pueden consultar con consultas SELECT. A menudo, se puede realizar durante la transferencia dentro del proceso de ETL o con las consultas programadas o vistas materializadas.
    • Usa el modo de ejecución de prueba. Ejecuta consultas en modo de ejecución de prueba, con lo que se calcula la cantidad de bytes leídos, pero que no se procesa la consulta.
    • Obtener la vista previa de los datos en la tabla Para experimentar con los datos o explorarlos en lugar de ejecutar consultas, obtén una vista previa de los datos de tablas con la función de vista previa de tablas en BigQuery.
    • Usa los resultados de las consultas en caché. Todos los resultados de consultas, incluidas las consultas interactivas y por lotes, se almacenan en caché en tablas temporales durante unas 24 horas, con algunas excepciones. Si bien la ejecución de una consulta almacenada en caché aún se considera para el límite de consultas simultáneas, las consultas que usan los resultados en caché son mucho más rápidas que las consultas que no usan resultados almacenados en caché porque BigQuery no necesita procesar el conjunto de resultados.
    • Usa BigQuery BI Engine. Si encontraste este error mientras usas una herramienta de inteligencia empresarial (IE) para crear paneles que consultan datos en BigQuery, te recomendamos que uses BigQuery BI Engine. El uso de BigQuery BI Engine es óptimo para este caso práctico.

  • Usa trabajos con prioridad de lote. Puedes poner en cola más consultas por lotes que consultas interactivas.

  • Distribuye consultas. Organiza y distribuye la carga en diferentes proyectos según la naturaleza de tus consultas y las necesidades de tu empresa.

  • Aumenta las ranuras de tu reserva. Aumenta las ranuras o, si tienes una carga de trabajo de alta demanda, cambia a reservas (modelo basado en la capacidad) desde a pedido (modelo de pago por consulta).

Evita los límites para las consultas interactivas de gran volumen

Ejecutar consultas interactivas de gran volumen puede hacer que esas consultas alcancen el límite de la cantidad máxima de consultas interactivas en cola. Este límite no se puede aumentar.

Si ejecutas consultas interactivas de gran volumen, en especial en situaciones que involucran activadores automatizados, como Cloud Run Functions, primero supervisa el comportamiento de la función de Cloud Run que causa el error y detenla. Luego, usa una de las siguientes estrategias recomendadas para evitar este límite:

  • Aumenta las ranuras en tu reserva. Si tienes una carga de trabajo de alta demanda, cambia a reservas (modelo basado en la capacidad) desde el modelo a pedido (modelo de pago por consulta).
  • Distribuye la carga de trabajo entre las consultas interactivas.
  • Debido a que puedes poner en cola más consultas por lotes que consultas interactivas, usa trabajos con prioridad por lotes en lugar de consultas interactivas.

Errores de límite de tamaño de Shuffle

BigQuery muestra este error cuando tu proyecto excede el límite máximo de disco y tamaño de memoria disponible para las operaciones de Shuffle.

Esta cuota se calcula por reserva y se divide en proyectos para las reservas. El servicio de Atención al cliente de Cloud no puede modificar la cuota. Para obtener más información sobre tu uso, consulta la vista INFORMATION_SCHEMA.JOBS_TIMELINE.

Si usas el modelo de precios a pedido, estás limitado a un máximo de 2,000 ranuras. Para aumentar la cantidad de ranuras, debes cambiar a un modelo de precios basado en la capacidad.

Mensaje de error

Tal vez recibas alguno de los siguientes mensajes de error:

Quota exceeded: Your project exceeded quota for total shuffle size limit.
 
Resources exceeded: Your project or organization exceeded the maximum
  disk and memory limit available for shuffle operations. Consider provisioning
  more slots, reducing query concurrency, or using more efficient logic in this
  job.

Solución

Para resolver este error, haz lo siguiente:

Cantidad de modificaciones de particiones para errores de cuotas de tablas particionadas por columnas

BigQuery muestra este error cuando tu tabla particionada por columnas alcanza la cuota de la cantidad de modificaciones de partición permitidas por día. Las modificaciones de partición incluyen el total de todos los trabajos de carga, Trabajos de copia y Trabajos de consulta que agregan o reemplazan una partición de destino.

Para ver el valor del límite para la cantidad de modificaciones de partición por tabla particionada por columnas por día, consulta Tablas particionadas.

Mensaje de error

Quota exceeded: Your table exceeded quota for
Number of partition modifications to a column partitioned table

Solución

No se puede aumentar esta cuota. Para resolver este error, haz lo siguiente:

  • Cambia la partición en la tabla para tener más datos en cada partición a fin de disminuir la cantidad total de particiones. Por ejemplo, cambia de partición por día a partición por mes o cambia la forma en que particionas la tabla.
  • Usa el agrupamiento en clústeres en lugar de la partición.
  • Si frecuentemente cargas datos de varios archivos pequeños almacenados en Cloud Storage que usan un trabajo por archivo, combina varios trabajos de carga en un solo trabajo. Puedes cargar desde varios URI de Cloud Storage con una lista separada por comas (por ejemplo, gs://my_path/file_1,gs://my_path/file_2) o mediante comodines (por ejemplo, gs://my_path/*).

    Para obtener más información, consulta Carga datos por lotes.

  • Si usas trabajos de carga, selección o copia para agregar filas individuales de datos a una tabla, por ejemplo, deberías considerar agrupar varios trabajos en uno solo. BigQuery no funciona bien cuando se usa como base de datos relacional. Como práctica recomendada, evita ejecutar acciones frecuentes de agregado de una sola fila.
  • Para agregar datos a una frecuencia alta, considera usar la API de BigQuery Storage Write (gRPC). Es una solución recomendada para la transferencia de datos de alto rendimiento. La API de BigQuery Storage Write (gRPC) cuenta con características sólidas, como la semántica de entrega del tipo “exactamente una vez”. Para obtener información sobre los límites y las cuotas, consulta lo siguiente API de Storage Write, y para ver los costos de usar esta API, consulta Precios de la transferencia de datos en BigQuery.
  • Para supervisar la cantidad de particiones modificadas en una tabla, usa la vista INFORMATION_SCHEMA.
  • Para obtener información sobre cómo optimizar los trabajos de carga de tablas para evitar alcanzar los límites de cuota, consulta Optimiza los trabajos de carga.

Frecuencia máxima de errores de límite de operaciones de actualización de metadatos en la tabla

BigQuery muestra este error cuando tu tabla alcanza el límite de frecuencia máxima de operaciones de actualización de metadatos en la tabla para tablas estándar. Las operaciones de la tabla incluyen el total combinado de todos los trabajos de carga, trabajos de copia y trabajos de consulta que agregan o reemplazan una tabla de destino o que usan una declaración DML DELETE, INSERT, MERGE, TRUNCATE TABLE o UPDATE para escribir datos en una tabla.

Para ver el valor del límite para la Frecuencia máxima de operaciones de actualización de metadatos en la tabla por tabla, consulta Tablas estándar.

Mensaje de error

Exceeded rate limits: too many table update operations for this table

Cuando encuentres este error, diagnostica el problema y, luego, sigue los pasos recomendados para resolverlo.

Diagnóstico

Las actualizaciones de la tabla de metadatos pueden originarse a partir de llamadas a la API que modifican los metadatos de una tabla o de trabajos que modifican el contenido de una tabla. Si no identificaste la fuente desde la que se origina la mayoría de las operaciones de actualización en los metadatos de una tabla, haz lo siguiente:

Identifica llamadas a la API

  1. Ve al menú de navegación de Google Cloud y, luego, selecciona Logging > Explorador de registros:

    Ir al Explorador de registros.

  2. Ejecuta la siguiente consulta para filtrar los registros y ver las operaciones de tabla:

    resource.type="bigquery_dataset"
protoPayload.resourceName="projects/my-project-id/datasets/my_dataset/tables/my_table"
(protoPayload.methodName="google.cloud.bigquery.v2.TableService.PatchTable" OR
protoPayload.methodName="google.cloud.bigquery.v2.TableService.UpdateTable" OR
protoPayload.methodName="google.cloud.bigquery.v2.TableService.InsertTable")
Identifica trabajos

En la siguiente consulta, se muestra una lista de trabajos que modifican la tabla afectada en el proyecto en el último día. Si esperas que varios proyectos de una organización escriban en la tabla, reemplaza JOBS_BY_PROJECT por JOBS_BY_ORGANIZATION.

SELECT
 job_id,
 user_email,
 query
FROM  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
AND destination_table.project_id = "my-project-id"
AND destination_table.dataset_id = "my_dataset"
AND destination_table.table_id = "my_table"

Para obtener más información, consulta la descripción general de los registros de auditoría de BigQuery.

Solución

No se puede aumentar esta cuota. Para resolver este error, haz lo siguiente:

  • Reduce la frecuencia de actualización para los metadatos en la tabla.
  • Agrega un retraso entre los trabajos o las operaciones de tabla para asegurarte de que la frecuencia de actualización esté dentro del límite.

  • Para inserciones o modificaciones de datos, considera usar operaciones DML. Las operaciones DML no se ven afectadas por el límite de frecuencia de la frecuencia máxima de operaciones de actualización de metadatos en la tabla por tabla.

    Las operaciones DML tienen otros límites y cuotas. Para obtener más información, consulta Usa el lenguaje de manipulación de datos (DML).

  • Si frecuentemente cargas datos de varios archivos pequeños almacenados en Cloud Storage que usan un trabajo por archivo, combina varios trabajos de carga en un solo trabajo. Puedes cargar desde varios URI de Cloud Storage con una lista separada por comas (por ejemplo, gs://my_path/file_1,gs://my_path/file_2) o mediante comodines (por ejemplo, gs://my_path/*).

    Para obtener más información, consulta Carga datos por lotes.

  • Si usas trabajos de carga, selección o copia para agregar filas individuales de datos a una tabla, por ejemplo, deberías considerar agrupar varios trabajos en uno solo. BigQuery no funciona bien cuando se usa como base de datos relacional. Como práctica recomendada, evita ejecutar acciones frecuentes de agregado de una sola fila.
  • Para agregar datos a una frecuencia alta, considera usar la API de BigQuery Storage Write (gRPC). Es una solución recomendada para la transferencia de datos de alto rendimiento. La API de BigQuery Storage Write (gRPC) cuenta con características sólidas, como la semántica de entrega del tipo “exactamente una vez”. Para obtener información sobre los límites y las cuotas, consulta lo siguiente API de Storage Write, y para ver los costos de usar esta API, consulta Precios de la transferencia de datos en BigQuery.
  • Para supervisar la cantidad de particiones modificadas en una tabla, usa la vista INFORMATION_SCHEMA.
  • Para obtener información sobre cómo optimizar los trabajos de carga de tablas para evitar alcanzar los límites de cuota, consulta Optimiza los trabajos de carga.

La tabla importa o consulta los errores de cuota anexados.

BigQuery muestra este mensaje de error cuando tu tabla alcanza el límite de operaciones de tabla por día para las tablas estándar. Las operaciones de tabla incluyen el total combinado de todos los trabajos de carga, Trabajos de copia y Trabajos de consulta que agregan o reemplazar una tabla de destino.

Para ver el valor del límite de operaciones de tabla por día, consulta Tablas estándar.

Mensaje de error

Your table exceeded quota for imports or query appends per table

Cuando encuentres este error, diagnostica el problema y, luego, sigue los pasos recomendados para resolverlo.

Diagnóstico

Si no identificaste la fuente desde la que se origina la mayoría de las operaciones de tabla, haz lo siguiente:

  1. Toma nota del proyecto, el conjunto de datos y la tabla en la que escribe la consulta, la carga o el trabajo de copia con errores.

  2. Usa las tablas INFORMATION_SCHEMA.JOBS_BY_* para obtener más información sobre los trabajos que modifican la tabla.

    En el siguiente ejemplo, se encuentra el recuento de trabajos agrupados por tipo de trabajo por el último período de 24 horas con JOBS_BY_PROJECT. Si esperas que varios proyectos escriban en la tabla, reemplaza JOBS_BY_PROJECT por JOBS_BY_ORGANIZATION.

    SELECT
TIMESTAMP_TRUNC(creation_time, HOUR),
job_type,
count(1)
FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
AND destination_table.project_id = "my-project-id"
AND destination_table.dataset_id = "my_dataset"
AND destination_table.table_id = "my_table"
GROUP BY 1, 2
ORDER BY 1 DESC

Solución

No se puede aumentar esta cuota. Para resolver este error, haz lo siguiente:

  • Si frecuentemente cargas datos de varios archivos pequeños almacenados en Cloud Storage que usan un trabajo por archivo, combina varios trabajos de carga en un solo trabajo. Puedes cargar desde varios URI de Cloud Storage con una lista separada por comas (por ejemplo, gs://my_path/file_1,gs://my_path/file_2) o mediante comodines (por ejemplo, gs://my_path/*).

    Para obtener más información, consulta Carga datos por lotes.

  • Si usas trabajos de carga, selección o copia para agregar filas individuales de datos a una tabla, por ejemplo, deberías considerar agrupar varios trabajos en uno solo. BigQuery no funciona bien cuando se usa como base de datos relacional. Como práctica recomendada, evita ejecutar acciones frecuentes de agregado de una sola fila.
  • Para agregar datos a una frecuencia alta, considera usar la API de BigQuery Storage Write (gRPC). Es una solución recomendada para la transferencia de datos de alto rendimiento. La API de BigQuery Storage Write (gRPC) cuenta con características sólidas, como la semántica de entrega del tipo “exactamente una vez”. Para obtener información sobre los límites y las cuotas, consulta lo siguiente API de Storage Write, y para ver los costos de usar esta API, consulta Precios de la transferencia de datos en BigQuery.
  • Para supervisar la cantidad de particiones modificadas en una tabla, usa la vista INFORMATION_SCHEMA.
  • Para obtener información sobre cómo optimizar los trabajos de carga de tablas para evitar alcanzar los límites de cuota, consulta Optimiza los trabajos de carga.

Se superó la cuota para la métrica de cuota "Vistas autorizadas por conjunto de datos" y el límite "2500".

Si la lista de control de acceso de un conjunto de datos supera el límite combinado de recursos autorizados, BigQuery devuelve este mensaje de error.

Mensaje de error

Quota exceeded for quota metric 'Authorized Views per dataset' and limit '2500'.

Solución

La lista de control de acceso de un conjunto de datos puede tener hasta 2,500 recursos autorizados en total, incluidas las vistas autorizadas, los conjuntos de datos autorizados y las funciones autorizadas. Si superas este límite debido a una gran cantidad de vistas autorizadas, considera agrupar las vistas en conjuntos de datos autorizados. Como práctica recomendada, agrupa las vistas relacionadas en conjuntos de datos autorizados cuando diseñes arquitecturas nuevas de BigQuery, en especial, las arquitecturas de múltiples usuarios.

Hay demasiadas sentencias DML pendientes en la tabla

Este error significa que la cantidad de sentencias DML de mutación simultáneas (UPDATE, DELETE, MERGE) que se ejecutan en la misma tabla superó el límite de cuota del lenguaje de manipulación de datos (DML). Este límite de cuota es por tabla y se aplica únicamente a las sentencias DML de mutación, que no incluye INSERT.

Solución

Agrupa los trabajos de DML según las Prácticas recomendadas para las sentencias DML.

Carga errores de cuota de archivos CSV

Si cargas un archivo CSV grande mediante el comando bq load con la marca --allow_quoted_newlines, es posible que aparezca este error.

Mensaje de error

Input CSV files are not splittable and at least one of the files is larger than
the maximum allowed size. Size is: ...

Solución

Para resolver este error, haz lo siguiente:

  • Establece la marca --allow_quoted_newlines en false.
  • Divide el archivo CSV en fragmentos más pequeños que tienen menos de 4 GB.

Para obtener más información sobre los límites que se aplican cuando cargas datos en BigQuery, consulta Trabajos de carga.

Errores de límite de creación de réplicas de conjuntos de datos entre regiones

BigQuery devuelve este error (reason: apiLimitExceeded) cuando configuras la replicación de conjuntos de datos entre regiones (ALTER SCHEMA ... ADD REPLICA) y excedes la cantidad máxima de réplicas de conjuntos de datos que se pueden agregar para una región dentro de un período continuo.

Mensaje de error

API limit exceeded: Cannot add more than LIMIT replicas for a region within WINDOW day(s)

Diagnóstico

Este error suele ocurrir cuando una secuencia de comandos automatizada o una herramienta de infraestructura como código (IaC) crea y descarta réplicas de conjuntos de datos (ADD REPLICA y DROP REPLICA) de forma repetida en un bucle.

Solución

Para resolver este error, haz lo siguiente:

  • Audita la automatización y las secuencias de comandos de infraestructura como código. Inspecciona cualquier Terraform, secuencia de comandos de implementación o trabajo programado que administre réplicas de conjuntos de datos para asegurarte de que no se descarten ni se vuelvan a crear réplicas de forma repetida en cada ejecución.
  • Espera a que transcurra la ventana móvil. Espera hasta que pase el período de días consecutivos especificado en el mensaje de error antes de volver a ejecutar ALTER SCHEMA ... ADD REPLICA para esa región.

Tu usuario superó la cuota de solicitudes de project.lists simultáneas

Este error se produce cuando los trabajos de Microsoft Power BI que se comunican con BigQuery a través de un controlador ODBC de Simba o DataHub fallan porque superan el límite de la API de project.list. Para resolver este problema, usa las soluciones alternativas a corto o largo plazo que se describen en esta sección.

Mensaje de error

Your user exceeded quota for concurrent project.lists requests

Diagnóstico

Este error se produce durante la fase de conexión y descubrimiento de Power BI cuando se actualiza un informe de Power BI y el controlador de Simba establece una conexión con un proyecto de BigQuery específico.

Resolución a corto plazo

Para solucionar este problema a corto plazo, usa las siguientes soluciones alternativas, que se ordenan de la más a la menos eficaz. Implementa las correcciones tres o cuatro, según si te conectas a BigQuery con el controlador de Simba o con DataHub.

Para obtener correcciones a largo plazo, consulta Resolución a largo plazo.

  1. Escalona las actualizaciones de los informes. Si no puedes modificar el DSN, mitiga el problema de cuota reduciendo la cantidad de solicitudes simultáneas. En lugar de que todos los informes se actualicen de forma simultánea (por ejemplo, a las 9:00 a.m.), escalona sus programaciones por unos minutos (por ejemplo, a las 9:01 a.m., 9:03 a.m. y 9:05 a.m.). Esta práctica distribuye las llamadas a la API en el tiempo, lo que reduce la probabilidad de que alcances el límite de simultaneidad.

  2. Implementa reintentos en Power BI. Esta estrategia reactiva ayuda a que un informe se recupere de una falla temporal. Power BI tiene una lógica de reintento integrada para las fallas de actualización de datos. Si bien esta práctica no evita el error de cuota, hace que tu canalización sea más resiliente, ya que permite que un informe se complete correctamente en un intento posterior después de que disminuya el aumento inicial de llamadas a la API. Para implementar esta corrección, haz lo siguiente:

    1. En el servicio de Power BI, ve a Configuración para tu conjunto de datos.
    2. Expande la sección Actualización programada. En Reintentar, configura Power BI para que vuelva a ejecutar automáticamente una actualización que falló.

  3. En las versiones anteriores del controlador de Simba, especifica el ID del proyecto en la conexión ODBC. Esta acción evita que el controlador realice la llamada de descubrimiento projects.list. En cambio, el controlador se conecta directamente al proyecto especificado, lo que evita llamadas a la API innecesarias y resuelve el problema de cuota.

    Los controladores más nuevos fallan de inmediato si no se especifica el proyecto con un mensaje similar a Unable to establish connection with data source. Missing settings: {[Catalog]}.

    Para aplicar esta corrección, haz lo siguiente:

    1. En la máquina que ejecuta la puerta de enlace de Power BI o Power BI Desktop, abre la aplicación Orígenes de datos ODBC (64 bits).
    2. En la pantalla de configuración principal del controlador ODBC de Simba para BigQuery, completa el campo Catálogo (proyecto) con tu ID del proyecto de Google Cloud específico, por ejemplo, my-gcp-project-id.

  4. En las versiones anteriores de DataHub, especifica el ID del proyecto en la configuración de transferencia de DataHub. Realiza esta corrección si usas DataHub en lugar del controlador de Simba. Al igual que Simba, las versiones posteriores de DataHub requieren que especifiques el ID del proyecto o no se conectarán a BigQuery.

    Para evitar exceder los límites de DataHub, modifica la configuración de transferencia de DataHub y proporciona una lista explícita de los IDs de los proyectos que se analizarán. Esto evita que la configuración de DataHub encuentre todos los proyectos que puede ver la cuenta de servicio.

    En el archivo de receta de origen de BigQuery (por lo general, un archivo YAML), usa la configuración project_ids para enumerar los proyectos que deseas transferir. Luego, vuelve a implementar la receta de transferencia de DataHub con la configuración nueva. Consulta el siguiente ejemplo y este ejemplo más largo proporcionado por DataHub.

    A continuación, se muestra un ejemplo de un fragmento de configuración de DataHub:

      source:
  type: "bigquery"
  config:
    # Instead of relying on discovery, explicitly list the projects.
    # This avoids the problematic projects.list() API call.
    project_ids:
    -  "YOUR_PRODUCTION_PROJECT_ID"
    -  "YOUR_ANALYTICS_PROJECT_ID"
    -  "ANOTHER_BQ_PROJECT"

Resolución a largo plazo

La mejor solución a largo plazo para este mensaje de error es crear cuentas de servicio deGoogle Cloud independientes y dedicadas para cada función. Por ejemplo, crea una cuenta de servicio para todos los informes de Power BI y una cuenta de servicio para la transferencia de DataHub.

Esta práctica recomendada aísla el uso de la API en buckets de cuota independientes y evita que un trabajo de carga alta en DataHub cause que fallen los informes empresariales críticos en Power BI.

Usa el plan de acción de las siguientes secciones para resolver los errores de cuota a largo plazo en Power BI y DataHub.

Fase 1: Preparación
  1. Informa a los propietarios de las puertas de enlace de Power BI y de la configuración de DataHub que realizarás cambios coordinados para resolver las fallas continuas de los trabajos.
  2. En la consola de Google Cloud , crea dos cuentas de servicio nuevas, por ejemplo, sa-powerbi-gateway@... y sa-datahub-ingestion@....
  3. Crea claves de cuenta de servicio para las cuentas de servicio de Power BI y DataHub.
  4. Otorga a cada cuenta de servicio nueva los permisos con privilegios mínimos asignando los siguientes roles de Identity and Access Management que le permiten realizar sus tareas en la Identity and Access Management (IAM) correspondiente. Evita asignar roles demasiado amplios, por ejemplo, ProjectEditor.
Roles obligatorios

La cuenta de servicio de Power BI ejecuta consultas y lee datos de las tablas. Otorga los siguientes roles a las cuentas de servicio en cada proyecto de Google Cloud que contenga datos a los que Power BI deba acceder. Para obtener más información sobre estos roles, consulta Roles de BigQuery.

La cuenta de servicio para la transferencia de DataHub solo necesita leer metadatos, como nombres de tablas, esquemas y descripciones, no los datos dentro de las tablas. Otorga el siguiente rol a nivel de proyecto para cada proyecto que DataHub analice. Para obtener más información sobre estos roles, consulta Roles de IAM para BigQuery.

Visualizador de metadatos de BigQuery: Este rol se diseñó específicamente para leer metadatos. Otorga permisos para enumerar conjuntos de datos y tablas, y ver sus metadatos sin otorgar acceso a los datos subyacentes.

Fase 2: Lanzamiento coordinado

Durante un período de poco uso, el administrador de Power BI actualiza las configuraciones de DSN de ODBC en las máquinas de puerta de enlace siguiendo estos pasos:

  1. Cambia el método de autenticación para usar la nueva clave de cuenta de servicio de sa-powerbi-gateway@... creada en un paso anterior.
  2. Si aún no se realizó como una solución a corto plazo, ingresa el ID del proyecto de Google Cloud en el campo Catálogo (proyecto) del controlador ODBC.
  3. Hace que el propietario de DataHub actualice el archivo YAML de configuración de la fuente de BigQuery.
  4. Apunta a la nueva clave de cuenta de servicio de sa-datahub-ingestion@... creada en un paso anterior.
  5. Si aún no se realizó como una solución a corto plazo, usa el parámetro project_ids para enumerar de forma explícita los proyectos que se analizarán.
  6. Vuelve a implementar la receta de transferencia de DataHub con la configuración nueva.
Fase 3: Verificación y supervisión

Para verificar y supervisar los efectos de las correcciones, los administradores de Power BI y DataHub realizan los siguientes pasos:

  1. Activa manualmente una actualización para algunos informes clave de Power BI y una nueva ejecución de transferencia en DataHub. Confirma que estos trabajos se completen correctamente sin que se produzcan errores de cuota.
  2. Para asegurarte de que el error Quota exceeded: Your user exceeded quota for concurrent project.lists requests ya no ocurra, supervisa los registros de la aplicación o los historiales de ejecución de la herramienta de inteligencia empresarial.

  3. Opcional: Verifica que el volumen general de llamadas a la API de projects.list o los errores de 403 relacionados hayan disminuido para las cuentas de servicio asociadas:

    1. En la consola de Google Cloud , ve a la página Detalles de la API o el servicio de la API de BigQuery.

      Ir a APIs y servicios

    2. Consulta los paneles en la pestaña Métricas para verificar la disminución en el volumen de llamadas y los errores 403 relacionados.

Los administradores deberían ver una disminución drástica y permanente en el uso de esta llamada a la API específica, lo que confirma que la corrección se realizó correctamente.