Introducción a las transferencias de Amazon S3

BigQuery Data Transfer Service para Amazon S3 te permite programar y gestionar automáticamente las tareas de carga periódicas de Amazon S3 en BigQuery.

Formatos de archivo admitidos

BigQuery Data Transfer Service permite cargar datos de Amazon S3 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 Amazon S3 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.

Requisitos previos de Amazon S3

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

• Proporcionar el URI de Amazon S3 de los datos de origen
• Tener el ID de la clave de acceso
• Tener tu clave de acceso secreta
• Define, como mínimo, la política gestionada de AWS AmazonS3ReadOnlyAccess en los datos de origen de Amazon S3

URIs de Amazon S3

Cuando proporcione el URI de Amazon S3, la ruta debe tener el siguiente formato: s3://bucket/folder1/folder2/... Solo se requiere el nombre del segmento de nivel superior. Los nombres de las carpetas son opcionales. Si especifica un URI que solo incluye el nombre del contenedor, se transferirán todos los archivos del contenedor y se cargarán en BigQuery.

Parametrización del tiempo de ejecución de las transferencias de Amazon S3

El URI de Amazon S3 y la tabla de destino se pueden parametrizar, lo que te permite cargar datos de segmentos de Amazon S3 organizados por fecha. Tenga en cuenta que la parte del URI correspondiente al segmento no se puede parametrizar. Los parámetros que usan las transferencias de Amazon S3 son los mismos que los que usan las transferencias de Cloud Storage.

Para obtener más información, consulta Parámetros de tiempo de ejecución en transferencias.

Ingestión de datos para transferencias de Amazon S3

Puedes especificar cómo se cargan los datos en BigQuery seleccionando una preferencia de escritura en la configuración de la transferencia cuando configures una transferencia de Amazon S3.

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.

Compatibilidad con comodines para URIs de Amazon S3

Si los datos de origen están separados en varios archivos que comparten un nombre base común, puedes usar un comodín en el URI al cargar los datos. Un comodín consta de un asterisco (*) y se puede usar en cualquier parte del URI de Amazon S3, excepto en el nombre del segmento.

Aunque se puede usar más de un comodín en el URI de Amazon S3, se puede optimizar el proceso si el URI de Amazon S3 especifica solo un comodín:

• Hay un límite superior en el número máximo de archivos por transferencia.

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

Ejemplos de URIs de Amazon S3

Ejemplo 1

Para cargar un solo archivo de Amazon S3 en 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 segmento de Amazon S3 en BigQuery, especifica solo el nombre del segmento, con o sin 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 segmento.

Ejemplo 3

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

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

Ten en cuenta que, a diferencia de la carga de todos los archivos de un contenedor de nivel superior de Amazon S3, 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 similar, especifica el prefijo común seguido de un comodín.

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

Ejemplo 5

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

Si tienes estos archivos de origen 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

entonces, se identifican de la siguiente manera:

s3://my-bucket/logs/*

Ejemplo 6

Si tienes estos archivos de origen, pero solo quieres transferir los que tengan logs.csv como nombre de archivo, sigue estos pasos:

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

A continuación, se identifican los archivos que tienen logs.csv en el nombre:

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

Ejemplo 7

Si usas varios comodines, tendrás más control sobre los archivos que se transfieren, pero los límites serán más bajos. Si se usan varios comodines, cada uno de ellos solo coincidirá hasta el final de una ruta dentro de un subdirectorio. Por ejemplo, para los siguientes archivos de origen de 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 solo quiere transferir my-file1.csv y my-file2.csv, utilice lo siguiente como valor del URI de Amazon S3:

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

Como ninguna de las comodines abarca directorios, este URI limitaría la transferencia solo a los archivos CSV que se encuentran en my-folder1 y my-other-folder2. Las subcarpetas no se incluirían en la transferencia.

Claves de acceso de AWS

El ID de clave de acceso y la clave de acceso secreta se usan para acceder a los datos de Amazon S3 en tu nombre. Como práctica recomendada, cree un ID de clave de acceso y una clave de acceso secreta únicos específicamente para las transferencias de Amazon S3, de modo que BigQuery Data Transfer Service tenga el mínimo acceso posible. Para obtener información sobre cómo gestionar tus claves de acceso, consulta la documentación de referencia general de AWS.

Restricciones de IP

Si utilizas restricciones de IP para acceder a Amazon S3, debes añadir los intervalos de IP que utilizan los trabajadores de BigQuery Data Transfer Service a tu lista de IPs permitidas.

Para añadir intervalos de IPs como direcciones IP públicas permitidas a Amazon S3, consulta Restricciones de IP.

Consideraciones sobre la coherencia

Cuando transfieres datos de Amazon S3, es posible que algunos de tus datos no se transfieran a BigQuery, sobre todo si los archivos se han añadido al segmento recientemente. Un archivo tarda aproximadamente 5 minutos en estar disponible para BigQuery Data Transfer Service después de añadirse al segmento.

Prácticas recomendadas para reducir los costes de transferencia de datos de salida

Las transferencias de Amazon S3 pueden fallar si la tabla de destino no se ha configurado correctamente. Estos son algunos de los motivos por los que se puede producir una configuración incorrecta:

• 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 van a transferir.

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

Precios

Para obtener información sobre los precios de BigQuery Data Transfer Service, consulta la página Precios.

Ten en cuenta que es posible que se apliquen cargos adicionales fuera de Google por utilizar este servicio. Consulta la página de precios de Amazon S3 para obtener más información.

Cuotas y límites

BigQuery Data Transfer Service usa tareas de carga para cargar datos de Amazon S3 en BigQuery. Todas las cuotas y los límites de BigQuery en las tareas de carga se aplican a las transferencias periódicas de Amazon S3, con las siguientes consideraciones adicionales:

Siguientes pasos

• Consulta cómo configurar una transferencia de Amazon S3.
• Consulta información sobre los parámetros de tiempo de ejecución en las transferencias de S3.
• Más información sobre BigQuery Data Transfer Service