Introducción a las transferencias de Cloud Storage

El Servicio de transferencia de datos de BigQuery para Cloud Storage permite programar cargas de datos recurrentes de los buckets 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 los buckets de Cloud Storage organizados por fecha.

Formatos de archivo compatibles

En la actualidad, el Servicio de transferencia de datos de BigQuery es compatible con la carga de datos de Cloud Storage en uno de los formatos siguientes:

  • Valores separados por comas (CSV)
  • JSON (delimitado por saltos de línea)
  • Avro
  • Parquet
  • ORC

Tipos de compresión compatibles

El Servicio de transferencia de datos de BigQuery para Cloud Storage admite la carga de datos comprimidos. Los tipos de compresión que admite el Servicio de transferencia de datos de BigQuery son los mismos que los que admiten los trabajos de carga de BigQuery. Para obtener más información, consulta la página sobre cómo cargar datos comprimidos y sin comprimir.

Transferencia de datos para transferencias de Cloud Storage

Para especificar cómo se cargan los datos en BigQuery, selecciona una Preferencia de escritura en la configuración de transferencia cuando configures 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 llamada transferencia incremental, agrega datos nuevos de forma incremental desde la transferencia exitosa anterior a una tabla de destino de BigQuery. Cuando una configuración de transferencia se ejecuta con una preferencia de escritura de APPEND, el Servicio de transferencia de datos de BigQuery filtra los archivos que se modificaron desde la ejecución de transferencia exitosa anterior. Para determinar cuándo se modifica un archivo, el Servicio de transferencia de datos de BigQuery busca en los metadatos del archivo una propiedad de “hora de la última modificación”. Por ejemplo, el Servicio de transferencia de datos de BigQuery examina la propiedad de marca de tiempo updated en un archivo de Cloud Storage. Si el Servicio de transferencia de datos de BigQuery encuentra archivos con una “hora de la última modificación” que se produjo después de la marca de tiempo de la última transferencia exitosa, el Servicio de transferencia de datos de BigQuery transfiere esos archivos en una transferencia incremental.

Para demostrar cómo funcionan las transferencias incrementales, considera el siguiente ejemplo de transferencia de Cloud Storage. Un usuario crea un archivo en un bucket de Cloud Storage en el momento 2023-07-01T00:00Z llamado file_1. La marca de tiempo updated de file_1 es la hora en la que se creó el archivo. Luego, el usuario crea una transferencia incremental desde el bucket de Cloud Storage, programada para ejecutarse una vez al día a las 03:00Z, comenzando desde 2023-07-01T03:00Z.

  • El 2023-07-01T03:00Z se inicia la primera ejecución de transferencia. Como esta es la primera ejecución de transferencia para esta configuración, el Servicio de transferencia de datos de BigQuery 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 es exitosa y el Servicio de transferencia de datos de BigQuery carga file_1 de forma correcta en la tabla de BigQuery de destino.
  • La siguiente ejecución de transferencia, del 2023-07-02T03:00Z, no detecta archivos en los que la propiedad de marca de tiempo updated sea mayor que la ejecución de transferencia correcta más reciente (2023-07-01T03:00Z). La ejecución de la transferencia se realiza de forma correcta sin cargar datos adicionales en la tabla de BigQuery de destino.

En el ejemplo anterior, se muestra cómo el Servicio de transferencia de datos de BigQuery observa la propiedad de marca de tiempo updated del archivo de origen para determinar si se realizaron cambios en los archivos de origen y transferir esos cambios si se detectaron.

En el mismo ejemplo, supongamos que el usuario crea otro archivo en el bucket de Cloud Storage en el momento 2023-07-03T00:00Z, llamado file_2. La marca de tiempo updated de file_2 es la hora en la que se creó el archivo.

  • La siguiente ejecución de transferencia, del 2023-07-03T03:00Z, detecta que file_2 tiene una marca de tiempo updated mayor que la última ejecución exitosa de transferencia (2023-07-01T03:00Z). Supongamos que, cuando se inicia la ejecución de la transferencia, esta falla debido a un error transitorio. En este caso, file_2 no se carga en la tabla de BigQuery de destino. La última marca de tiempo de ejecución de la transferencia correcta se mantiene en 2023-07-01T03:00Z.
  • La siguiente ejecución de transferencia, del 2023-07-04T03:00Z, detecta que file_2 tiene una marca de tiempo updated mayor que la última ejecución de transferencia exitosa (2023-07-01T03:00Z). Esta vez, la ejecución de la transferencia se completa sin problemas, por lo que carga correctamente file_2 en la tabla de BigQuery de destino.
  • La ejecución de la transferencia siguiente, del 2023-07-05T03:00Z, no detecta archivos en los que la marca de tiempo updated sea mayor que la ejecución de la transferencia correcta más reciente (2023-07-04T03:00Z). La ejecución de la transferencia es exitosa sin cargar datos adicionales en la tabla de BigQuery de destino.

En el ejemplo anterior, se muestra que cuando una transferencia falla, no se transfieren archivos a la tabla de destino de BigQuery. Cualquier cambio en el archivo se transfiere en la próxima ejecución de transferencia exitosa. Cualquier transferencia exitosa posterior que sigue a una transferencia con errores no genera datos duplicados. En el caso de una transferencia con errores, también puedes elegir activar una transferencia de forma manual fuera de su hora programada habitual.

Transferencias truncadas

Una configuración de transferencia con una preferencia de escritura MIRROR o WRITE_TRUNCATE, también llamada transferencia truncada, reemplaza los datos en la tabla de destino de BigQuery durante cada ejecución de transferencia con los datos de todos los archivos que coinciden con el URI de origen. MIRROR reemplaza una copia nueva de los datos en la tabla de destino. Si la tabla de destino usa un decorador de particiones, la ejecución de la transferencia solo reemplaza los datos en 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.

Repetir las mismas transferencias incrementales o truncadas en un día no genera datos duplicados. Sin embargo, si ejecutas varias configuraciones de transferencia diferentes que afectan la misma tabla de destino de BigQuery, esto puede hacer que el Servicio de transferencia de datos de BigQuery duplique los datos.

Ruta de acceso a recursos de Cloud Storage

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

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

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

Para recuperar el URI del recurso de Cloud Storage, sigue estos pasos:

  1. Abre Cloud Storage Console.

    Consola de Cloud Storage

  2. Explora 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 inicia con gs://.

Compatibilidad con comodines para las rutas de recursos de Cloud Storage

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

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

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

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

Tampoco puedes hacer coincidir prefijos sin comodines. Por ejemplo, gs://bucket/dir no busca coincidencias en gs://bucket/dir/file.csv ni gs://bucket/file.csv.

Sin embargo, puedes usar varios comodines para los nombres de archivos dentro de los depósitos. Por ejemplo, gs://bucket/dir/*/*.csv coincide con gs://bucket/dir/subdir/file.csv.

Para ver ejemplos de compatibilidad de comodines en combinación con nombres de tablas parametrizados, consulta la página sobre Parámetros de entorno de ejecución en transferencias.

Consideraciones de ubicación

Tu depósito de Cloud Storage debe estar en una región o multirregión 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 bucket de Cloud Storage que contiene los datos que transferirás debe estar en la misma multirregión o en una ubicación dentro de la multirregión. Por ejemplo, si tu conjunto de datos de BigQuery está en la multirregión `EU`, el bucket de Cloud Storage puede estar ubicado en la región `europe-west1` de Bélgica, que está dentro de EU.
  • Si tu conjunto de datos está en una región, el bucket 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 bucket de Cloud Storage no puede estar en la multirregión `ASIA`.

Para obtener información detallada sobre transferencias y regiones, consulta Ubicaciones y transferencias de conjuntos de datos.

Para obtener más información sobre las ubicaciones de Cloud Storage, consulta Ubicaciones de depósitos en la documentación de Cloud Storage.

Precios

  • A los trabajos de carga se les aplican cuotas y límites estándar de BigQuery.

  • Una vez transferidos los datos a BigQuery, se les aplican los precios estándar de BigQuery para el almacenamiento y las consultas.

  • Los datos no se borrarán de forma automática de tu depósito de Cloud Storage una vez que estén subidos a BigQuery, a menos que indiques su eliminación cuando configures la transferencia. Consulta la página sobre cómo configurar una transferencia de Cloud Storage.

  • Consulta la página de precios de transferencias para obtener más detalles.

Cuotas y límites

El Servicio de transferencia de datos de BigQuery usa trabajos de carga para cargar los datos de Cloud Storage en BigQuery.

Todas las cuotas y límites de BigQuery para los trabajos de carga se aplican a los trabajos de carga recurrentes de Cloud Storage, con las siguientes consideraciones adicionales:

Valor Límite
Tamaño máximo por carga de ejecución de transferencia de trabajo 15 TB
Cantidad máxima de archivos por ejecución de transferencia 10,000 archivos

¿Qué sigue?