Introducción a las transferencias de Blob Storage
El Servicio de transferencia de datos de BigQuery para Azure Blob Storage te permite administrar y programar de manera automática trabajos de carga recurrentes de Azure Blob Storage y Azure Data Lake Storage Gen2 en BigQuery.
Formatos de archivo compatibles
En la actualidad, el Servicio de transferencia de datos de BigQuery es compatible con la carga de datos de Blob Storage en 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 Blob Storage admite 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 para las transferencias
Para cargar datos desde una fuente de datos de Blob Storage, primero recopila lo siguiente:
- El nombre de la cuenta de Blob Storage, el nombre del contenedor y la ruta de datos (opcional) para tus datos de origen. El campo de ruta de los datos es opcional. se usa para hacer coincidir prefijos de objeto y extensiones de archivo comunes. Si se omite la ruta de acceso de los datos, se transfieren todos los archivos del contenedor.
- Un token de firma de acceso compartido (SAS) de Azure que otorga acceso de lectura a tu fuente de datos. Para obtener detalles sobre cómo crear un token SAS, consulta Firma de acceso compartido (SAS).
Parametrización del entorno de ejecución de transferencia
La ruta de datos y la tabla de destino de Blob Storage se pueden parametrizar, lo que te permite cargar datos de contenedores organizados por fecha. Los parámetros que usan las transferencias de Blob Storage son los mismos que los que usan 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 Azure Blob
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 Azure Blob.
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 tiempoupdated
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 tiempoupdated
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 correctamentefile_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 de comodines para la ruta de datos de Blob Storage
Puedes seleccionar datos de origen separados en varios archivos si especificas
uno o más caracteres comodín de asterisco (*
) en la ruta de datos.
Si bien se puede usar más de un comodín en la ruta de datos, es posible implementar un proceso de optimización cuando se usa 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, la ruta de acceso de los datos
my-folder/*.csv
coincidirá con el archivomy-folder/my-subfolder/my-file.csv
.
Ejemplos de rutas de acceso de datos de Blob Storage
Los siguientes son ejemplos de rutas de datos válidas para una transferencia de
Blob Storage. Ten en cuenta que las rutas de datos no comienzan con /
.
Ejemplo: Archivo único
Para cargar un solo archivo de Blob Storage en BigQuery, especifica el nombre de archivo de Blob Storage:
my-folder/my-file.csv
Ejemplo: Todos los archivos
Para cargar todos los archivos de un contenedor de Blob Storage en BigQuery, establece la ruta de acceso de los datos en un solo comodín:
*
Ejemplo: Archivos con un prefijo común
Para cargar todos los archivos de Blob Storage que tienen un prefijo en común, especifica el prefijo en común con o sin un comodín:
my-folder/
o
my-folder/*
Ejemplo: Archivos con una ruta similar
Para cargar todos los archivos de Blob Storage con una ruta de acceso similar, especifica el prefijo y el sufijo comunes:
my-folder/*.csv
Cuando usas un solo comodín, abarca directorios. En este ejemplo,
se selecciona cada archivo CSV en my-folder
, así como cada archivo CSV en cada
subcarpeta de my-folder
.
Ejemplo: Comodín al final de la ruta de acceso
Considera la siguiente ruta de datos:
logs/*
Se seleccionaron todos los archivos siguientes:
logs/logs.csv
logs/system/logs.csv
logs/some-application/system_logs.log
logs/logs_2019_12_12.csv
Ejemplo: Comodín al comienzo de la ruta de acceso
Considera la siguiente ruta de datos:
*logs.csv
Se seleccionaron todos los archivos siguientes:
logs.csv
system/logs.csv
some-application/logs.csv
Y no se seleccionó ninguno de los siguientes archivos:
metadata.csv
system/users.csv
some-application/output.csv
Ejemplo: Varios comodines
Si usas varios comodines, obtienes más control sobre la selección de archivos, al costo de límites inferiores. Cuando usas varios comodines, cada comodín individual solo abarca un único subdirectorio.
Considera la siguiente ruta de datos:
*/*.csv
Se seleccionaron los siguientes archivos:
my-folder1/my-file1.csv
my-other-folder2/my-file2.csv
Y no se seleccionó ninguno de los siguientes archivos:
my-folder1/my-subfolder/my-file3.csv
my-other-folder2/my-subfolder/my-file4.csv
Firma de acceso compartido (SAS)
El token SAS de Azure se usa para acceder a los datos de Blob Storage en tu nombre. Sigue estos pasos a fin de crear un token SAS para su transferencia:
- Crea un usuario de Blob Storage o usa uno existente para acceder a la cuenta de almacenamiento de tu contenedor de Blob Storage.
Crea un token SAS a nivel de la cuenta de almacenamiento. Para crear un token SAS con Azure Portal, haz lo siguiente:
- En Servicios permitidos, selecciona Blob.
- En Tipos de recursos permitidos, selecciona Contenedor y Objeto.
- En Permisos permitidos, selecciona Leer y Lista.
- El tiempo de vencimiento predeterminado para los tokens SAS es de 8 horas. Establece una fecha de vencimiento que funcione para tu programa de transferencia.
- No especifiques ninguna dirección IP en el campo Direcciones IP permitidas.
- En Protocolos permitidos, selecciona Solo HTTPS.
Después de crear el token SAS, ten en cuenta el valor del token SAS que se muestra. Necesitas este valor cuando configuras las transferencias.
Restricciones de IP
Si restringes el acceso a tus recursos de Azure mediante un firewall de Azure Storage, debes agregar los rangos de IP que usan los trabajadores del Servicio de transferencia de datos de BigQuery a tu lista de IPs permitidas.
Para agregar rangos de IP como IPs permitidas a los firewalls de Azure Storage, consulta Restricciones de IP.
Consideraciones de coherencia
El archivo debe tardar aproximadamente 10 minutos en estar disponible para el Servicio de transferencia de datos de BigQuery después de agregarlo al contenedor de Blob Storage.
Prácticas recomendadas para controlar los costos de salida
Las transferencias de Blob Storage podrían fallar si la tabla de destino no está configurada de forma correcta. Entre las posibles causas de una configuración incorrecta, se incluyen las 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 costos adicionales de salida de Blob Storage, primero prueba una transferencia con un subconjunto de archivos pequeño pero representativo. Asegúrate de que esta prueba sea pequeña en cuanto al tamaño de los datos y la cantidad de archivos.
También es importante tener en cuenta que la coincidencia de prefijos para las rutas de datos ocurre antes de que los archivos se transfieran desde Blob Storage, pero la coincidencia de comodines ocurre dentro de Google Cloud. Esta distinción podría aumentar los costos de salida de Blob Storage para los archivos que se transfieren a Google Cloud, pero no se cargan en BigQuery.
A modo de ejemplo, considera esta ruta de datos:
folder/*/subfolder/*.csv
Los siguientes archivos se transfieren a Google Cloud, porque
tienen el prefijo folder/
:
folder/any/subfolder/file1.csv
folder/file2.csv
Sin embargo, solo el archivo folder/any/subfolder/file1.csv
se carga en
BigQuery, ya que coincide con la ruta de acceso completa de los datos.
Precios
Para obtener más información, consulta los precios del Servicio de transferencia de datos de BigQuery.
También puedes incurrir en costos fuera de Google por el uso de este servicio. Para obtener más información, consulta los precios de Blob Storage.
Cuotas y límites
El Servicio de transferencia de datos de BigQuery usa trabajos de carga para cargar los datos de Blob Storage en BigQuery. Todas las cuotas y límites de BigQuery para los trabajos de carga se aplican a las transferencias recurrentes de Blob Storage, con las siguientes consideraciones adicionales:
Límite | Predeterminado |
---|---|
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 la ruta de datos de Blob Storage incluye 0 o 1 comodines | 10,000,000 de archivos |
Cantidad máxima de archivos por ejecución de transferencia cuando la ruta de datos de Blob Storage incluye 2 o más comodines | 10,000 archivos |
¿Qué sigue?
- Obtén más información sobre cómo configurar una transferencia de Blob Storage.
- Obtén más información sobre los parámetros de entorno de ejecución en las transferencias.
- Obtén más información acerca del Servicio de transferencia de datos de BigQuery.