Introducción a las transferencias de Cloud Storage

BigQuery Data Transfer Service para Cloud Storage permite programar cargas periódicas de datos desde segmentos de Cloud Storage a BigQuery. La ruta a los datos almacenados en Cloud Storage y la tabla de destino se pueden parametrizar, lo que te permite cargar datos de segmentos de Cloud Storage organizados por fecha.

Formatos de archivo admitidos

Actualmente, BigQuery Data Transfer Service permite cargar datos de Cloud Storage en uno de los siguientes formatos:

  • Valores separados por comas (CSV)
  • JSON (delimitado por líneas nuevas)
  • Avro
  • Parquet
  • ORC

Tipos de compresión admitidos

BigQuery Data Transfer Service para Cloud Storage permite cargar datos comprimidos. Los tipos de compresión admitidos por BigQuery Data Transfer Service son los mismos que los tipos de compresión admitidos por las tareas de carga de BigQuery. Para obtener más información, consulta Cargar datos comprimidos y sin comprimir.

Ingestión de datos para transferencias de Cloud Storage

Puede especificar cómo se cargan los datos en BigQuery seleccionando una preferencia de escritura en la configuración de la transferencia al configurar una transferencia de Cloud Storage.

Hay dos tipos de preferencias de escritura disponibles: transferencias incrementales y transferencias truncadas.

Transferencias incrementales

Una configuración de transferencia con una preferencia de escritura APPEND o WRITE_APPEND, también denominada transferencia incremental, añade de forma incremental los datos nuevos desde la transferencia correcta anterior a una tabla de destino de BigQuery. Cuando se ejecuta una configuración de transferencia con la preferencia de escritura APPEND, BigQuery Data Transfer Service filtra los archivos que se han modificado desde la ejecución de transferencia anterior. Para determinar cuándo se modifica un archivo, BigQuery Data Transfer Service consulta los metadatos del archivo para ver la propiedad "hora de última modificación". Por ejemplo, BigQuery Data Transfer Service consulta la propiedad de marca de tiempo updated de un archivo de Cloud Storage. Si BigQuery Data Transfer Service encuentra algún archivo con una marca de tiempo de última modificación posterior a la de la última transferencia correcta, BigQuery Data Transfer Service transferirá esos archivos en una transferencia incremental.

Para mostrar cómo funcionan las transferencias incrementales, vamos a ver el siguiente ejemplo de transferencia de Cloud Storage. Un usuario crea un archivo en un segmento de Cloud Storage a las 00:00 del 1 de julio del 2023 (2023-07-01T00:00Z) llamado file_1. La updated marca de tiempo de file_1 es la hora en la que se creó el archivo. A continuación, el usuario crea una transferencia incremental desde el bucket de Cloud Storage, programada para ejecutarse una vez al día a las 03:00 UTC, a partir del 1 de julio del 2023 a las 03:00 UTC.

  • A las 2023-07-01T03:00Z, se inicia la primera ejecución de transferencia. Como esta es la primera ejecución de transferencia de esta configuración, BigQuery Data Transfer Service intenta cargar todos los archivos que coincidan con el URI de origen en la tabla de BigQuery de destino. La ejecución de la transferencia se completa correctamente y BigQuery Data Transfer Service carga file_1 en la tabla de BigQuery de destino.
  • En la siguiente ejecución de la transferencia, el 2023-07-02T03:00Z, no se detectan archivos en los que la propiedad de marca de tiempo updated sea posterior a la de la última ejecución de la transferencia (2023-07-01T03:00Z). La ejecución de la transferencia se realiza correctamente sin cargar datos adicionales en la tabla de BigQuery de destino.

En el ejemplo anterior se muestra cómo BigQuery Data Transfer Service consulta la propiedad de marca de tiempo updated del archivo de origen para determinar si se han realizado cambios en los archivos de origen y transferir esos cambios si se detectan.

Siguiendo el mismo ejemplo, supongamos que el usuario crea otro archivo en el segmento de Cloud Storage a las 00:00 del 3 de julio del 2023, llamado file_2. La updated marca de tiempo de file_2 es la hora en la que se creó el archivo.

  • En la siguiente ejecución de la transferencia, el 3 de julio del 2023 a las 03:00 UTC, se detecta que file_2 tiene una marca de tiempo updated posterior a la de la última ejecución de la transferencia (1 de julio del 2023 a las 03:00 UTC). Supongamos que, cuando se inicia la ejecución de la transferencia, falla debido a un error transitorio. En este caso, file_2 no se carga en la tabla de BigQuery de destino. La marca de tiempo de la última transferencia correcta sigue siendo 2023-07-01T03:00Z.
  • En la siguiente ejecución de la transferencia, el 4 de julio del 2023 a las 03:00 (UTC), se detecta que file_2 tiene una marca de tiempo updated posterior a la de la última ejecución de la transferencia correcta (el 1 de julio del 2023 a las 03:00 [UTC]). Esta vez, la ejecución de la transferencia se completa sin problemas, por lo que file_2 se carga correctamente en la tabla de BigQuery de destino.
  • En la siguiente ejecución de la transferencia, el 5 de julio del 2023 a las 03:00 UTC, no se detectan archivos cuya marca de tiempo updated sea posterior a la de la última ejecución de la transferencia (4 de julio del 2023 a las 03:00 UTC). La ejecución de la transferencia se completa correctamente sin cargar datos adicionales en la tabla de BigQuery de destino.

En el ejemplo anterior se muestra que, cuando falla una transferencia, no se transfiere ningún archivo a la tabla de destino de BigQuery. Los cambios en los archivos se transfieren en la siguiente transferencia correcta. Las transferencias posteriores que se realicen correctamente después de una transferencia fallida no provocarán que se dupliquen los datos. Si la transferencia falla, también puede iniciarla manualmente fuera del horario programado.

Transferencias truncadas

Una configuración de transferencia con una preferencia de escritura MIRROR o WRITE_TRUNCATE, también denominada transferencia truncada, sobrescribe los datos de la tabla de destino de BigQuery durante cada ejecución de la transferencia con los datos de todos los archivos que coincidan con el URI de origen. MIRROR sobrescribe una copia nueva de los datos de la tabla de destino. Si la tabla de destino usa un decorador de partición, la transferencia solo sobrescribe los datos de la partición especificada. Una tabla de destino con un decorador de partición tiene el formato my_table${run_date}, por ejemplo, my_table$20230809.

Si repites las mismas transferencias incrementales o truncadas en un día, no se duplicarán los datos. Sin embargo, si ejecutas varias configuraciones de transferencia diferentes que afectan a la misma tabla de destino de BigQuery, BigQuery Data Transfer Service puede duplicar los datos.

Ruta de recurso de Cloud Storage

Para cargar datos desde una fuente de datos de Cloud Storage, debe proporcionar la ruta a los datos.

La ruta del recurso de Cloud Storage contiene el nombre del segmento y el objeto (nombre de archivo). Por ejemplo, si el segmento de Cloud Storage se llama mybucket y el archivo de datos se llama myfile.csv, la ruta del recurso sería gs://mybucket/myfile.csv.

BigQuery no admite rutas de recursos de Cloud Storage que incluyan varias barras consecutivas después de la barra doble inicial. Los nombres de los objetos de Cloud Storage pueden contener varias barras (/) consecutivas. Sin embargo, BigQuery convierte varias barras consecutivas en una sola barra. Por ejemplo, la siguiente ruta de recurso, aunque es válida en Cloud Storage, no funciona en BigQuery: gs://bucket/my//object//name.

Para obtener la ruta del recurso de Cloud Storage, sigue estos pasos:

  1. Abre la consola de Cloud Storage.

    Consola de Cloud Storage

  2. Desplázate hasta la ubicación del objeto (archivo) que contiene los datos de origen.

  3. Haz clic en el nombre del objeto.

    Se abrirá la página Detalles del objeto.

  4. Copia el valor proporcionado en el campo URI de gsutil, que empieza por gs://.

Compatibilidad con comodines para rutas de recursos de Cloud Storage

Si los datos de Cloud Storage están separados en varios archivos que comparten un nombre base común, puede usar un comodín en la ruta del recurso al cargar los datos.

Para añadir un comodín a la ruta del recurso de Cloud Storage, añade un asterisco (*) al nombre base. Por ejemplo, si tienes dos archivos llamados fed-sample000001.csv y fed-sample000002.csv, la ruta del recurso sería gs://mybucket/fed-sample*. Esta wildcard se puede usar en la Google Cloud consola o en Google Cloud CLI.

Puedes usar varios comodines para objetos (nombres de archivo) en los contenedores. El comodín puede aparecer en cualquier parte del nombre del objeto.

Los comodines no expanden un directorio en un gs://bucket/. Por ejemplo, gs://bucket/dir/* busca archivos en el directorio dir, pero no en el subdirectorio gs://bucket/dir/subdir/.

Tampoco puedes buscar prefijos sin comodines. Por ejemplo, gs://bucket/dir no coincide con gs://bucket/dir/file.csv ni con gs://bucket/file.csv.

Sin embargo, puedes usar varios comodines para los nombres de archivo de los contenedores. Por ejemplo, gs://bucket/dir/*/*.csv coincide con gs://bucket/dir/subdir/file.csv.

Para ver ejemplos de compatibilidad con comodines en combinación con nombres de tabla parametrizados, consulta Usar parámetros de tiempo de ejecución en las transferencias.

Consideraciones de ubicación

El segmento de Cloud Storage debe estar en una región o multirregión que sea compatible con la región o multirregión del conjunto de datos de destino en BigQuery.

  • Si tu conjunto de datos de BigQuery está en una multirregión, el segmento de Cloud Storage que contenga los datos que vas a transferir debe estar en la misma multirregión o en una ubicación que esté incluida en la multirregión. Por ejemplo, si tu conjunto de datos de BigQuery está en la multirregión EU, el segmento de Cloud Storage puede estar en la región europe-west1 de Bélgica, que está en la UE.
  • Si tu conjunto de datos está en una sola región, tu segmento de Cloud Storage debe estar en la misma región. Por ejemplo, si tu conjunto de datos está en la región asia-northeast1 de Tokio, tu segmento de Cloud Storage no puede estar en la multirregión ASIA.

Para obtener información detallada sobre las transferencias y las regiones, consulta el artículo Ubicaciones y transferencias de conjuntos de datos.

Para obtener más información sobre las ubicaciones de Cloud Storage, consulta la sección Ubicaciones de los segmentos de la documentación de Cloud Storage.

Precios

Cuotas y límites

BigQuery Data Transfer Service usa tareas de carga para cargar datos de Cloud Storage en BigQuery.

Se aplican todas las cuotas y los límites de BigQuery a las tareas de carga de Cloud Storage periódicas, con las siguientes consideraciones adicionales:

Valor Límite
Tamaño máximo por ejecución de transferencia de trabajos de carga 15 TB
Número máximo de archivos por transferencia 10.000 archivos

Siguientes pasos