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 de transferencia

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 acceso de los datos (opcional) para los datos de origen. El campo de ruta de acceso a los datos es opcional; se usa para hacer coincidir prefijos de objeto y extensiones de archivos comunes. Si se omite la ruta de datos, se transfieren todos los archivos en el 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, consulte Firma de acceso compartido (SAS).

Parametrización del entorno de ejecución de transferencia

La ruta de acceso de los datos de Blob Storage y la tabla de destino se pueden parametrizar, lo que te permite cargar datos de contenedores organizados por fecha. Las transferencias de Cloud Storage 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 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 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 de comodines para la ruta de datos de Blob Storage

Puedes seleccionar datos de origen que estén 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 realizar alguna optimización cuando se usa solo un 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 datos my-folder/*.csv coincidirá con el archivo my-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, configura 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 comparten un prefijo común, especifica el prefijo común con o sin un comodín:

my-folder/

o

my-folder/*

Ejemplo: Archivos con una ruta de acceso 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 solo usas un solo comodín, abarca directorios. En este ejemplo, se selecciona cada archivo CSV de my-folder y cada archivo CSV de cada subcarpeta de my-folder.

Ejemplo: Comodín al final de la ruta de acceso

Considera la siguiente ruta de datos:

logs/*

Se seleccionan los siguientes archivos:

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 seleccionan los siguientes archivos:

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

Cuando 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 solo 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 de Azure SAS 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:

  1. Crea un usuario de Blob Storage o usa uno existente para acceder a la cuenta de almacenamiento de tu contenedor de Blob Storage.

  2. Crea un token SAS a nivel de la cuenta de almacenamiento. Para crear un token SAS con Azure Portal, haz lo siguiente:

    1. En Servicios permitidos, selecciona Blob.
    2. En Tipos de recursos permitidos, selecciona Contenedor y Objeto.
    3. En Permisos permitidos, selecciona Lectura y Lista.
    4. El tiempo de vencimiento predeterminado para los tokens SAS es de 8 horas. Establece un plazo de vencimiento que se adapte a tu programación de transferencia.
    5. No especifiques ninguna dirección IP en el campo Direcciones IP permitidas.
    6. En Protocolos permitidos, selecciona Solo HTTPS.

    SAS del portal de Azure

  3. 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 pueden fallar si la tabla de destino no está configurada de forma correcta. Las posibles causas de una configuración incorrecta 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 pequeño pero representativo de archivos. Asegúrate de que esta prueba sea pequeña en cuanto al tamaño de los datos y el recuento 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 puede aumentar los costos de salida de Blob Storage para los archivos que se transfieren a Google Cloud, pero que 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 datos completa.

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 Default
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?