Introducción a las transferencias de Amazon S3

El Servicio de transferencia de datos de BigQuery para Amazon S3 te permite programar y administrar de manera automática los trabajos de carga recurrentes de Amazon S3 en BigQuery.

Formatos de archivo compatibles

El Servicio de transferencia de datos de BigQuery admite que se carguen datos desde Amazon S3 en uno de los siguientes formatos:

  • 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 Amazon S3 es compatible con la carga de datos comprimidos. Los tipos de compresión compatibles con el Servicio de transferencia de datos de BigQuery son los mismos que los tipos de compresión compatibles con 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.

Requisitos previos de Amazon S3

Para cargar datos desde una fuente de datos de Amazon S3, debes hacer lo siguiente:

  • Proporciona el URI de Amazon S3 para tus datos de origen.
  • Ten tu ID de clave de acceso.
  • Ten tu clave de acceso secreta.
  • Establece, como mínimo, la política AmazonS3ReadOnlyAccess administrada de AWS en tus datos de origen de Amazon S3.

URI de Amazon S3

Cuando proporciones el URI de Amazon S3, la ruta de acceso debe tener el siguiente formato: s3://bucket/folder1/folder2/... Solo se requiere el nombre del depósito de nivel superior. Los nombres de las carpetas son opcionales. Si especificas un URI que incluye solo el nombre del bucket, todos los archivos del bucket se transfieren y se cargan en BigQuery.

Parametrización del entorno de ejecución de la transferencia de Amazon S3

Tanto el URI de Amazon S3 como la tabla de destino se pueden parametrizar, lo que te permite cargar datos de depósitos de Amazon S3 organizados por fecha. Ten en cuenta que la parte del bucket del URI no se puede parametrizar. Las transferencias de Amazon S3 usan los mismos parámetros que las transferencias de Cloud Storage.

Para obtener más información, consulta la página Parámetros de entorno de ejecución en las transferencias.

Transferencia de datos para transferencias de Amazon S3

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 Amazon S3.

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.

Compatibilidad con comodines para los URI de Amazon S3

Si los datos de origen están separados en varios archivos que comparten un nombre base, puedes usar un comodín en el URI cuando cargues los datos. Un comodín se compone de un asterisco (*) y se puede usar en cualquier parte del URI de Amazon S3, excepto en el nombre del bucket.

Si bien se puede usar más de un comodín en el URI de Amazon S3, es posible realizar alguna optimización cuando el URI de Amazon S3 especifica un solo comodín:

  • Existe un límite más alto en la cantidad máxima de archivos por ejecución de transferencia.

  • El comodín abarcará los límites del directorio. Por ejemplo, el URI s3://my-bucket/*.csv de Amazon S3 coincidirá con el archivo s3://my-bucket/my-folder/my-subfolder/my-file.csv.

Ejemplos de URI de Amazon S3

Ejemplo 1

Para cargar un solo archivo de Amazon S3 a BigQuery, especifica el URI de Amazon S3 del archivo.

s3://my-bucket/my-folder/my-file.csv

Ejemplo 2

Para cargar todos los archivos de un bucket de Amazon S3 en BigQuery, especifica solo el nombre del bucket, con o sin un comodín.

s3://my-bucket/

o

s3://my-bucket/*

Ten en cuenta que s3://my-bucket* no es un URI de Amazon S3 permitido, ya que no se puede usar un comodín en el nombre del depósito.

Ejemplo 3

Para cargar todos los archivos de Amazon S3 que tienen un prefijo en común, especifica el prefijo en común seguido de un comodín.

s3://my-bucket/my-folder/*

Ten en cuenta que, a diferencia de cargar todos los archivos de un bucket Amazon S3 de nivel superior, el comodín debe especificarse al final del URI de Amazon S3 para que se carguen los archivos.

Ejemplo 4

Para cargar todos los archivos de Amazon S3 con una ruta de acceso similar, especifica el prefijo en común seguido de un comodín.

s3://my-bucket/my-folder/*.csv

Ejemplo 5

Ten en cuenta que los comodines abarcan directorios, por lo que los archivos csv en my-folder, así como en las subcarpetas de my-folder, se cargarán en BigQuery.

Si tienes estos archivos fuente en una carpeta logs:

s3://my-bucket/logs/logs.csv
s3://my-bucket/logs/system/logs.csv
s3://my-bucket/logs/some-application/system_logs.log
s3://my-bucket/logs/logs_2019_12_12.csv

el siguiente comando lo identifica:

s3://my-bucket/logs/*

Ejemplo 6

Si tienes estos archivos fuente, pero deseas transferir solo aquellos que tengan logs.csv como nombre de archivo, haz lo siguiente:

s3://my-bucket/logs.csv
s3://my-bucket/metadata.csv
s3://my-bucket/system/logs.csv
s3://my-bucket/system/users.csv
s3://my-bucket/some-application/logs.csv
s3://my-bucket/some-application/output.csv

el siguiente comando identifica a los archivos con logs.csv en el nombre:

s3://my-bucket/*logs.csv

Ejemplo 7

Si se usan varios comodines, se puede lograr un mayor control sobre los archivos que se transfieren, al costo de límites inferiores. Usar varios comodines significa que cada comodín solo coincidirá por completo con una ruta de acceso dentro de un subdirectorio. Por ejemplo, para los siguientes archivos fuente en Amazon S3:

s3://my-bucket/my-folder1/my-file1.csv
s3://my-bucket/my-other-folder2/my-file2.csv
s3://my-bucket/my-folder1/my-subfolder/my-file3.csv
s3://my-bucket/my-other-folder2/my-subfolder/my-file4.csv

Si la intención es solo transferir my-file1.csv y my-file2.csv, usa lo siguiente como el valor del URI de Amazon S3:

s3://my-bucket/*/*.csv

Como ninguno de los comodines abarca directorios, mediante este URI se limitaría la transferencia solo a los archivos CSV que están en my-folder1 y my-other-folder2. Las subcarpetas no se incluirán en la transferencia.

Claves de acceso de AWS

El ID de clave de acceso y la clave de acceso secreto se usan para acceder a los datos de Amazon S3 en tu nombre. Como práctica recomendada, crea un ID de clave de acceso única y una clave de acceso secreta específicas para las transferencias de Amazon S3 a fin de brindar acceso mínimo al Servicio de transferencia de datos de BigQuery. Para obtener información sobre cómo administrar las claves de acceso, consulta la documentación de referencia general de AWS.

Consideraciones de coherencia

Cuando transfieres datos de Amazon S3, es posible que algunos de tus datos no se transfieran a BigQuery, en especial si los archivos se agregaron al bucket hace poco tiempo. El archivo debe tardar aproximadamente 10 minutos en estar disponible para el Servicio de transferencia de datos de BigQuery después de agregarlo al bucket. Sin embargo, en algunos casos puede demorar más de 10 minutos.

Para obtener más información sobre el modelo de coherencia de Amazon S3, consulta el Modelo de coherencia de datos de Amazon S3 en la documentación de Amazon S3.

Práctica recomendada sobre los costos de transferencia de datos salientes

Las transferencias de Amazon S3 podrían fallar si la tabla de destino no se configuró de forma correcta. Algunos de los motivos que pueden dar lugar a una configuración incorrecta son los siguientes:

  • La tabla de destino no existe.
  • El esquema de la tabla no está definido.
  • El esquema de la tabla no es compatible con los datos que se transfieren.

Para evitar los costos de transferencia de datos salientes de Amazon S3, primero debes probar una transferencia con un subconjunto pequeño pero representativo de los archivos. Pequeño significa que la prueba debe tener un tamaño de datos pequeño y cantidad de archivos pequeños.

Precios

Para obtener información sobre los precios del Servicio de transferencia de datos de BigQuery, consulta la página Precios.

Ten en cuenta que se pueden incurrir costos fuera de Google por el uso de este servicio. Consulta la página de precios de Amazon S3 para obtener más información.

Cuotas y límites

El Servicio de transferencia de datos de BigQuery usa trabajos de carga para cargar datos de Amazon S3 en BigQuery. Todas las cuotas y límites de BigQuery en los trabajos de carga se aplican a las transferencias recurrentes de Amazon S3, 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 cuando el URI de Amazon S3 incluye 0 o 1 comodines 10,000,000 de archivos
Cantidad máxima de archivos por ejecución de transferencia cuando el URI de Amazon S3 incluye más de 1 comodín 10,000 archivos

¿Qué sigue?