Optimiza los trabajos de carga

Puedes mantenerte dentro de los límites de trabajos de carga por tabla en BigQuery por medio de la escritura por lotes, la transmisión de actualizaciones frecuentes y la partición de tablas de destino. Las cuotas de modificación diarias son fijas y no se pueden aumentar, por lo que usar menos escrituras y más grandes con reintentos de cliente integrados ayuda a evitar errores quotaExceeded.

Cómo funcionan las cuotas de operaciones de tablas

El límite de BigQuery para las modificaciones de tabla por tabla por día por proyecto es fijo, independientemente de si las modificaciones agregan o actualizan datos, o truncan la tabla. Este límite incluye el total combinado de todos los trabajos de carga, trabajos de copia y trabajos de consulta que agregan datos a una tabla de destino o la reemplazan.

Los trabajos de carga tienen una tasa de reabastecimiento. Si excedes el límite de operaciones de la tabla o su tasa de reabastecimiento, los trabajos de carga fallarán con un error quotaExceeded. El límite a nivel de proyecto para los trabajos de carga por día se restablece en un período de 24 horas. Cuando finalizan los trabajos de carga, disminuye tu cuota disponible. Luego, la cuota se vuelve a llenar de forma gradual durante las próximas 24 horas. Los trabajos de carga con errores se siguen considerando en las cuotas por tabla y por proyecto. Para obtener más información sobre los límites de los trabajos de carga, consulta Trabajos de carga.

En el caso de las tablas particionadas, se aplica un límite independiente para las tabla particionada particionadas, que reemplaza el límite de tablas estándar.

Para mantenerte dentro de los límites diarios de operaciones de tabla, distribuye las operaciones en un período de 24 horas. Por ejemplo, si realizas 25 actualizaciones, cada una con 60 operaciones, puedes ejecutar alrededor de 60 operaciones cada 58 minutos. Este enfoque te ayuda a cumplir con el límite diario. Para supervisar las actualizaciones de las tablas, consulta las vistas de INFORMATION_SCHEMA de BigQuery .

Operaciones de tablas excluidas de la cuota

La actualización de la información de la tabla (metadatos) y el uso de sentencias DML no se consideran en el límite diario de modificaciones de tablas. Esta exclusión se aplica a las tablas estándar y particionadas.

Tu proyecto puede ejecutar una cantidad ilimitada de sentencias DML. Si bien las sentencias DML antes se consideraban en las modificaciones diarias de las tablas y no se limitaban, incluso cuando se alcanzaba el límite, ya no es así.

Las inserciones de transmisión también modifican las tablas, pero se rigen por sus propias cuotas específicas.

Estrategias de carga para evitar el límite de operaciones de tabla

Para mantenerte dentro del límite diario de operaciones de tablas de BigQuery, ten en cuenta estas prácticas recomendadas:

• Realiza menos escrituras, pero más grandes, en lugar de muchas pequeñas.
• Minimiza los trabajos de escritura independientes en tu tabla de producción final cada día.

Para usar estas prácticas recomendadas, carga tus datos por lotes o transmítelos a BigQuery. La elección del método de carga depende de si necesitas cargar grandes volúmenes de datos en tiempo real o si la carga en tiempo real no es un problema. En las siguientes secciones, se explican en detalle la carga por lotes y la transmisión de datos, incluidos los servicios y las herramientas que puedes usar para cada método.

Carga por lotes

Para mantenerte dentro del límite de carga diario por proyecto de BigQuery, agrupa grandes cantidades de datos y cárgalos con menos trabajos en BigQuery. En las siguientes secciones, se describen varios métodos que puedes usar para cargar tus datos por lotes.

Carga más datos para cada trabajo

En lugar de enviar datos a BigQuery cada vez que haya información nueva disponible, recopílalos y cárgalos en BigQuery con un solo trabajo grande.

Por ejemplo, en lugar de ejecutar un trabajo de carga independiente para cada pocas filas de datos, puedes esperar hasta acumular varios miles de filas de datos en un archivo, por ejemplo, en un archivo CSV o JSON, y, luego, ejecutar un trabajo de carga para agregar todos los datos a una tabla. Esta acción cuenta como una operación de tabla, aunque el trabajo contenga muchos más datos. Puedes agrupar tus archivos por lotes usando comodines con tu trabajo de carga. Los comodines te permiten seleccionar lotes de archivos en un directorio para cargar varios archivos en un solo trabajo de carga.

En el siguiente ejemplo, se muestra cómo usar comodines con el comando bq load o las consultas en SQL LOAD DATA.

bq

En el siguiente ejemplo, se muestra un comando bq load para cargar datos de CSV de Cloud Storage en una tabla de BigQuery llamada my_target_table. Para seleccionar más de un nombre de archivo de origen, usa un comodín con el comando. La marca AUTODETECT determina automáticamente el esquema de tu tabla a partir de los datos de origen en Cloud Storage y puede admitir un comodín (*) para cargar varios archivos que se ajusten a un patrón de nombres específico en la tabla de BigQuery.

bq load \
  --source_format=CSV \
  --autodetect \
  --project_id=PROJECT_ID \
  DATASET_NAME.TABLE_NAME \
  "gs://BUCKET_NAME/OBJECT_PATH_WILDCARD"

Reemplaza lo siguiente:

• PROJECT_ID: Es el ID de tu proyecto de Google Cloud .
• DATASET_NAME: Es el nombre del conjunto de datos de BigQuery en el que deseas cargar los datos.
• TABLE_NAME: Es el nombre de la tabla de BigQuery en la que deseas cargar los datos.
• BUCKET_NAME: Es el nombre de tu bucket de Cloud Storage que contiene los archivos de origen.
• OBJECT_PATH_WILDCARD: Es la ruta de acceso a tus archivos CSV en el bucket de Cloud Storage. Incluye un comodín (*) para que coincida con varios archivos. Por ejemplo, la cadena gs://my-bucket/path/to/data/my_prefix_*.csv usa el carácter comodín * para cargar todos los archivos en gs://my-bucket/path/to/data/ que comienzan con my_prefix_ y terminan con .csv.

Para obtener más información, consulta lo siguiente:

• Compatibilidad de comodines para los URI de Cloud Storage
• Referencia de la herramienta de línea de comandos de bq

SQL

En el siguiente ejemplo, se muestra cómo usar la consulta de SQL LOAD DATA para cargar datos de CSV desde un bucket de Cloud Storage en una tabla de BigQuery. Para seleccionar más de un nombre de archivo de origen, usa un comodín con el comando.

LOAD DATA INTO
DATASET_NAME.TABLE_NAME
FROM FILES (
  format = 'SOURCE_FORMAT',
  uris = ['gs://BUCKET_NAME/OBJECT_PATH_WILDCARD]
  );

Reemplaza lo siguiente:

• DATASET_NAME: Es el nombre del conjunto de datos de BigQuery en el que deseas cargar los datos.
• TABLE_NAME: Es el nombre de la tabla de BigQuery en la que deseas cargar los datos.
• El SOURCE_FORMAT establece el tipo de tus archivos de origen, por ejemplo, CSV o JSON. En este ejemplo, usa CSV.
• BUCKET_NAME: Es el nombre de tu bucket de Cloud Storage que contiene los archivos de origen.
• OBJECT_PATH_WILDCARD: Es la ruta de acceso a tus archivos CSV en el bucket de Cloud Storage. Incluye un comodín (*) para que coincida con varios archivos. Por ejemplo, la cadena gs://my-bucket/path/to/data/my_prefix_*.csv usa el carácter comodín * para cargar todos los archivos en gs://my-bucket/path/to/data/ que comienzan con my_prefix_ y terminan con .csv.

Para obtener más información, consulta Declaraciones LOAD en GoogleSQL.

Carga por lotes con la API de BigQuery Storage Write (gRPC)

Para cargar datos por lotes en BigQuery, una opción es usar la API de Storage Write (gRPC) directamente desde tu aplicación con las bibliotecas cliente de la API de Google.

La API de Storage Write (gRPC) optimiza la carga de datos para mantenerse dentro de los límites de la tabla. Para la transmisión en tiempo real de alto volumen, usa una transmisión PENDING, en lugar de una transmisión COMMITTED. Cuando usas una transmisión PENDING, la API almacena los registros de forma temporal hasta que confirmas la transmisión.

Para ver un ejemplo completo de la carga de datos por lotes con la API de Storage Write, consulta Carga datos por lotes con la API de Storage Write.

Carga por lotes con Dataflow

Si deseas transmitir, transformar y escribir datos en BigQuery con canalizaciones de datos, puedes usar Dataflow. Las canalizaciones de datos que creas leen desde fuentes compatibles, como Pub/Sub o Apache Kafka. También puedes crear una canalización de Dataflow con el conector BigQueryIO, que usa la API de Storage Write (gRPC) para la transmisión de datos de alto rendimiento y la semántica de entrega de tipo "exactamente una vez".

Para obtener información sobre cómo usar Dataflow para cargar datos por lotes en BigQuery, consulta Escribe desde Dataflow a BigQuery.

Transmisión de datos

Para cargar grandes volúmenes de datos con actualizaciones frecuentes, te recomendamos que transmitas tus datos a BigQuery. Con la transmisión de datos, los datos nuevos se escriben de forma continua desde tu aplicación cliente en BigQuery, una estrategia que evita alcanzar el límite de ejecución de demasiados trabajos de carga. En las siguientes secciones, se describen varios métodos para transmitir tus datos a BigQuery.

Transmite datos con la API de Storage Write (gRPC)

Usa la API de Storage Write (gRPC) para transmitir registros en tiempo real a BigQuery con una latencia mínima. La API de Storage Write (gRPC) proporciona un protocolo de transmisión eficiente que ofrece funciones avanzadas, como semántica de entrega de una sola vez, detección de actualizaciones de esquemas y upserts de captura de datos modificados (CDC) de transmisión. Además, puedes transferir hasta 2 TiB por mes sin costo.

Para obtener información sobre cómo usar la API de Storage Write (gRPC), consulta Transmite datos con la API de Storage Write.

Transmite datos con Dataflow

Usa Dataflow para crear canalizaciones de datos que lean desde fuentes compatibles, como Pub/Sub o Apache Kafka. Luego, estas canalizaciones transforman y escriben los datos en BigQuery como destino. Puedes crear una canalización de Dataflow con el conector BigQueryIO, que usa la API de Storage Write (gRPC).

Para obtener información sobre cómo usar Dataflow para transmitir datos a BigQuery, consulta Escribe desde Dataflow a BigQuery.

Prácticas recomendadas para administrar tus tablas para la carga

Además de cargar o transmitir datos por lotes a BigQuery, administra tus tablas de las siguientes maneras para optimizarlas para la transferencia de datos.

Usar tablas particionadas

La partición de tablas es una técnica potente para administrar tablas grandes en BigQuery, en especial cuando necesitas realizar operaciones de carga de datos frecuentes. Puedes mejorar de forma significativa el rendimiento y la rentabilidad de una tabla si la divides en segmentos más pequeños y fáciles de administrar en función de una fecha, una marca de tiempo o un número entero.

La principal ventaja de la partición para la carga de datos es que las cuotas de operaciones de tablas diarias para BigQuery se aplican a nivel de partición, en lugar de a nivel de tabla. En el caso de las tablas particionadas, se aplica un límite independiente y más alto a las modificaciones de particiones, que reemplaza el límite de tabla estándar. El límite para las tablas particionadas aumenta de forma drástica la cantidad de trabajos de carga que puedes ejecutar por día sin alcanzar los límites de cuota.

Una estrategia común y muy eficaz es cargar tus datos diarios por lotes. Por ejemplo, puedes recopilar todos los datos del día para 2025-09-18 en una tabla de etapa de pruebas temporal. Luego, al final del día, ejecutas un solo trabajo para cargar estos datos en la partición específica de este día en tu tabla de producción principal. Como BigQuery interactúa solo con los datos de una sola partición, este enfoque mantiene tus datos bien organizados y hace que tus operaciones de carga sean más rápidas y menos costosas.

Si bien se recomienda particionar las tablas grandes y en crecimiento, es mejor evitarlo si las particiones son de menos de 10 GB de forma constante. Para obtener más información, consulta Cuándo usar la partición.

Para obtener más información sobre los diferentes métodos de partición disponibles, como la partición por unidad de tiempo y por rango de números enteros, consulta Tipos de tablas particionadas.

Aprovecha la retirada exponencial, el truncamiento y la fluctuación integrados

La retirada exponencial y el reintento integrados son un método de manejo de errores que ayuda a que tu aplicación se recupere sin problemas cuando una operación falla de forma temporal. Estas fallas pueden incluir un error de límite de frecuencia (rateLimitExceeded) o un problema de red breve (unavailable).

En un sistema confiable, los trabajadores que toman tareas de la cola del cliente también usan la retirada exponencial y el reintento. Esto se hace cuando se llama a BigQuery, lo que crea dos niveles de protección.

Por ejemplo, la biblioteca oficial de google-cloud-bigquery-storage para Python incluye una lógica de reintento integrada con retirada exponencial. Esta lógica controla los errores temporales de gRPC, por ejemplo, UNAVAILABLE. En la mayoría de los casos, no es necesario que escribas este código de reintento. La llamada client.append_rows() controla estos reintentos automáticamente.

Este manejo integrado es un beneficio significativo de usar las bibliotecas cliente oficiales. Solo debes lidiar con los errores que no se pueden reintentar, por ejemplo, INVALID_ARGUMENT, lo que significa que hay una discrepancia de esquema.