Optimiza los trabajos de carga

Las estrategias y las prácticas recomendadas que se describen en este documento te ayudan a optimizar la carga por lotes o la transmisión de datos en BigQuery para evitar alcanzar el límite de la cantidad de trabajos de carga por tabla y por día.

Dado que el límite para los trabajos de carga es fijo y no se puede aumentar, debes optimizar tus trabajos de carga estructurando tus tablas a través de métodos como las particiones de tablas o administrando tus cargas a través de métodos como la carga por lotes o la transmisión.

Cómo funcionan las cuotas de operaciones de tablas

El límite de BigQuery para las modificaciones de tablas por tabla por día por proyecto es fijo, independientemente de si las modificaciones agregan o actualizan datos, o bien 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 recarga. Si excedes el límite de operaciones de la tabla o su tasa de recarga, los trabajos de carga fallarán con un error quotaExceeded. El límite a nivel del proyecto para los trabajos de carga por día se restablece en un período de 24 horas consecutivas. Cuando finalizan los trabajos de carga, disminuye la cuota disponible. Luego, la cuota se restablece gradualmente durante las próximas 24 horas. Los trabajos de carga con errores siguen contando para 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 estándar de las tablas.

Para no superar 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 tablas, consulta las vistas de BigQuery.INFORMATION_SCHEMA

Operaciones de tablas excluidas de la cuota

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

Tu proyecto puede ejecutar una cantidad ilimitada de sentencias DML. Si bien las sentencias DML se contabilizaban anteriormente para las modificaciones diarias de tablas y no se limitaban incluso en el límite, ya no lo hacen.

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 no superar el límite diario de operaciones de tablas de BigQuery, considera estas prácticas recomendadas:

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

Para usar estas prácticas recomendadas, carga por lotes o transmite tus datos 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, incluidas las herramientas y los servicios que puedes usar para cada método.

Carga por lotes

Para no exceder el límite de carga diario por proyecto de BigQuery, procesa grandes cantidades de datos por lotes y cárgalos en BigQuery con menos trabajos. 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 hay información nueva disponible, recopílala y cárgala 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 se considera 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 tu comando bq load o consultas LOAD DATA de SQL.

bq

En el siguiente ejemplo, se muestra un comando bq load para cargar datos CSV de Cloud Storage en una tabla de BigQuery llamada my_target_table. Para seleccionar más de un nombre de archivo fuente, 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 fuente.
• OBJECT_PATH_WILDCARD: Es la ruta de acceso a tus archivos CSV en el bucket de Cloud Storage. Incluye un comodín (*) para que coincidan 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 CSV desde un bucket de Cloud Storage en una tabla de BigQuery. Para seleccionar más de un nombre de archivo fuente, 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 parámetro SOURCE_FORMAT establece el tipo de tus archivos fuente, 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 fuente.
• OBJECT_PATH_WILDCARD: Es la ruta de acceso a tus archivos CSV en el bucket de Cloud Storage. Incluye un comodín (*) para que coincidan 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 Sentencias LOAD en GoogleSQL.

Carga por lotes con la API de BigQuery Storage Write

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

La API de Storage Write optimiza la carga de datos para cumplir con los límites de la tabla. Para la transmisión en tiempo real de gran volumen, usa una transmisión PENDING en lugar de una transmisión COMMITTED. Cuando usas una transmisión de PENDING, la API almacena 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 para la transmisión de datos de alto rendimiento y la semántica de “exactamente una vez”.

Para obtener información sobre cómo usar Dataflow para cargar datos por lotes en BigQuery, consulta Escribe desde Dataflow en 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 por ejecutar 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

Usa la API de Storage Write para transmitir registros en tiempo real a BigQuery con una latencia mínima. La API de Storage Write proporciona un protocolo de transmisión eficiente que ofrece funciones avanzadas, como la semántica de entrega del tipo “exactamente una vez”, la detección de actualizaciones de esquemas y las inserciones y actualizaciones 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 el uso de la API de Storage Write, 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, por ejemplo, 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 de BigQueryIO, que usa la API de Storage Write.

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 por lotes o transmitir datos 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 eficaz para administrar tablas grandes en BigQuery, en especial cuando necesitas realizar operaciones de carga de datos frecuentes. Puedes mejorar significativamente el rendimiento y la rentabilidad de las tablas si las divides en segmentos más pequeños y fáciles de administrar según 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 de BigQuery se aplican a nivel de la partición y no a nivel de la 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 considerablemente 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 por lotes tus datos diarios. Por ejemplo, puedes recopilar todos los datos del día para 2025-09-18 en una tabla de transferencia temporal. Luego, al final del día, ejecutas un solo trabajo para cargar estos datos en la partición específica de ese día en tu tabla de producción principal. Dado que BigQuery solo interactúa 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 económicas.

Si bien se recomienda particionar las tablas grandes y en crecimiento, es mejor evitarlo si las particiones son constantemente más pequeñas que 10 GB. Para obtener más información, consulta Cuándo usar el particionamiento.

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 el jitter integrados

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

En un sistema confiable, los trabajadores que toman tareas de tu 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 google-cloud-bigquery-storage para Python incluye 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 control integrado es un beneficio importante de usar las bibliotecas cliente oficiales. Solo debes ocuparte de los errores que no se pueden reintentar, por ejemplo, INVALID_ARGUMENT, que significa que hay una falta de coincidencia del esquema.