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 a BigQuery para evitar alcanzar el límite de la cantidad de trabajos de carga por tabla y por día.

Debido a 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, de copia y 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 tablas o su tasa de recarga, los trabajos de carga fallan con un error quotaExceeded. El límite a nivel del proyecto para los trabajos de carga por día se recarga en un período continuo de 24 horas. Cuando finalizan los trabajos de carga, disminuye tu cuota disponible. Luego, la cuota se recarga de forma gradual durante las próximas 24 horas. Los trabajos de carga con errores aún se consideran 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 tabla estándar.

Para mantenerte dentro de los límites diarios de operaciones de tablas, distribuye las operaciones durante un período de 24 horas. Por ejemplo, si realizas 25 actualizaciones, cada una con 60 operaciones, puedes ejecutar aproximadamente 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 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 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 instrucciones DML. Si bien las instrucciones DML se consideraban anteriormente en 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 sus propias cuotas específicas las rigen.

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

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

  • Realiza menos escrituras 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, procesa por lotes o transmite tus datos a BigQuery. Tu 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 mantenerte dentro del límite de carga diario por proyecto para BigQuery, procesa por lotes 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í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 que acumules 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 como una operación de tabla, aunque el trabajo contenga muchos más datos. Puedes procesar tus archivos por lotes con comodines en 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 las consultas SQL LOAD DATA.

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 fuente 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: el ID de tu Google Cloud proyecto.
  • DATASET_NAME: el nombre del conjunto de datos de BigQuery en el que deseas cargar los datos.
  • TABLE_NAME: el nombre de la tabla de BigQuery en la que deseas cargar los datos.
  • BUCKET_NAME: el nombre de tu bucket de Cloud Storage que contiene los archivos fuente.
  • OBJECT_PATH_WILDCARD: 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:

SQL

En el siguiente ejemplo, se muestra cómo usar la consulta SQL LOAD DATApara cargar datos CSV de 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: el nombre del conjunto de datos de BigQuery en el que deseas cargar los datos.
  • TABLE_NAME: el nombre de la tabla de BigQuery en la que deseas cargar los datos.
  • SOURCE_FORMAT establece el tipo de tus archivos fuente, por ejemplo, CSV o JSON. En este ejemplo, usa CSV.
  • BUCKET_NAME: el nombre de tu bucket de Cloud Storage que contiene los archivos fuente.
  • OBJECT_PATH_WILDCARD: 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 Instrucciones de carga 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 mantenerte dentro de 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 PENDING, la API almacena registros de forma temporal hasta que confirmas la transmisión.

Para obtener 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 de 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 tipo “exactamente una vez”.

Para obtener información sobre el uso de 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 para 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 (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 proporciona funcionalidad avanzada, como la semántica de entrega de tipo “exactamente una vez”, la detección de actualizaciones de esquemas y los 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 el uso de 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 de 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 BigQueryIO, que usa la API de Storage Write (gRPC).

Para obtener información sobre el uso de Dataflow para transmitir datos a BigQuery, consulta Escribe desde Dataflow en 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 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 diarias de operaciones de tablas para BigQuery se aplican a nivel de la partición en lugar de 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 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 por lotes tus datos diarios. Por ejemplo, puedes recopilar todos los datos del día 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. Debido a que 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 la partición para las tablas grandes y en crecimiento, es mejor evitarla si tus particiones serían constantemente más pequeñas que 10 GB. 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 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 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 tu cola del cliente también usan la retirada exponencial y el reintento. Lo hacen cuando llaman a BigQuery, lo que crea dos niveles de protección.

Por ejemplo, la biblioteca oficial 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 necesitas escribir este código de reintento tú mismo. La llamada client.append_rows() controla estos reintentos de forma automática.

Este manejo integrado es un beneficio significativo del uso de las bibliotecas cliente oficiales. Solo necesitas ocuparte de los errores que no se pueden reintentar, por ejemplo, INVALID_ARGUMENT, lo que significa que hay una falta de coincidencia del esquema.