Acerca del acceso a los datos en distintas nubes

La función de acceso a datos multinube te permite consultar datos almacenados en otros proveedores de servicios en la nube directamente desde Google Cloud sin migrar archivos ni compilar canalizaciones de ETL complejas. Las consultas se pueden enrutar a través de la Internet pública o usar Cross‑Cloud Interconnect para el transporte de redes privadas.

El acceso a los datos multinube en Lakehouse unifica las cargas de trabajo de análisis y de IA en tus conjuntos de datos distribuidos a través de BigQuery, entornos independientes de Apache Spark o Managed Service para Apache Spark.

Además de ejecutar consultas analíticas, puedes crear agentes de análisis conversacional basados en tus tablas distribuidas, incluidas las fuentes multinube, para analizar datos en diferentes nubes desde una sola conversación. También puedes usar Knowledge Catalog para crear perfiles de datos y obtener estadísticas en plataformas remotas.

Cuándo usar el acceso a los datos multinube

A continuación, se muestran algunos casos de uso comunes:

  • Consulta tablas de múltiples nubes in situ: Ejecuta análisis de SQL de BigQuery y Managed Service para Apache Spark directamente en tablas externas de Apache Iceberg en Amazon Web Services (AWS) y Microsoft Azure sin migrar archivos ni mantener canalizaciones de ETL.
  • Aplicar el aislamiento de red privada entre nubes: Enruta las lecturas de datos de consultas y la actualización de metadatos en segundo plano a través de Cross‑Cloud Interconnect para ayudar a cumplir con las políticas de seguridad y cumplimiento que restringen el tráfico de Internet público.
  • Reduce los costos recurrentes de transferencia de datos multinube: combina las tarifas de salida de interconexión privada predecibles con el almacenamiento en caché de bloques local automático enGoogle Cloud para los paneles de IE y las cargas de trabajo analíticas repetidas.
  • Unifica la administración multinube y los agentes de IA: fundamenta los agentes de estadísticas conversacionales en tablas distribuidas y aplica el descubrimiento, la generación de perfiles y el linaje de Knowledge Catalog en todas las nubes.

Arquitectura

En el siguiente diagrama, se ilustra la arquitectura de acceso a los datos multinube de Lakehouse:

Arquitectura del acceso a los datos de Lakehouse multinube en Google Cloud, Amazon Web Services (AWS) y socios de SaaS.
La arquitectura de Lakehouse conecta los motores de IA y análisis de Google Cloud con catálogos de nubes externas, almacenamiento de objetos y socios de SaaS.

En el diagrama anterior, se ilustra la arquitectura en Google Cloud y los entornos externos de SaaS y de nube:

  • Google Cloud: Proporciona IA, administración, análisis y acceso a datos multinube en conjuntos de datos remotos:
    • Agentes y experiencias de IA: Crea agentes autónomos en Conversational Analytics y Gemini Enterprise que buscan datos y significado semántico en Knowledge Catalog y ejecutan consultas a través de motores de análisis y procesamiento.
    • Knowledge Catalog: Ofrece administración unificada y linaje de datos, junto con estadísticas de datos, generación de perfiles y productos de datos, a través de la sincronización de metadatos y linaje de Lakehouse.
    • Motores de análisis y procesamiento: Ejecuta cargas de trabajo de BigQuery SQL, BigQuery AI y Looker, o procesa datos remotos con Managed Service para Apache Spark y motores abiertos (Apache Spark, Apache Flink y Trino) resolviendo metadatos y leyendo tablas a través de Lakehouse.
    • Acceso a datos multinube de Lakehouse: Consulta datos remotos in situ sin migración de archivos ni canalizaciones de ETL:
      • Sincronización de metadatos: Descubre y sincroniza los metadatos de las tablas a través de Apache Iceberg REST y Delta Sharing con el catálogo de tiempo de ejecución de Lakehouse, se autentica a través de OpenID Connect (OIDC) o Secret Manager, y vende credenciales temporales con alcance.
      • Funciones multinube (AWS): Almacena en caché los bloques de datos de lectura en Google Cloud con una caché de lectura directa a nivel de bloque (almacenamiento en caché inteligente [caché local]) y enruta el tráfico a través de Cross‑Cloud Interconnect dedicada (CCI), la interconexión de socio o Internet (con TLS) con el transporte de red multinube.
  • Fuentes de datos externas de SaaS y de la nube: Aloja los catálogos remotos, las nubes de datos de SaaS y el almacén de objetos:
    • Catálogos externos de SaaS y de la nube: Sincroniza metadatos de catálogos de datos de la nube (AWS Glue Data Catalog en AWS, y Databricks Unity Catalog y Snowflake Horizon Catalog en AWS o Google Cloud) y nubes de datos de SaaS (Salesforce Data Cloud, Workday Data Lake en AWS oGoogle Cloudy SAP Business Data Cloud [BDC]) a través de la API de REST de Iceberg y Delta Sharing (para SAP BDC).
    • Almacenamiento de objetos en la nube externo (AWS): Almacena tablas de Apache Iceberg (archivos de datos de Parquet) y tablas de Amazon S3 en Amazon S3 para lecturas de bloques directas a través de CCI o Internet (con TLS).

Cómo funciona el acceso a los datos multinube

Lakehouse consulta datos remotos con el siguiente proceso:

  1. Detección de metadatos: El catálogo de tiempo de ejecución de Lakehouse se conecta a los extremos remotos del catálogo de REST de Apache Iceberg, como Databricks Unity Catalog, AWS Glue Data Catalog o Snowflake Horizon Catalog, para descubrir los metadatos de las tablas sin copiar archivos. Según el proveedor de catálogo remoto, Lakehouse se autentica a través de Secret Manager o la federación de tokens de OIDC con Google como proveedor de identidad.
  2. Transporte seguro: Elegir enrutar el tráfico a través de una interconexión privada (por ejemplo, CCI dedicada o interconexión de socio) reduce significativamente los costos de transferencia de datos en comparación con la Internet pública y hace que la latencia sea muy predecible.
  3. Ejecución optimizada: Cuando habilitas el almacenamiento en caché multinube en tu catálogo o conexión federados, Lakehouse almacena en caché los bloques de archivos recuperados de forma local dentro de la región de ejecución de consultas de Google Cloud . Las consultas posteriores orientadas a los mismos bloques de archivos se leen directamente desde la caché local en lugar de volver a recuperar los archivos de la nube remota, lo que ayuda a reducir los costos de salida entre nubes y mejora el rendimiento de las consultas.

Catálogos admitidos

Lakehouse admite la consulta de datos de los siguientes proveedores de catálogos remotos:

Conceptos básicos

El acceso a los datos multinube separa la actualización de metadatos en segundo plano del transporte de datos de consulta, por lo que puedes enrutar una o ambas capas de tráfico de forma privada según tus requisitos de seguridad y costo.

Capa de metadatos

La capa de metadatos en el catálogo de tiempo de ejecución de Lakehouse se conecta a los extremos remotos del catálogo de REST de Apache Iceberg para sincronizar los metadatos de las tablas y los espacios de nombres de Apache Iceberg en función de un intervalo de actualización. Lakehouse se autentica con las credenciales almacenadas en Secret Manager o la federación de tokens de OIDC.

De forma predeterminada, las solicitudes de autenticación y actualización de metadatos en segundo plano se envían a través de la Internet pública con TLS. Cuando tu catálogo remoto restringe el acceso a la red pública o tu política de seguridad requiere tráfico privado del plano de control, puedes configurar un servicio de directorio de servicios de metadatos (--metadata-service-directory-name) para AWS Glue Data Catalog (en AWS), Databricks Unity Catalog (en AWS y Azure) y Snowflake Horizon Catalog (en AWS y Azure). Esta configuración enruta el tráfico de metadatos y autenticación de forma privada a través de Cross‑Cloud Interconnect dedicada o Cross‑Cloud Interconnect para socios (para AWS), de forma independiente o junto con el transporte de consultas privadas (--service-directory-name).

Capa de transporte

La capa de transporte permite que BigQuery y los motores de código abierto consulten los archivos de tablas remotas con los metadatos sincronizados de la capa de metadatos. En el caso de los catálogos remotos compatibles, Lakehouse admite la consulta de datos a través de la Internet pública o una interconexión privada dedicada.

Selecciona el método de transporte que coincida con tus requisitos de arquitectura y seguridad:

Propiedad del cliente (CCI)

Puedes configurar BigQuery para consultar datos almacenados en buckets de Amazon S3 o contenedores de Azure Data Lake Storage Gen2 (ADLS Gen2) a través de una conexión privada de Cross-Cloud Interconnect con Cross-Cloud Interconnect dedicado o Cross-Cloud Interconnect para socios.

El uso de una interconexión privada proporciona los siguientes beneficios:

  • Seguridad mejorada: Los datos viajan a través de una conexión de red privada entre Google Cloud y AWS o Azure, lo que evita el Internet público.
  • Reducción de costos: Es posible que se reduzcan los cargos de salida de AWS o Azure en comparación con la salida de Internet, en especial, cuando se combina con tu capacidad de interconexión privada.
  • Rendimiento constante: Latencia de red y ancho de banda más predecibles en comparación con la Internet pública.

Descripción general de la arquitectura

Para habilitar las consultas privadas, configura una ruta de acceso desde BigQuery hasta tu bucket de Amazon S3 o contenedor de ADLS Gen2 a través de tu interconexión privada. Un componente clave en la nube privada virtual (VPC) deGoogle Cloud es un balanceador de cargas interno (ILB). El ILB distribuye las solicitudes de BigQuery a los extremos privados de Amazon S3 dentro de tu VPC de AWS (aprovisionada con AWS PrivateLink) o de ADLS Gen2 dentro de tu red virtual de Azure (VNet), aprovisionada con Azure Private Link.

Usar un ILB con varias interfaces de red elásticas (ENI) o tarjetas de interfaz de red (NIC) como backends es esencial para el balanceo de cargas, la escalabilidad y la alta disponibilidad. Esto se aplica si usas la CCI dedicada o la interconexión de socio.

El flujo de trabajo de la consulta privada sigue este proceso:

  1. BigQuery usa una conexión configurada con un servicio del Directorio de servicios.
  2. El Directorio de servicios resuelve el nombre del servicio en la dirección IP interna del ILB de Google Cloud .
  3. El ILB recibe las solicitudes de BigQuery y las distribuye a los backends configurados.
  4. Los backends del ILB son grupos de extremos de red (NEG) de conectividad híbrida, cada uno de los cuales apunta a la dirección IP privada de una ENI en tu VPC de AWS o una NIC en tu VNet de Azure.
  5. El tráfico fluye desde el ILB, a través de los NEG, por la interconexión privada, hasta las ENI de AWS o las NIC de Azure.
  6. Las ENI de AWS, que forman parte de un extremo de interfaz de VPC de Amazon S3 (AWS PrivateLink), o las NIC de Azure, que forman parte de un extremo privado de ADLS Gen2 (Azure Private Link), proporcionan acceso privado al servicio de Amazon S3 o ADLS Gen2.

Internet público (sin CCI)

Si no configuras una interconexión privada, las consultas a tu catálogo remoto se envían a través de la Internet pública de forma predeterminada.

Cuando consultes datos a través de la Internet pública, ten en cuenta las siguientes implicaciones:

  • Encriptación estándar: Las solicitudes de acceso a los datos y las transferencias de datos se encriptan en tránsito con protocolos TLS estándar en la Internet pública.
  • Costos de salida: La transferencia de datos genera cargos de salida de Internet estándar desde tu proveedor de servicios en la nube remoto (por ejemplo, AWS o Azure), que suelen ser más altos que las tarifas de salida de interconexión privada.
  • Latencia variable: El rendimiento, el ancho de banda y la latencia de la red dependen del enrutamiento y la congestión de la Internet pública, lo que genera tiempos de ejecución de consultas menos predecibles en comparación con una interconexión privada dedicada.
  • Configuración simplificada: No requiere infraestructura de red adicional, intercambio de tráfico entre VPC ni configuración del Directorio de servicios en Google Cloud ni en tu proveedor de servicios en la nube remoto.

Descripción general de la arquitectura

Cuando se consultan datos a través de la Internet pública, Lakehouse se conecta directamente a los extremos de tu catálogo remoto y de tu almacén de objetos sin necesidad de una infraestructura de red de nube privada Google Cloud o remota.

El flujo de trabajo de la consulta de Internet pública sigue este proceso:

  1. BigQuery inicia una consulta en una tabla remota definida en tu catálogo de Lakehouse.
  2. Lakehouse se autentica de forma segura con tu catálogo remoto de Apache Iceberg con credenciales almacenadas en Secret Manager o la federación de tokens de OIDC.
  3. Lakehouse recupera los metadatos de la tabla y los archivos de manifiesto a través de la Internet pública para identificar los archivos de datos subyacentes pertinentes (por ejemplo, en Amazon S3 o ADLS Gen2).
  4. Las solicitudes de acceso a los datos para los objetos subyacentes se envían directamente desde Google Cloud a través de la Internet pública con la encriptación TLS estándar.
  5. El servicio de almacenamiento remoto verifica la solicitud con credenciales temporales y con alcance que Lakehouse vende y devuelve los bloques de archivos solicitados a través de la Internet pública a Google Cloud.

Almacenamiento en caché inteligente

Para ayudar a reducir los costos de salida multinube y acelerar las consultas que leen los mismos bloques de archivos, puedes habilitar el almacenamiento en caché multinube en tus catálogos federados de Lakehouse y en las conexiones multinube de BigQuery sin cargo adicional.

Cuando habilitas el almacenamiento en caché multinube, Lakehouse almacena en caché los bloques de archivos recuperados de Amazon S3 o Azure Blob Storage de forma local dentro de la región de ejecución de consultas de Google Cloud . Las consultas posteriores, incluidas las diferentes consultas orientadas a los mismos bloques de archivos, se leen directamente desde la caché local en lugar de volver a recuperar los archivos de la nube remota.

Google administra automáticamente la capacidad, la retención y la expulsión de la caché. Tus ahorros reales en los costos de salida dependen de tus patrones de consulta, la frecuencia con la que cambian los archivos de origen y la retención de la caché en la región de destino de Google Cloud. Antes de entregar datos almacenados en caché, cada consulta verifica los metadatos y los permisos de acceso con la fuente de almacenamiento remoto para que no leas datos obsoletos ni omitas los permisos revocados.

El almacenamiento en caché multinube está inhabilitado de forma predeterminada. Puedes habilitar o inhabilitar el almacenamiento en caché cuando creas o actualizas un catálogo federado de Lakehouse o una conexión multinube de BigQuery. Para obtener instrucciones de configuración, consulta la guía de configuración de tu proveedor de catálogo compatible o Crea conexiones multinube.

Verifica el uso de la caché y el ahorro de costos de salida

Para verificar las tasas de acierto de caché y medir tus ahorros en los costos de salida, inspecciona los detalles del trabajo en la consola de BigQuery o verifica el campo objectStorageStats (object_storage_stats) en las estadísticas de trabajos de consulta de JobStatistics2 de BigQuery:

  • cloudProvider (cloud_provider): Es el proveedor de servicios en la nube que aloja el almacén de objetos (por ejemplo, AWS o AZURE).
  • cacheBytesRead (cache_bytes_read): Es el total de bytes leídos de la caché local de Google Cloud , lo que evita una lectura remota del almacén de objetos.
  • objectStorageBytesRead (object_storage_bytes_read): Es el total de bytes leídos directamente del almacén de objetos del proveedor de servicios en la nube.

Para obtener instrucciones sobre cómo recuperar estas métricas con la herramienta de línea de comandos de bq, consulta Supervisa el uso de la caché y el ahorro de costos de salida.

Consideraciones sobre la residencia de datos y la jurisdicción

Cuando habilitas el almacenamiento en caché multinube, Lakehouse almacena de forma temporal copias en caché de tus archivos remotos en reposo en la región de Google Cloud en la que se ejecuta la consulta. Antes de habilitar el almacenamiento en caché para los archivos ubicados en otra región geográfica o jurisdicción (por ejemplo, Amazon S3 o Azure Blob Storage en la Unión Europea consultados desde us-east4), verifica que el almacenamiento de copias temporales en caché en la región Google Cloud de destino cumpla con los requisitos de residencia de datos y cumplimiento de tu organización.

Compatibilidad con encriptación y CMEK

Los datos almacenados en caché se encriptan en reposo con la Google-owned and Google-managed encryption keyspredeterminada. Las claves de encriptación administradas por el cliente (CMEK) no son compatibles con el almacenamiento en caché multinube.

Si tu organización aplica la restricción de la política de la organización Restringir servicios que no son de CMEK (constraints/gcp.restrictNonCmekServices), Lakehouse inhabilita automáticamente el almacenamiento en caché para las consultas que acceden a tablas restringidas. Tus consultas se siguen ejecutando, pero leen directamente desde el almacenamiento remoto sin almacenar en caché los bloques de archivos.

Modo de identidad

Lakehouse admite dos modos de identidad para el acceso a los datos multinube:

  • Identidad de servicio (predeterminada): Tanto la actualización de metadatos en segundo plano como las consultas se ejecutan con la cuenta de servicio del catálogo, que se puede configurar con OIDC (recomendado) o con la autenticación basada en secretos.

  • Federación de identidades de usuario: La actualización de metadatos en segundo plano se ejecuta con la cuenta de servicio del catálogo, pero las consultas se ejecutan con la identidad del usuario final y se propagan al catálogo remoto. Esto permite que el catálogo remoto atribuya consultas de Google Cloud a los usuarios finales, lo que permite la aplicación de permisos y la generación de registros de auditoría. La federación de identidades debe configurarse en el catálogo remoto.

¿Qué sigue?