Solucionar problemas de cuotas y límites

BigQuery tiene varias cuotas y límites que limitan la frecuencia y el volumen de diferentes solicitudes y operaciones. Se utilizan para proteger la infraestructura y prevenir un uso inesperado por parte de los clientes. En este documento se explica cómo diagnosticar y mitigar errores específicos derivados de las cuotas y los límites.

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

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

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

Información general

Si una operación de BigQuery falla porque se ha superado una cuota, la API devuelve el código de estado HTTP 403 Forbidden. El cuerpo de la respuesta incluye más información sobre la cuota que se ha alcanzado. y tiene un aspecto similar a este:

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

El campo message de la carga útil indica cuál es el límite que se ha superado. Por ejemplo, la información del campo message podría ser: Exceeded rate limits: too many table update operations for this table.

Por lo general, los límites de cuota se dividen en dos categorías. La categoría correspondiente se indica en el campo reason de la carga útil de la respuesta.

  • rateLimitExceeded. Este valor indica un límite a corto plazo. Para solucionar estos problemas de límites, vuelve a intentar la operación al cabo de unos segundos. Usa un tiempo de espera exponencial entre cada intento. Es decir, debes aumentar exponencialmente el tiempo que transcurre entre cada intento.

  • quotaExceeded. Este valor indica un límite a largo plazo. Si llegas a un límite de este tipo, tendrás que esperar 10 minutos como mínimo antes de volver a realizar la operación. Si lo alcanzas sistemáticamente, te recomendamos que analices tu carga de trabajo para determinar cómo puedes mitigar el problema. Entre otras medidas, puedes optimizar tu carga de trabajo o solicitar un aumento de cuota.

En caso de que recibas un error quotaExceeded, revisa el mensaje para saber qué límite de cuota se ha superado. Luego, analiza tu carga de trabajo y comprueba si puedes tomar alguna medida para no llegar a la cuota.

En algunos casos, la cuota se puede aumentar. Para hacerlo, ponte en contacto con el equipo de Asistencia de BigQuery o con el equipo de Ventas Google Cloud . Sin embargo, te recomendamos que primero pruebes las sugerencias de este documento.

Diagnóstico

Para diagnosticar problemas, haz lo siguiente:

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

    Por ejemplo, en la siguiente consulta, se usa la vista INFORMATION_SCHEMA.JOBS, en la que se enumeran todos los errores relacionados con la cuota que se han producido en el último día:

    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')

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

  • Consulta los errores en los registros de auditoría de Cloud.

    Por ejemplo, mediante el Explorador de registros, se puede ver que la siguiente consulta devuelve errores con el valor Quota exceeded o limit en la cadena 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 se corresponde con el código de estado HTTP 403.

    Para ver más ejemplos de consultas de registros de auditoría de Cloud, consulta Consultas de BigQuery.

Solucionar problemas con cuotas o límites que se pueden aumentar

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

Tu proyecto ha superado la cuota de bytes de consulta analizados gratuitos

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

Mensaje de error

Your project exceeded quota for free query bytes scanned

Resolución

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

Errores de cuota de inserción de transmisión

En esta sección se proporcionan consejos para solucionar errores de cuota asociados a la transmisión de datos a BigQuery.

En determinadas regiones, las inserciones de transmisión tienen una cuota más alta si no rellenas el campo insertId de cada fila. Puedes consultar más información sobre las cuotas de las inserciones de transmisión aquí. Los errores relacionados con la cuota de transmisión de BigQuery están determinados por la presencia o ausencia de insertId.

Mensaje de error

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

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

Si se rellena el campo insertId, pueden producirse los siguientes errores de cuota:

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

La función del campo insertId es anular los duplicados de filas insertadas. Si llegan varias inserciones con el mismo insertId en un periodo de pocos minutos, BigQuery escribe una sola versión del registro. Sin embargo, esta anulación automática de duplicados no está garantizada. Si quieres conseguir el máximo rendimiento de transmisión, te recomendamos que, en lugar de incluir insertId, anules los duplicados manualmente. Para obtener más información, consulta cómo asegurar la coherencia de los datos.

Cuando te encuentres con este error, diagnostica el problema y, a continuación, sigue los pasos recomendados para solucionarlo.

Diagnóstico

Usa las vistas STREAMING_TIMELINE_BY_* para analizar el tráfico de transmisión. En estas vistas, se engloban las estadísticas de transmisión en intervalos de un minuto, agrupadas por código de error. Los errores de cuota aparecen en los resultados en los que error_code es igual a RATE_LIMIT_EXCEEDED o a 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 ha producido en una cuota a nivel de tabla, filtra por table_id.

Por ejemplo, en la siguiente consulta se muestra el total de bytes ingeridos 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

Resolución

Para solucionar este error de cuota, sigue estos pasos:

  • Si usas el campo insertId para que se anulen los duplicados y el proyecto está en una región que admite una cuota de transmisión más alta, es recomendable que quites el campo insertId. Esta solución puede requerir algunos pasos adicionales para anular de forma manual los duplicados de datos. Para obtener más información, consulta cómo quitar duplicados manualmente.

  • Si no usas el campo insertId o no es factible quitarlo, monitoriza el tráfico de transmisión durante 24 horas y analiza los errores de cuota:

    • Si observas que, principalmente, se producen errores RATE_LIMIT_EXCEEDED en lugar de QUOTA_EXCEEDED y el tráfico general es inferior al 80% de la cuota, es probable que los errores se deban a que se han producido picos temporales. Para solucionarlos, vuelve a intentar la operación dejando un tiempo de espera exponencial entre cada intento.

    • Si usas un trabajo de Dataflow para insertar datos, te recomendamos que utilices trabajos de carga en lugar de inserciones de streaming. Para obtener más información, consulta Configurar el método de inserción. Si usas Dataflow con un conector de E/S personalizado, te recomendamos que utilices un conector de E/S integrado. Para obtener más información, consulta Patrones de entrada/salida personalizados.

    • Si se producen errores QUOTA_EXCEEDED o el tráfico general supera el 80% de la cuota, envía una solicitud para aumentarla. Para obtener más información, consulta Solicitar un ajuste de cuota.

    • También puedes sustituir las inserciones de streaming por la nueva API Storage Write, que tiene un mayor rendimiento, un precio más bajo y muchas funciones útiles.

Número máximo de consultas simultáneas que contienen funciones remotas

BigQuery devuelve este error cuando el número de consultas simultáneas que contienen funciones remotas supera el límite. Sin embargo, este límite se puede aumentar. Prueba primero las soluciones alternativas y las prácticas recomendadas.

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

Diagnóstico

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

Resolución

Número máximo de instrucciones CREATE MODEL

Este error significa que has superado la cuota de instrucciones CREATE MODEL.

Mensaje de error

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

Resolución

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

Número máximo de errores de cuota de tareas de copia por día y proyecto

BigQuery devuelve este error cuando el número de trabajos de copia en ejecución en un proyecto ha superado el límite diario. Para obtener más información sobre el límite de tareas de copia por día, consulta Tareas de copia.

Mensaje de error

Your project exceeded quota for copies per project

Diagnóstico

Si quieres recoger más datos sobre la procedencia de los trabajos de copia, puedes probar lo siguiente:

  • Si tus trabajos de copia se encuentran en una sola región o en unas pocas, puedes probar a consultar la tabla INFORMATION_SCHEMA.JOBS para obtener información sobre 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 de tiempo en función del periodo que te interese.

  • Para ver todos los trabajos de copia de 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:*
    

Resolución

  • Si el objetivo de las operaciones de copia frecuentes es crear una instantánea de los datos, te recomendamos que utilices instantáneas de tablas. Las capturas de tablas son una alternativa más económica y rápida que copiar tablas completas.
  • Para solicitar un aumento de cuota, ponte en contacto con el equipo de Asistencia o con el de Ventas. La solicitud puede tardar varios días en revisarse y procesarse. Te recomendamos que indiques la prioridad, el caso práctico y el ID del proyecto en la solicitud.

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

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 las tareas de extracción, consulta Tareas de extracción.

Mensaje de error

Your usage exceeded quota for ExtractBytesPerDay

Diagnóstico

Si exporta una tabla que tiene un tamaño superior a 50 TiB, la exportación fallará porque supera el límite de extracción. Para evitar este problema, consulta la solución. Si quieres exportar datos de una tabla de particiones específicas, puedes usar un decorador de partición para identificar las particiones que quieres exportar.

Si quieres recoger 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 la tendencia de uso durante varios días.

  • También puedes consultar INFORMATION_SCHEMA.JOBS_BY_PROJECT para ver el total de bytes extraídos durante varios días. Por ejemplo, la siguiente consulta devuelve el total diario de bytes procesados por las tareas 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_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"
    GROUP BY 1
    ORDER BY 2 DESC
  • Después, puede acotar los resultados identificando los trabajos específicos que consumen más bytes de lo esperado. En el siguiente ejemplo se devuelven los 100 trabajos de EXTRACT principales que han consumido más de 100 GB 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

También puedes usar el explorador de trabajos con filtros como Bytes processed more than para filtrar los trabajos con un procesamiento elevado durante un periodo específico.

Resolución

Una forma de 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 comprobación del límite, ya que utiliza tus reservas dedicadas en lugar de un grupo de ranuras compartido gratuito. Si es necesario, puedes eliminar la reserva si quieres usar un grupo de ranuras compartido más adelante.

Para ver otras formas de exportar más de 50 TiB, consulta la sección de notas de Trabajos de extracción.

Número máximo de errores de cuota de tabledata.list bytes por segundo y proyecto

BigQuery devuelve 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 Máximo de tabledata.list bytes por minuto.

Mensaje de error

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

Resolución

Para solucionar este error, sigue estos pasos:

  • En general, te recomendamos que intentes no superar este límite. Por ejemplo, espaciando las solicitudes durante un periodo más largo con retrasos. Si el error no se produce con frecuencia, puedes solucionar el problema implementando reintentos con un tiempo de espera exponencial.
  • Si el caso de uso requiere leer de forma rápida y frecuente una gran cantidad de datos de una tabla, le recomendamos que utilice la API Storage Read de BigQuery en lugar de la API tabledata.list.
  • Si las sugerencias anteriores no funcionan, puedes solicitar un aumento de cuota desde el panel de control de la API de la consolaGoogle Cloud siguiendo estos pasos:

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

    La solicitud puede tardar varios días en revisarse y procesarse.

Número máximo de errores de límite de solicitudes a la API

BigQuery devuelve este error cuando se alcanza el límite de frecuencia del número de solicitudes a una API de BigQuery por usuario y 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 otra dirección de correo de usuario. Para obtener más información, consulta el límite de frecuencia Número máximo de solicitudes a la API por segundo, usuario y método en la API BigQuery.

Mensaje de error

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

Si te encuentras con este error, diagnostica el problema y, a continuación, sigue los pasos recomendados para solucionarlo.

Diagnóstico

Si no has identificado el método que ha alcanzado este límite de frecuencia, haz lo siguiente:

Cuenta de servicio

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

  2. En la Google Cloud consola, ve al panel de control de APIs.

    Para obtener instrucciones sobre cómo ver la información de uso detallada de una API, consulta Usar el panel de APIs.

  3. En el panel de control de APIs, selecciona API de BigQuery.

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

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

    2. Filtra el gráfico por las credenciales de la cuenta de servicio. Es posible que veas picos en un método en el periodo en el que has detectado el error.

Para 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 ha alcanzado el límite, haz lo siguiente:

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

    Ir al Explorador de registros

  2. Filtra los registros ejecutando la siguiente consulta:

     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 el resumen de los registros de auditoría de BigQuery.

Resolución

Para solucionar este error de cuota, sigue estos pasos:

  • Reduce el número de solicitudes a la API o añade un retraso entre varias solicitudes a la API para que el número de solicitudes no supere este límite.

  • Si el límite solo se supera de vez en cuando, puedes implementar reintentos en este error específico con un tiempo de espera exponencial.

  • Si insertas datos con frecuencia, te recomendamos que uses inserciones de streaming, ya que no se ven afectadas por la cuota de la API de BigQuery. Sin embargo, la API de inserciones de streaming tiene costes asociados y su propio conjunto de límites y cuotas.

    Para obtener información sobre el coste de las inserciones de transmisión, consulta los precios de BigQuery.

  • Al cargar datos en BigQuery mediante Dataflow con el conector de E/S de BigQuery, es posible que se produzca este error en el método tables.get. Para solucionar este problema, sigue estos pasos:

    • Define el valor de la propiedad de creación de la tabla de destino como CREATE_NEVER. Para obtener más información, consulta Crear una resolución.

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

  • Para solicitar un aumento de la cuota, ponte en contacto con el equipo de Asistencia o de Ventas. Para obtener más cuota, consulta Solicitar un aumento de cuota. Las solicitudes de aumento de cuota pueden tardar varios días en procesarse. Para proporcionar más información sobre tu solicitud, te recomendamos que incluyas la prioridad del trabajo, el usuario que ejecuta la consulta y el método afectado.

Solucionar problemas con cuotas o límites que no se pueden aumentar

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

Errores de límite de cola de consultas

Si un proyecto intenta poner en cola más consultas interactivas o por lotes de las que permite su límite de cola, es posible que se produzca este error.

Mensaje de error

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

Resolución

Este límite no se puede aumentar. Para solucionar este error de cuota, sigue estos pasos:

  • Pausa la tarea. Si identificas un proceso o un flujo de procesamiento responsable de un aumento de las consultas, pausa ese proceso o flujo.

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

  • Distribuir consultas. Organiza y distribuye la carga entre diferentes proyectos en función de la naturaleza de tus consultas y de las necesidades de tu empresa.

  • Distribuye los tiempos de ejecución. Distribuir la carga en un periodo más largo. Si tu solución de informes necesita ejecutar muchas consultas, intenta introducir cierta aleatoriedad en el momento en que se inician las consultas. Por ejemplo, no inicies todos los informes al mismo tiempo.

  • Usa BigQuery BI Engine. Si has recibido este error al usar una herramienta de inteligencia empresarial (BI) para crear paneles que consultan datos en BigQuery, te recomendamos que uses BI Engine de BigQuery. Usar BigQuery BI Engine es la opción óptima para este caso práctico.

  • Optimiza las consultas y el modelo de datos. A menudo, una consulta se puede reescribir para que se ejecute de forma más eficiente. Por ejemplo, si tu consulta contiene una expresión de tabla común (CTE), es decir, una cláusula WITH, a la que se hace referencia en más de un lugar de la consulta, este cálculo se realiza varias veces. Es mejor conservar los cálculos realizados por la CTE en una tabla temporal y, a continuación, hacer referencia a ella en la consulta.

    Las combinaciones múltiples también pueden ser la causa de la falta de eficiencia. En este caso, puede que te interese usar columnas anidadas y repetidas. Si lo haces, a menudo se mejora la localidad de los datos, se elimina la necesidad de realizar algunas combinaciones y, en general, se reduce el consumo de recursos y el tiempo de ejecución de las consultas.

    Al optimizar las consultas, se abaratan, por lo que, si usas los precios basados en la capacidad, podrás ejecutar más consultas con tus slots. Para obtener más información, consulta la introducción a la optimización del rendimiento de las consultas.

  • Optimizar el modelo de consulta. BigQuery no es una base de datos relacional. No está optimizada para un número infinito de consultas pequeñas. Si ejecutas un gran número de consultas pequeñas, tus cuotas se agotarán rápidamente. Estas consultas no se ejecutan con la misma eficiencia que con los productos de bases de datos más pequeños. BigQuery es un almacén de datos de gran tamaño y este es su caso de uso principal. Es la opción más adecuada para las consultas analíticas de grandes cantidades de datos.

  • Conservar datos (tablas guardadas). Preprocesa los datos en BigQuery y almacénalos en tablas adicionales. Por ejemplo, si ejecutas muchas consultas similares que requieren muchos recursos computacionales con diferentes WHERE condiciones, sus resultados no se almacenan en caché. Estas consultas también consumen recursos cada vez que se ejecutan. Puedes mejorar el rendimiento de estas consultas y reducir su tiempo de procesamiento precalculando los datos y almacenándolos en una tabla. Los datos precalculados de la tabla se pueden consultar mediante SELECT consultas. A menudo, se puede hacer durante la ingestión en el proceso de ETL o mediante consultas programadas o vistas materializadas.

  • Usa el modo de ejecución de prueba. Ejecuta consultas en modo de prueba, que estima el número de bytes leídos, pero no procesa la consulta.

  • Vista previa de los datos de la tabla. Para experimentar con los datos o explorarlos en lugar de ejecutar consultas, puedes usar la función de vista previa de tablas de BigQuery.

  • Utiliza los resultados de la consulta almacenados en caché. Todos los resultados de las consultas, tanto interactivas como por lotes, se almacenan en caché en tablas temporales durante aproximadamente 24 horas, con algunas excepciones. Aunque ejecutar una consulta almacenada en caché sigue contando para el límite de consultas simultáneas, las consultas que usan resultados almacenados en caché son significativamente más rápidas que las que no lo hacen, ya que BigQuery no necesita calcular el conjunto de resultados.

Errores de límite de tamaño de la aleatorización

BigQuery devuelve este error cuando tu proyecto supera el límite máximo de tamaño de disco y memoria disponible para las operaciones de aleatorización.

Esta cuota se calcula por reserva y se divide entre los proyectos de las reservas. El equipo 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.

Mensaje de error

Recibes uno 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.

Resolución

Para solucionar este error, sigue estos pasos:

Número de modificaciones de particiones en tablas con particiones por columnas

BigQuery devuelve este error cuando tu tabla particionada por columnas alcanza la cuota del número de modificaciones de partición permitidas por día. Las modificaciones de particiones incluyen el total de todas las tareas de carga, tareas de copia y tareas de consulta que añaden datos a una partición de destino o la sobrescriben.

Para ver el valor del límite Número de modificaciones de partición por tabla con particiones por columnas al día, consulta Tablas con particiones.

Mensaje de error

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

Resolución

Esta cuota no se puede aumentar. Para solucionar este error de cuota, sigue estos pasos:

  • Cambia el particionado de la tabla para que cada partición contenga más datos y, de esta forma, se reduzca el número total de particiones. Por ejemplo, puedes cambiar la partición de la tabla de diaria a mensual o modificar la forma en que se particiona la tabla.
  • Usa el agrupamiento en clústeres en lugar de las particiones.
  • Si cargas datos con frecuencia desde varios archivos pequeños almacenados en Cloud Storage que usan una tarea por archivo, combina varias tareas de carga en una sola. Puedes cargar datos desde varios URIs 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 Cargar datos por lotes.

  • Si usas tareas de carga, selección o copia para añadir filas de datos a una tabla, por ejemplo, te recomendamos que combines varias tareas en una sola. BigQuery no funciona bien cuando se usa como base de datos relacional. Te recomendamos que evites ejecutar acciones de anexión de una sola fila con frecuencia.
  • Para añadir datos a un ritmo elevado, te recomendamos que uses la API Storage Write de BigQuery. Es una solución recomendada para la ingestión de datos de alto rendimiento. La API Storage Write de BigQuery tiene funciones sólidas, incluida la semántica de entrega "exactamente una vez". Para obtener información sobre los límites y las cuotas, consulta la API Storage Write. Para ver los costes de usar esta API, consulta los precios de la ingestión de datos de BigQuery.
  • Para monitorizar el número de particiones modificadas de una tabla, usa la vista INFORMATION_SCHEMA.

Errores de límite de frecuencia máxima de operaciones de actualización de metadatos de una tabla

BigQuery devuelve este error cuando una tabla alcanza el límite de frecuencia máxima de operaciones de actualización de metadatos de una tabla estándar. Las operaciones con las tablas incluyen el total combinado de todas las tareas de carga, tareas de copia y tareas de consulta que añaden datos a tablas de destino o las sobrescriben, o bien que usan declaraciones DELETE, INSERT, MERGE, TRUNCATE TABLE o UPDATE de DML para escribir datos en tablas.

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

Mensaje de error

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

Si te encuentras con este error, diagnostica el problema y, a continuación, sigue los pasos recomendados para resolverlo.

Diagnóstico

Las actualizaciones de las tablas de metadatos pueden proceder de llamadas a la API que modifican los metadatos de una tabla o de trabajos que modifican el contenido de una tabla. Si no ha identificado la fuente de la que proceden la mayoría de las operaciones de actualización de los metadatos de una tabla, haga lo siguiente:

Identificar llamadas a la API
  1. Ve al menú de Google Cloud navegación y, a continuación, selecciona Logging > Explorador de registros:

    Ir al Explorador de registros

  2. Filtra los registros para ver las operaciones de la tabla ejecutando la siguiente consulta:

    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")
    
Identificar trabajos

La siguiente consulta devuelve una lista de trabajos que modifican la tabla afectada en el proyecto durante el último día. Si esperas que varios proyectos de una organización escriban en la tabla, sustituye 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 el resumen de los registros de auditoría de BigQuery.

Resolución

Esta cuota no se puede aumentar. Para solucionar este error de cuota, sigue estos pasos:

  • Reduce la frecuencia de actualización de los metadatos de la tabla.
  • Añade un retraso entre las tareas o las operaciones de tabla para asegurarte de que la frecuencia de actualización no supera el límite.
  • Para insertar o modificar datos, considera la posibilidad de usar operaciones de DML. Las operaciones de DML no se ven afectadas por el límite de frecuencia de frecuencia máxima de operaciones de actualización de metadatos de una tabla.

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

  • Si cargas datos con frecuencia desde varios archivos pequeños almacenados en Cloud Storage que usan una tarea por archivo, combina varias tareas de carga en una sola. Puedes cargar datos desde varios URIs 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 Cargar datos por lotes.

  • Si usas tareas de carga, selección o copia para añadir filas de datos a una tabla, por ejemplo, te recomendamos que combines varias tareas en una sola. BigQuery no funciona bien cuando se usa como base de datos relacional. Te recomendamos que evites ejecutar acciones de anexión de una sola fila con frecuencia.
  • Para añadir datos a un ritmo elevado, te recomendamos que uses la API Storage Write de BigQuery. Es una solución recomendada para la ingestión de datos de alto rendimiento. La API Storage Write de BigQuery tiene funciones sólidas, incluida la semántica de entrega "exactamente una vez". Para obtener información sobre los límites y las cuotas, consulta la API Storage Write. Para ver los costes de usar esta API, consulta los precios de la ingestión de datos de BigQuery.
  • Para monitorizar el número de particiones modificadas de una tabla, usa la vista INFORMATION_SCHEMA.

Errores de cuota de importaciones de tablas o de anexiones de consultas

BigQuery devuelve este mensaje de error cuando tu tabla alcanza el límite de operaciones de tabla al día para las tablas estándar. Las operaciones de tabla incluyen el total combinado de todas las tareas de carga, tareas de copia y tareas de consulta que añaden datos a una tabla de destino o la sobrescriben.

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

Mensaje de error

Your table exceeded quota for imports or query appends per table

Si te encuentras con este error, diagnostica el problema y, a continuación, sigue los pasos recomendados para resolverlo.

Diagnóstico

Si no ha identificado la fuente de la que proceden la mayoría de las operaciones de la tabla, haga lo siguiente:

  1. Anota el proyecto, el conjunto de datos y la tabla en los que se está escribiendo la consulta, la carga o la tarea de copia que ha fallado.

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

    En el siguiente ejemplo se muestra el recuento por horas de las tareas agrupadas por tipo de tarea de las últimas 24 horas mediante JOBS_BY_PROJECT. Si esperas que varios proyectos escriban en la tabla, sustituye 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

Resolución

Esta cuota no se puede aumentar. Para solucionar este error de cuota, sigue estos pasos:

  • Si cargas datos con frecuencia desde varios archivos pequeños almacenados en Cloud Storage que usan una tarea por archivo, combina varias tareas de carga en una sola. Puedes cargar datos desde varios URIs 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 Cargar datos por lotes.

  • Si usas tareas de carga, selección o copia para añadir filas de datos a una tabla, por ejemplo, te recomendamos que combines varias tareas en una sola. BigQuery no funciona bien cuando se usa como base de datos relacional. Te recomendamos que evites ejecutar acciones de anexión de una sola fila con frecuencia.
  • Para añadir datos a un ritmo elevado, te recomendamos que uses la API Storage Write de BigQuery. Es una solución recomendada para la ingestión de datos de alto rendimiento. La API Storage Write de BigQuery tiene funciones sólidas, incluida la semántica de entrega "exactamente una vez". Para obtener información sobre los límites y las cuotas, consulta la API Storage Write. Para ver los costes de usar esta API, consulta los precios de la ingestión de datos de BigQuery.
  • Para monitorizar el número de particiones modificadas de una tabla, usa la vista INFORMATION_SCHEMA.

Hay demasiadas instrucciones DML pendientes en la tabla

Este error significa que se ha superado el límite de la cuota del lenguaje de manipulación de datos (DML), ya que se han ejecutado demasiadas declaraciones de DML de mutación simultáneas (UPDATE, DELETE y MERGE) en la misma tabla. Este límite de cuota es por tabla y solo se aplica a las instrucciones de DML de mutación, que no incluyen INSERT.

Resolución

Agrupa los trabajos de DML por lotes siguiendo las prácticas recomendadas para las instrucciones DML.

Errores de cuota al cargar archivos CSV

Si cargas un archivo CSV de gran tamaño con el comando bq load y la --allow_quoted_newlines marca, es posible que se produzca 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: ...

Resolución

Para solucionar este error de cuota, sigue estos pasos:

  • Asigna el valor false a la marca --allow_quoted_newlines.
  • Divide el archivo CSV en fragmentos más pequeños, cada uno de ellos con un tamaño inferior a 4 GB.

Para obtener más información sobre los límites que se aplican al cargar datos en BigQuery, consulta el artículo sobre las tareas de carga.

Tu usuario ha superado la cuota de solicitudes simultáneas de project.lists

Este error se produce cuando fallan los trabajos de Microsoft Power BI que se comunican con BigQuery a través de un controlador ODBC de Simba o DataHub porque superan el project.listlímite de la API. Para resolver este problema, utilice 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 detección de Power BI cuando se actualiza un informe de Power BI y el controlador Simba establece una conexión con un proyecto de BigQuery específico.

Resolución a corto plazo

Para solucionar este problema a corto plazo, utiliza las siguientes soluciones alternativas, que se han ordenado de la más a la menos eficaz. Implementa las correcciones tres o cuatro, en función de si te conectas a BigQuery con el controlador Simba o con DataHub.

Para obtener soluciones a largo plazo, consulta Solución a largo plazo.

  1. Alternar las actualizaciones de los informes. Si no puedes modificar el DSN, reduce el número de solicitudes simultáneas para mitigar el problema de la cuota. En lugar de que todos los informes se actualicen simultáneamente (por ejemplo, a las 9:00), programa sus actualizaciones con unos minutos de diferencia (por ejemplo, a las 9:01, a las 9:03 y a las 9:05). De esta forma, las llamadas a la API se distribuyen a lo largo del tiempo, por lo que es menos probable que alcances el límite de simultaneidad.

  2. Implementar reintentos en Power BI. Esta estrategia reactiva ayuda a que un informe se recupere de un fallo temporal. Power BI tiene una lógica de reintento integrada para los errores de actualización de datos. Aunque esta práctica no evita el error de cuota, hace que tu canalización sea más resistente, ya que permite que un informe se complete en un intento posterior después de que se haya reducido el pico inicial de llamadas a la API. Para implementar esta solución, sigue estos pasos:

    1. En el servicio Power BI, vaya a Configuración de su conjunto de datos.
    2. Despliega la sección Actualización programada. En Reintentar, configure Power BI para que vuelva a ejecutar automáticamente una actualización fallida.
  3. En versiones anteriores del controlador Simba, especifica el ID del proyecto en la conexión ODBC. Esta acción impide que el controlador realice la llamada de descubrimiento projects.list. En su lugar, 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 recientes fallan inmediatamente si el proyecto no se especifica con un mensaje similar a Unable to establish connection with data source. Missing settings: {[Catalog]}.

    Para aplicar esta corrección, sigue estos pasos:

    1. En el equipo que ejecuta Power BI Gateway 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 Simba ODBC para BigQuery, rellena el campo Catalog (Project) con el ID de tu proyecto específico, por ejemplo, Google Cloud my-gcp-project-id.
  4. En versiones anteriores de DataHub, especifica el ID de proyecto en la configuración de ingestión de DataHub. Aplica esta corrección si usas DataHub en lugar del controlador Simba. Al igual que Simba, las versiones posteriores de DataHub requieren que especifiques el ID del proyecto para conectarse a BigQuery.

    Para no superar los límites de DataHub, modifique la configuración de la ingestión de DataHub para proporcionar una lista explícita de los IDs de los proyectos que se van a analizar. De esta forma, se evita que la configuración de DataHub encuentre todos los proyectos que puede ver la cuenta de servicio.

    En el archivo de receta de la fuente de BigQuery (normalmente, un archivo YAML), usa la configuración project_ids para enumerar los proyectos que quieras ingerir. A continuación, vuelve a implementar la receta de ingestión de DataHub con la nueva configuración. Consulte el siguiente ejemplo y este otro más largo proporcionado por DataHub.

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

  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 crearGoogle Cloud cuentas de servicio independientes y específicas para cada función. Por ejemplo, crea una cuenta de servicio para todos los informes de Power BI y otra para la ingestión de DataHub.

Esta práctica recomendada aísla el uso de la API en diferentes contenedores de cuota e impide que un trabajo con mucha carga en DataHub provoque errores en los informes empresariales críticos de Power BI.

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

Fase 1: Preparación
  1. Informa a los propietarios de las pasarelas de Power BI y de la configuración de DataHub de que vas a hacer cambios coordinados para resolver los errores de trabajos en curso.
  2. En la Google Cloud consola, 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. Concede a cada cuenta de servicio nueva permisos con el mínimo privilegio asignando los siguientes roles de Gestión de Identidades y Accesos que le permitan llevar a cabo sus tareas en la Gestión de Identidades y Accesos (IAM) correspondiente. Evita asignar roles demasiado generales, como ProjectEditor.
Roles obligatorios

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

La cuenta de servicio de la ingestión de DataHub solo necesita leer metadatos, como nombres de tablas, esquemas y descripciones, pero no los datos de las tablas. Concede el siguiente rol a nivel de proyecto para cada proyecto que analice DataHub. Para obtener más información sobre estos roles, consulta el artículo sobre los roles de gestión de identidades y accesos de BigQuery.

Lector de metadatos de BigQuery: este rol se ha diseñado específicamente para leer metadatos. Otorga permisos para enumerar conjuntos de datos y tablas, y para ver sus metadatos sin dar acceso a los datos subyacentes.

Fase 2: Lanzamiento coordinado

Durante un periodo de poco uso, el administrador de Power BI actualiza las configuraciones de DSN de ODBC en los equipos de la puerta de enlace siguiendo estos pasos:

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

Para verificar y monitorizar los efectos de las correcciones, los administradores de Power BI y DataHub deben seguir estos pasos:

  1. Activa manualmente la actualización de algunos informes clave de Power BI y una nueva ejecución de ingesta en DataHub. Confirma que estos trabajos se completan correctamente sin incurrir en errores de cuota.
  2. En la Google Cloud consola, ve a la página IAM y administración > Cuotas.
  3. Filtra por el servicio API de BigQuery.
  4. Busca la cuota Solicitudes simultáneas project.lists y haz clic en el icono de gráfico para ver el uso a lo largo del tiempo.

Los administradores deberían observar una reducción drástica y permanente en el uso de esta llamada a la API específica, lo que confirmaría que la corrección se ha aplicado correctamente.