Introducción a las tablas externas de BigLake

En este documento se ofrece una descripción general de BigLake y se presupone que el lector está familiarizado con las tablas de bases de datos y con Gestión de Identidades y Accesos (IAM). Para consultar los datos almacenados en los almacenes de datos admitidos, primero debes crear tablas de BigLake y, después, consultarlas con la sintaxis de GoogleSQL:

También puedes actualizar una tabla externa a BigLake. Para obtener más información, consulta Actualizar una tabla externa a BigLake.

Las tablas de BigLake te permiten consultar datos estructurados en almacenes de datos externos con delegación de acceso. La delegación de acceso desacopla el acceso a la tabla de BigLake del acceso al almacén de datos subyacente. Se usa una conexión externa asociada a una cuenta de servicio para conectarse al almacén de datos. Como la cuenta de servicio se encarga de obtener los datos del almacén de datos, solo tiene que conceder acceso a los usuarios a la tabla de BigLake. De esta forma, puedes aplicar una seguridad pormenorizada a nivel de tabla, incluida la seguridad a nivel de fila y de columna. En el caso de las tablas de BigLake basadas en Cloud Storage, también puedes usar el enmascaramiento dinámico de datos. Para obtener más información sobre las soluciones de analíticas multinube que usan tablas de BigLake con datos de Amazon S3 o Blob Storage, consulta BigQuery Omni.

Almacenes de datos admitidos

Puedes usar tablas de BigLake con los siguientes almacenes de datos:

Compatibilidad con tablas temporales

Las tablas de BigLake basadas en Cloud Storage pueden ser temporales o permanentes. Las tablas de BigLake basadas en Amazon S3 o Blob Storage deben ser permanentes.

Varios archivos de origen

Puede crear una tabla de BigLake basada en varias fuentes de datos externas, siempre que tengan el mismo esquema.

Uniones entre nubes

Las combinaciones entre nubes te permiten ejecutar consultas que abarcan regiones de Google Cloud y de BigQuery Omni. Puedes usar las operaciones de GoogleSQL JOIN para analizar datos de muchas soluciones de almacenamiento diferentes, como AWS, Azure, conjuntos de datos públicos y otros servicios Google Cloud . Las combinaciones entre nubes eliminan la necesidad de copiar datos entre fuentes antes de ejecutar consultas.

Puedes hacer referencia a las tablas de BigLake en cualquier parte de una instrucción SELECT como si fueran tablas de BigQuery estándar, incluidas las instrucciones del lenguaje de manipulación de datos (DML) y del lenguaje de definición de datos (DDL) que usan subconsultas para recuperar datos. Puedes usar varias tablas BigLake de diferentes nubes y tablas de BigQuery en la misma consulta. Todas las tablas de BigQuery deben ser de la misma región.

Permisos necesarios para unirse entre nubes

Para obtener los permisos que necesitas para ejecutar una combinación entre nubes, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos en el proyecto en el que se ejecuta la combinación:

Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

Estos roles predefinidos contienen los permisos necesarios para ejecutar una combinación entre nubes. Para ver los permisos exactos que se necesitan, despliega la sección Permisos necesarios:

Permisos obligatorios

Se necesitan los siguientes permisos para ejecutar una combinación entre nubes:

  • bigquery.jobs.create
  • bigquery.tables.getData

También puedes obtener estos permisos con roles personalizados u otros roles predefinidos.

Costes de las uniones entre nubes

Cuando ejecutas una operación de unión entre nubes, BigQuery analiza la consulta en partes locales y remotas. La parte local se trata como una consulta estándar en la región de BigQuery. La parte remota se convierte en una operación CREATE TABLE AS SELECT (CTAS) en la tabla de BigLake a la que se hace referencia en la región de BigQuery Omni, lo que crea una tabla temporal en tu región de BigQuery. A continuación, BigQuery usa esta tabla temporal para ejecutar la unión entre nubes y elimina la tabla automáticamente al cabo de ocho horas.

Se te cobrará por la transferencia de datos de las tablas BigLake a las que se haga referencia. Sin embargo, BigQuery ayuda a reducir estos costes transfiriendo solo las columnas y las filas de la tabla de BigLake a las que se hace referencia en la consulta, en lugar de toda la tabla. Te recomendamos que especifiques un filtro de columna lo más acotado posible para reducir aún más los costes de transferencia. El trabajo de CTAS aparece en tu historial de trabajos y muestra información como el número de bytes transferidos. Las transferencias completadas con éxito generan costes aunque falle la tarea de consulta principal. Para obtener más información, consulta los precios de BigQuery Omni.

Veamos un ejemplo de consulta:

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

En este ejemplo, hay dos transferencias: una de una tabla de empleados (con un filtro de nivel) y otra de una tabla de empleados activos. La unión se realiza en la región de BigQuery después de la transferencia. Si una transferencia falla y la otra se realiza correctamente, se aplican los cargos de transferencia de datos a la transferencia correcta.

Limitaciones de la unión entre nubes

  • Las combinaciones entre nubes no se admiten en el nivel gratuito de BigQuery ni en la zona de pruebas de BigQuery.
  • Es posible que las agregaciones no se inserten en las regiones de BigQuery Omni si la consulta contiene instrucciones JOIN.
  • Cada tabla temporal solo se usa en una consulta entre nubes y no se reutiliza aunque se repita la misma consulta varias veces.
  • El límite de tamaño de cada transferencia es de 60 GB. En concreto, si aplicas un filtro a una tabla de BigLake y cargas el resultado, este debe ser inferior a 60 GB. Si es necesario, puedes solicitar un ajuste de la cuota. No hay límite de bytes analizados.
  • Las consultas de unión entre nubes tienen una cuota interna sobre la frecuencia de las consultas. Si la tasa de consultas supera la cuota, es posible que recibas un error All our servers are busy processing data transferred between regions. Volver a intentar la consulta debería funcionar en la mayoría de los casos. Ponte en contacto con el equipo de Asistencia para aumentar la cuota interna y admitir una tasa de consultas más alta.
  • Las combinaciones entre nubes solo se admiten en las regiones de BigQuery ubicadas en el mismo lugar que sus regiones de BigQuery Omni correspondientes, así como en las multirregiones US y EU. Las combinaciones entre nubes que se ejecutan en las multirregiones US o EU solo pueden acceder a datos de las regiones de BigQuery Omni de EE. UU. o de la UE, respectivamente.
  • Si una consulta de unión entre nubes hace referencia a 10 o más conjuntos de datos de regiones de BigQuery Omni, puede fallar y mostrar el error Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. Para evitar este problema, le recomendamos que especifique explícitamente una ubicación cuando ejecute una unión entre nubes que haga referencia a más de 10 conjuntos de datos. Tenga en cuenta que, si especifica explícitamente una región de BigQuery y su consulta solo contiene tablas de BigLake, la consulta se ejecutará como una consulta entre nubes y se le cobrarán costes de transferencia de datos.
  • No puedes consultar la pseudocolumna _FILE_NAME con uniones entre nubes.
  • Cuando haces referencia a las columnas de una tabla BigLake en una cláusula WHERE, no puedes usar literales INTERVAL ni RANGE.
  • Las tareas de combinación entre nubes no registran el número de bytes que se procesan y transfieren desde otras nubes. Esta información está disponible en los trabajos de CTAS secundarios que se crean como parte de la ejecución de consultas entre nubes.
  • Las vistas autorizadas y las rutinas autorizadas que hacen referencia a tablas o vistas de BigQuery Omni solo se admiten en regiones de BigQuery Omni.
  • Si tu consulta entre nubes hace referencia a columnas STRUCT o JSON, no se aplicará ningún pushdown a las subconsultas remotas. Para optimizar el rendimiento, te recomendamos que crees una vista en la región de BigQuery Omni que filtre las columnas STRUCT y JSON y devuelva solo los campos necesarios como columnas individuales.
  • Las intercalaciones no se admiten en las combinaciones entre nubes.

Ejemplos de combinaciones entre nubes

La siguiente consulta combina una tabla orders de una región de BigQuery con una tabla lineitem de una región de BigQuery Omni:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Esta consulta se divide en partes locales y remotas. La siguiente consulta se envía a la región de BigQuery Omni para que se ejecute primero. El resultado es una tabla temporal en la región de BigQuery. Puedes ver este trabajo de CTAS secundario y sus metadatos en tu historial de trabajos.

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

Una vez que se crea la tabla temporal, se completa la operación JOIN y se ejecuta la siguiente consulta:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Veamos otro ejemplo de combinación entre nubes:

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
SELECT c_mktsegment, c_name
FROM aws_dataset.customer
WHERE c_mktsegment = 'FURNITURE'
LIMIT 10;

En esta consulta, la cláusula LIMIT no se envía a la región de BigQuery Omni. Todos los clientes del segmento de mercado FURNITURE se transfieren primero a la región de BigQuery y, a continuación, se aplica el límite de 10.

Conectores

Puedes acceder a los datos de las tablas de BigLake basadas en Cloud Storage desde otras herramientas de procesamiento de datos mediante conectores de BigQuery. Por ejemplo, puedes acceder a los datos de las tablas BigLake desde Apache Spark, Apache Hive, TensorFlow, Trino o Presto. La API Storage de BigQuery aplica políticas de gobernanza a nivel de fila y de columna en todos los accesos a datos de las tablas de BigLake, incluidos los que se realizan a través de conectores.

Por ejemplo, el siguiente diagrama muestra cómo la API Storage de BigQuery permite a los usuarios acceder a datos autorizados mediante motores de consulta de código abierto, como Apache Spark:

Arquitectura de BigLake.

Para obtener más información sobre los conectores compatibles con BigQuery, consulta Conectores de BigQuery.

Tablas de BigLake en almacenes de objetos

Para los administradores de lagos de datos, BigLake permite definir controles de acceso en las tablas en lugar de en los archivos, lo que ofrece opciones más detalladas al configurar el acceso de los usuarios a los datos del lago de datos.

Como las tablas de BigLake simplifican el control de acceso de esta forma, te recomendamos que las uses para crear y mantener conexiones con almacenes de objetos externos.

Puede usar tablas externas en los casos en los que no se requiera gobernanza o para descubrir y manipular datos de forma puntual.

Limitaciones

  • Todas las limitaciones de las tablas externas se aplican a las tablas de BigLake.
  • Las tablas de BigLake en almacenes de objetos están sujetas a las mismas limitaciones que las tablas de BigQuery. Para obtener más información, consulta Cuotas.

  • BigLake no admite credenciales con ámbito reducido de Autenticación de clúster personal de Dataproc. Como solución alternativa, para usar clústeres con autenticación de clústeres personales, debes insertar tus credenciales mediante un Credential Access Boundary vacío con la marca --access-boundary=<(echo -n "{}"). Por ejemplo, el siguiente comando habilita una sesión de propagación de credenciales en un proyecto llamado myproject para el clúster llamado mycluster: 

    gcloud dataproc clusters enable-personal-auth-session \
    --region=us \
    --project=myproject \
    --access-boundary=<(echo -n "{}") \
    mycluster

  • Las tablas de BigLake son de solo lectura. No puedes modificar las tablas de BigLake con instrucciones DML ni con otros métodos.

  • Las tablas de BigLake admiten los siguientes formatos:

  • No puedes usar metadatos almacenados en caché con tablas externas de Apache Iceberg, ya que BigQuery usa los metadatos que Iceberg captura en los archivos de manifiesto.

  • La API Storage de BigQuery no está disponible en otros entornos de nube, como AWS y Azure.

  • Si usas metadatos almacenados en caché, se aplican las siguientes limitaciones:

    • Solo puedes usar metadatos almacenados en caché con tablas BigLake que usen los formatos Avro, ORC, Parquet, JSON y CSV.
    • Si crea, actualiza o elimina archivos en Amazon S3, al consultar los archivos no se devolverán los datos actualizados hasta la próxima actualización de la caché de metadatos. Esto puede dar lugar a resultados inesperados. Por ejemplo, si eliminas un archivo y escribes uno nuevo, es posible que los resultados de tu consulta excluyan tanto el archivo antiguo como el nuevo, en función de cuándo se actualizó por última vez la metainformación almacenada en caché.
    • No se admite el uso de claves de cifrado gestionadas por el cliente (CMEK) con metadatos almacenados en caché en tablas BigLake que hagan referencia a datos de Amazon S3 o Blob Storage.

Modelo de seguridad

Los siguientes roles de organización suelen participar en la gestión y el uso de tablas BigLake:

  • Administradores de lagos de datos. Estos administradores suelen gestionar las políticas de gestión de identidades y accesos (IAM) en los segmentos y objetos de Cloud Storage.
  • Administradores de almacenes de datos. Estos administradores suelen crear, eliminar y actualizar tablas.
  • Analistas de datos. Los analistas suelen leer datos y ejecutar consultas.

Los administradores de lagos de datos son responsables de crear conexiones y compartirlas con los administradores de almacenes de datos. A su vez, los administradores del almacén de datos crean tablas, definen los controles de acceso adecuados y comparten las tablas con los analistas de datos.

Almacenamiento en caché de metadatos para mejorar el rendimiento

Puede usar metadatos almacenados en caché para mejorar el rendimiento de las consultas en algunos tipos de tablas de BigLake. El almacenamiento en caché de metadatos es especialmente útil cuando trabajas con un gran número de archivos o si los datos están particionados en Hive. Los siguientes tipos de tablas de BigLake admiten el almacenamiento de metadatos en caché:

  • Tablas de BigLake de Amazon S3
  • Tablas de BigLake de Cloud Storage
BigQuery usa CMETA como sistema de metadatos distribuido para gestionar tablas grandes de forma eficiente. CMETA proporciona metadatos pormenorizados a nivel de columna y de bloque, a los que se puede acceder a través de tablas del sistema. Este sistema ayuda a mejorar el rendimiento de las consultas optimizando el acceso y el procesamiento de los datos. Para acelerar aún más el rendimiento de las consultas en tablas grandes, BigQuery mantiene una caché de metadatos. Los trabajos de actualización de CMETA mantienen esta caché actualizada.

Los metadatos incluyen nombres de archivo, información de partición y metadatos físicos de archivos, como el número de filas. Puedes elegir si quieres habilitar el almacenamiento en caché de metadatos en una tabla. Las consultas con un gran número de archivos y con filtros de partición de Apache Hive son las que más se benefician del almacenamiento en caché de metadatos.

Si no habilita el almacenamiento en caché de metadatos, las consultas en la tabla deben leer la fuente de datos externa para obtener los metadatos del objeto. La lectura de estos datos aumenta la latencia de las consultas. Listar millones de archivos de la fuente de datos externa puede llevar varios minutos. Si habilitas el almacenamiento en caché de metadatos, las consultas pueden evitar enumerar archivos de la fuente de datos externa y pueden particionar y eliminar archivos más rápidamente.

El almacenamiento en caché de metadatos también se integra con la gestión de versiones de objetos de Cloud Storage. Cuando se rellena o se actualiza la caché, se capturan los metadatos en función de la versión activa de los objetos de Cloud Storage en ese momento. Por lo tanto, las consultas con el almacenamiento en caché de metadatos habilitado leen los datos correspondientes a la versión específica del objeto almacenado en caché, aunque se publiquen versiones más recientes en Cloud Storage. Para acceder a los datos de las versiones de objetos actualizadas posteriormente en Cloud Storage, es necesario actualizar la caché de metadatos.

Hay dos propiedades que controlan esta función:

  • Antigüedad máxima especifica cuándo las consultas usan metadatos almacenados en caché.
  • El modo de caché de metadatos especifica cómo se recogen los metadatos.

Si tienes habilitada la caché de metadatos, puedes especificar el intervalo máximo de obsolescencia de los metadatos que se acepta para las operaciones en la tabla. Por ejemplo, si especificas un intervalo de 1 hora, las operaciones en la tabla usarán los metadatos almacenados en caché si se han actualizado en la última hora. Si los metadatos almacenados en caché son anteriores a esa fecha, la operación recurre a la recuperación de metadatos del almacén de datos (Amazon S3 o Cloud Storage). Puedes especificar un intervalo de antigüedad entre 30 minutos y 7 días.

Cuando habilitas el almacenamiento de metadatos en caché para tablas de BigLake o de objetos, BigQuery activa tareas de actualización de la generación de metadatos. Puedes actualizar la caché de forma automática o manual:

  • En el caso de las actualizaciones automáticas, la caché se actualiza a intervalos definidos por el sistema, normalmente entre 30 y 60 minutos. Actualizar la caché automáticamente es una buena opción si los archivos del almacén de datos se añaden, eliminan o modifican a intervalos aleatorios. Si necesitas controlar el momento de la actualización (por ejemplo, para activarla al final de un trabajo de extracción, transformación y carga), usa la actualización manual.

  • Para las actualizaciones manuales, ejecuta el procedimiento del sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para actualizar la caché de metadatos según una programación que se ajuste a tus necesidades. En el caso de las tablas BigLake, puedes actualizar los metadatos de forma selectiva proporcionando subdirectorios del directorio de datos de la tabla. De esta forma, se evita el procesamiento innecesario de metadatos. Actualizar la caché manualmente es una buena opción si los archivos del almacén de datos se añaden, eliminan o modifican a intervalos conocidos, por ejemplo, como resultado de una canalización.

    Si emite varias actualizaciones manuales simultáneas, solo se completará una.

La caché de metadatos caduca al cabo de 7 días si no se actualiza.

Tanto las actualizaciones de caché manuales como las automáticas se ejecutan con la prioridad de consulta INTERACTIVE.

Usar reservas de BACKGROUND

Si decides usar las actualizaciones automáticas, te recomendamos que crees una reserva y, a continuación, una asignación con el tipo de tarea BACKGROUND para el proyecto que ejecute las tareas de actualización de la caché de metadatos. Con las reservas de BACKGROUND, las tareas de actualización usan un grupo de recursos específico, lo que evita que compitan con las consultas de los usuarios y que puedan fallar si no hay suficientes recursos disponibles.

Aunque el uso de un grupo de ranuras compartido no conlleva ningún coste adicional, el uso de BACKGROUND reservas proporciona un rendimiento más constante al asignar un grupo de recursos específico y mejora la fiabilidad de los trabajos de actualización y la eficiencia general de las consultas en BigQuery.

Antes de definir los valores del intervalo de obsolescencia y del modo de almacenamiento en caché de metadatos, debes tener en cuenta cómo interactuarán. Ten en cuenta los siguientes ejemplos:

  • Si actualizas manualmente la caché de metadatos de una tabla y estableces el intervalo de obsolescencia en 2 días, debes ejecutar el procedimiento del sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE cada 2 días o menos si quieres que las operaciones de la tabla usen metadatos almacenados en caché.
  • Si actualizas automáticamente la caché de metadatos de una tabla y estableces el intervalo de obsolescencia en 30 minutos, es posible que algunas de tus operaciones en la tabla lean del almacén de datos si la actualización de la caché de metadatos tarda más de lo habitual (entre 30 y 60 minutos).

Para obtener información sobre los trabajos de actualización de metadatos, consulta la vista INFORMATION_SCHEMA.JOBS, como se muestra en el siguiente ejemplo:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

En el caso de las tablas de BigLake de Cloud Storage basadas en archivos Parquet, las estadísticas de la tabla se recogen durante la actualización de la caché de metadatos y se usan para mejorar los planes de consulta.

Para obtener más información, consulta Almacenamiento en caché de metadatos.

Para obtener más información sobre cómo definir las opciones de almacenamiento en caché de metadatos, consulta Crear tablas de BigLake de Amazon S3 o Crear tablas de BigLake de Cloud Storage.

Tablas habilitadas para la caché con vistas materializadas

Puedes usar vistas materializadas en tablas con la caché de metadatos de BigLake habilitada para mejorar el rendimiento y la eficiencia al consultar datos estructurados almacenados en Cloud Storage o Amazon Simple Storage Service (Amazon S3). Estas vistas materializadas funcionan como vistas materializadas en tablas de almacenamiento gestionadas por BigQuery, incluidas las ventajas de la actualización automática y la optimización inteligente.

Integraciones

Se puede acceder a las tablas de BigLake desde otras funciones de BigQuery y servicios de la CLI de gcloud, incluidos los siguientes servicios destacados.

Compartir datos de BigQuery (antes Analytics Hub)

Las tablas de BigLake son compatibles con la función Compartir. Los conjuntos de datos que contienen tablas de BigLake se pueden publicar como fichas de uso compartido. Los suscriptores que comparten pueden suscribirse a estas fichas, que proporcionan un conjunto de datos de solo lectura, denominado conjunto de datos vinculado, en su proyecto. Los suscriptores pueden consultar todas las tablas del conjunto de datos vinculado, incluidas todas las tablas BigLake. Para obtener más información, consulta Ver y suscribirse a fichas.

BigQuery ML

Puedes usar BigQuery ML para entrenar y ejecutar modelos en BigLake en Cloud Storage.

Protección de datos sensibles

Protección de datos sensibles analiza tus tablas de BigLake para identificar y clasificar datos sensibles. Si se detectan datos sensibles, las transformaciones de desidentificación de Protección de Datos Sensibles pueden enmascarar, eliminar u ocultar de cualquier otra forma esos datos.

Costes

Los costes están asociados a los siguientes aspectos de las tablas de BigLake:

Si tienes reservas de ranuras, no se te cobrará por consultar tablas externas. En su lugar, se consumen slots para estas consultas.

En la siguiente tabla se muestra cómo influye tu modelo de precios en la forma en que se aplican estos costes:


Precios bajo demanda
Ediciones Standard, Enterprise y Enterprise Plus

Consultas
Se te cobra por los bytes procesados por las consultas de los usuarios.
Las ranuras de las asignaciones de reservas con el tipo de trabajo QUERY se consumen durante el tiempo de consulta.

Actualizar manualmente la caché de metadatos.
Se te facturan los bytes procesados para actualizar la caché.
Los slots de las asignaciones de reservas con un tipo de trabajo QUERY se consumen durante la actualización de la caché.

Actualizar automáticamente la caché de metadatos.
Se te facturan los bytes procesados para actualizar la caché.
Los slots de las asignaciones de reservas con un tipo de trabajo BACKGROUND se consumen durante la actualización de la caché.

Si no hay reservas BACKGROUND disponibles para actualizar la caché de metadatos, BigQuery usará automáticamente las ranuras de las reservas QUERY si usas la edición Enterprise o Enterprise Plus.

También se te cobrará por el almacenamiento y el acceso a los datos de Cloud Storage, Amazon S3 y Azure Blob Storage, según las directrices de precios de cada producto.

Siguientes pasos