Optimizar las tareas 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 del número de tareas de carga por tabla y día.

Como el límite de tareas de carga es fijo y no se puede aumentar, debes optimizar tus tareas de carga estructurando tus tablas mediante métodos como las particiones de tabla o gestionando tus cargas mediante métodos como la carga por lotes o el streaming.

Cómo funcionan las cuotas de operaciones de tabla

El límite de BigQuery para las modificaciones de tablas por tabla y día por proyecto es fijo, independientemente de si las modificaciones añaden o actualizan datos, o truncan la tabla. Este límite incluye 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.

Los trabajos de carga tienen una tasa de recarga. Si superas el límite de operaciones de tabla o su tasa de recarga, las tareas de carga fallarán y se mostrará un error quotaExceeded. El límite a nivel de proyecto de tareas de carga por día se repone en un periodo de 24 horas ininterrumpido. Cuando finalizan los trabajos de carga, la cuota disponible se reduce. La cuota se recarga gradualmente en las 24 horas siguientes. Las tareas de carga fallidas 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 con particiones, se aplica un límite independiente para las modificaciones de tablas con particiones, que sustituye al límite estándar de las tablas.

Para no superar los límites diarios de operaciones de tabla, distribuye las operaciones a lo largo de un periodo de 24 horas. Por ejemplo, si realizas 25 actualizaciones, cada una con 60 operaciones, puedes ejecutar unas 60 operaciones cada 58 minutos. Este método te ayuda a cumplir el límite diario. Para monitorizar las actualizaciones de las tablas, consulta las vistas de BigQuery INFORMATION_SCHEMA.

Operaciones de tabla excluidas de la cuota

Actualizar la información de una tabla (metadatos) y usar instrucciones DML no se tiene en cuenta para el límite diario de modificaciones de tablas. Esta exclusión se aplica a las tablas estándar y a las particionadas.

Tu proyecto puede ejecutar un número ilimitado de instrucciones DML. Aunque antes las declaraciones de DML se tenían en cuenta para calcular las modificaciones de tablas diarias y no se limitaban aunque se alcanzara el límite, ahora ya no es así.

Las inserciones de streaming 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 tabla de BigQuery, siga 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 aplicar estas prácticas recomendadas, envía tus datos a BigQuery por lotes o en streaming. El método de carga que elijas dependerá de si necesitas cargar grandes volúmenes de datos en tiempo real o si no te preocupa la carga en tiempo real. En las siguientes secciones se explica en detalle la carga por lotes y el streaming de datos, así como las herramientas y los servicios que puedes usar en cada método.

Carga por lotes

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

Cargar más datos de cada tarea

En lugar de enviar datos a BigQuery cada vez que haya información nueva, recógelos y cárgalos en BigQuery con un solo trabajo de gran tamaño.

Por ejemplo, en lugar de ejecutar una tarea de carga independiente por 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, a continuación, ejecutar una tarea de carga para añadir 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 de 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 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 de origen, usa un comodín con el comando. La marca AUTODETECT determina automáticamente el esquema de la tabla a partir de los datos de origen de Cloud Storage y puede admitir un comodín (*) para cargar varios archivos que se ajusten a un patrón de nomenclatura 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"

Haz los cambios siguientes:

• PROJECT_ID: el ID de tu proyecto de Google Cloud .
• DATASET_NAME: el nombre del conjunto de datos de BigQuery en el que quiere cargar los datos.
• TABLE_NAME: el nombre de la tabla de BigQuery en la que quiere cargar los datos.
• BUCKET_NAME: el nombre de tu segmento de Cloud Storage que contiene los archivos de origen.
• OBJECT_PATH_WILDCARD: la ruta a los archivos CSV en el segmento 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 de gs://my-bucket/path/to/data/ que empiezan por my_prefix_ y terminan por .csv.

Para obtener más información, consulta las siguientes secciones:

• Compatibilidad con comodines para URIs de Cloud Storage
• Referencia de la herramienta de línea de comandos bq

SQL

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

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

Haz los cambios siguientes:

• DATASET_NAME: el nombre del conjunto de datos de BigQuery en el que quiere cargar los datos.
• TABLE_NAME: el nombre de la tabla de BigQuery en la que quiere cargar los datos.
• El SOURCE_FORMAT define el tipo de tus archivos de origen, por ejemplo, CSV o JSON. En este ejemplo, utiliza CSV.
• BUCKET_NAME: el nombre del segmento de Cloud Storage que contiene los archivos de origen.
• OBJECT_PATH_WILDCARD: la ruta a los archivos CSV en el segmento 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 de gs://my-bucket/path/to/data/ que empiezan por my_prefix_ y terminan por .csv.

Para obtener más información, consulta Cargar instrucciones en GoogleSQL.

Carga por lotes con la API Storage Write de BigQuery

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

La API Storage Write optimiza la carga de datos para no superar los límites de las tablas. Para el streaming en tiempo real de gran volumen, usa un flujo PENDING en lugar de un flujo COMMITTED. Cuando usas un flujo PENDING, la API almacena temporalmente los registros hasta que confirmas el flujo.

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

Carga por lotes con Dataflow

Si quieres transmitir, transformar y escribir datos en BigQuery mediante flujos de procesamiento de datos, puedes usar Dataflow. Las canalizaciones de datos que creas leen datos 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 Storage Write para ofrecer un streaming de datos de alto rendimiento y una semántica de tipo "exactamente una vez".

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

Streaming 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 continuamente desde tu aplicación cliente en BigQuery, una estrategia que evita alcanzar el límite de ejecución de demasiadas tareas de carga. En las siguientes secciones se describen varios métodos para transmitir datos a BigQuery.

Transmitir datos con la API Storage Write

Usa la API Storage Write para transmitir registros en tiempo real a BigQuery con una latencia mínima. La API Storage Write proporciona un protocolo de streaming eficiente que ofrece funciones avanzadas, como la semántica de entrega exactamente una vez, la detección de actualizaciones de esquemas y las inserciones y actualizaciones de Change Data Capture (CDC) en streaming. Además, puedes ingerir hasta 2 TiB al mes sin coste económico.

Para obtener información sobre cómo usar la API Storage Write, consulta Transmitir datos mediante la API Storage Write.

Transmitir datos mediante Dataflow

Usa Dataflow para crear flujos de datos que lean de fuentes compatibles, como Pub/Sub o Apache Kafka. A continuación, estos flujos de procesamiento transforman los datos y los escriben en BigQuery como destino. Puedes crear una canalización de Dataflow con el conector BigQueryIO, que usa la API Storage Write.

Para obtener información sobre cómo usar Dataflow para transmitir datos a BigQuery, consulta el artículo Escribir datos de Dataflow en BigQuery.

Prácticas recomendadas para gestionar las tablas de carga

Además de cargar datos por lotes o transmitir datos a BigQuery, puede gestionar sus tablas de las siguientes formas para optimizarlas de cara a la ingestión de datos.

Usar tablas con particiones

La creación de particiones de tablas es una técnica eficaz para gestionar tablas de gran tamaño en BigQuery, sobre todo cuando necesitas realizar operaciones de carga de datos frecuentes. Puede mejorar significativamente el rendimiento y la rentabilidad de una tabla dividiéndola en segmentos más pequeños y fáciles de gestionar en función de una fecha, una marca de tiempo o un número entero.

La principal ventaja de las particiones para la carga de datos es que las cuotas de operaciones de tablas diarias de BigQuery se aplican a nivel de partición en lugar de a nivel de tabla. En el caso de las tablas con particiones, se aplica un límite superior independiente a las modificaciones de particiones, que sustituye al límite de las tablas estándar. El límite de las tablas particionadas aumenta considerablemente el número de tareas de carga que puedes ejecutar al día sin alcanzar los límites de cuota.

Una estrategia habitual y muy eficaz es cargar los datos diarios por lotes. Por ejemplo, puede recoger todos los datos del día de 2025-09-18 en una tabla de almacenamiento temporal. Después, al final del día, ejecuta un único trabajo para cargar estos datos en la partición específica de ese día en tu tabla de producción principal. Como BigQuery solo interactúa con los datos de una partición, este enfoque mantiene los datos bien organizados y hace que las operaciones de carga sean más rápidas y menos costosas.

Aunque se recomienda particionar las tablas grandes que crecen, es mejor no hacerlo si las particiones van a ser siempre más pequeñas de 10 GB. Para obtener más información, consulta Cuándo usar la partición.

Para obtener más información sobre los distintos métodos de partición disponibles, como la partición por unidad de tiempo y por intervalo de enteros, consulta Tipos de tablas con particiones.

Aprovecha las funciones integradas de tiempo de espera exponencial, truncamiento y jitter

El tiempo de espera exponencial y los reintentos integrados son un método de gestión de errores que ayuda a tu aplicación a recuperarse sin problemas cuando una operación falla temporalmente. Entre estos fallos se incluyen un error de límite de frecuencia (rateLimitExceeded) o un problema de red breve (unavailable).

En un sistema fiable, los trabajadores que toman tareas de tu cola del lado del cliente también usan la interrupción exponencial y los reintentos. Lo hacen cuando llaman a BigQuery, lo que crea dos niveles de protección.

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

Esta gestión integrada es una ventaja significativa de usar las bibliotecas de cliente oficiales. Solo tienes que gestionar los errores que no se pueden volver a intentar, como INVALID_ARGUMENT, que significa que hay un error de coincidencia de esquemas.