Acerca del acceso a los datos en distintas nubes

La función de acceso a los 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 con Cross‑Cloud Interconnect.

Como parte de Lakehouse sin fronteras, esta capacidad te permite realizar análisis unificados y aplicar IA en tus conjuntos de datos distribuidos con BigQuery, entornos independientes de Apache Spark o Managed Service para Apache Spark.

Además de las consultas analíticas, puedes usar tus datos federados para obtener estadísticas y gobernanza basadas en IA:

  • Conversational Analytics: Crea agentes especializados fundamentados en tus fuentes de datos exactas, incluidas las tablas multinube, para analizar datos en diferentes nubes desde una sola conversación.
  • Knowledge Catalog: Usa las funciones de Knowledge Catalog para crear perfiles de datos y obtener estadísticas con fuentes de datos federadas.

Casos de uso

Lakehouse admite varios casos de uso clave para acceder a los datos en múltiples proveedores de servicios en la nube:

  • La reducción del movimiento de datos te permite consultar directamente los datos almacenados en otros entornos de nube, lo que simplifica el acceso a los datos y el procesamiento.
  • Unified analytics te permite realizar análisis avanzados con funciones coherentes y optimización de hardware en todos tus datos, independientemente de dónde residan.
  • IA y AA sin fronteras te permite aplicar modelos de IA, agentes autónomos y aprendizaje automático directamente a tus datos remotos sin migrarlos.

Cómo funciona el acceso a los datos multinube

Las consultas de Lakehouse acceden a los datos remotos con el siguiente proceso:

  1. Descubrimiento de metadatos: Google Cloud's Lakehouse se conecta a catálogos REST de Apache Iceberg remotos, como Databricks Unity o AWS Glue. El lakehouse descubre los datos sin copiar ningún archivo. Según el proveedor del catálogo remoto, Lakehouse se autentica de forma segura a través de Secret Manager o la federación de tokens de OpenID Connect con Google como proveedor de identidad (federación de tokens de OIDC).
  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 Internet pública y hace que la latencia sea altamente predecible.
  3. Ejecución optimizada: A medida que las consultas leen datos de nubes remotas, Lakehouse almacena en caché de forma temporal esos segmentos de datos de manera local dentro de Google Cloud en un almacenamiento especializado. Las consultas posteriores usan la caché local, lo que evita una parte significativa de los cargos de salida multinube.

Catálogos admitidos

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

Conceptos básicos

En esta sección, se describen los componentes clave esenciales para usar la función de acceso a datos entre nubes.

Capa de metadatos

La capa de metadatos se conecta a extremos remotos del catálogo de REST de Apache Iceberg para sincronizar los metadatos de los recursos de Iceberg (espacio de nombres, tabla) según un intervalo de actualización. Lakehouse se autentica de forma segura con las credenciales de OAuth almacenadas en Secret Manager o la federación de tokens de OIDC.

Capa de transporte

La capa de transporte permite que BigQuery y los motores de código abierto consulten los datos con los metadatos sincronizados de la capa de metadatos. En el caso de ciertos tipos de catálogos remotos, Lakehouse admite la consulta de datos a través de 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 de Amazon Web Services (AWS) a través de una conexión privada de Cross-Cloud Interconnect con Dedicated Cross-Cloud Interconnect o Partner Cross-Cloud Interconnect.

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, lo que evita el uso de Internet público.
  • Reducción de costos: Es posible que los cargos de salida de AWS sean más bajos en comparación con los de salida de Internet, en especial cuando se combinan con tu capacidad de interconexión privada.
  • Rendimiento constante: Latencia y ancho de banda de la red más predecibles en comparación con la Internet pública

Descripción general de la arquitectura

Para habilitar las consultas privadas, debes configurar una ruta de acceso desde BigQuery hasta tu bucket de Amazon S3 de AWS a través de tu interconexión privada. Un componente clave de la nube privada virtual (VPC) Google Cloudes 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, que se aprovisionan con AWS PrivateLink.

Usar un ILB con varias interfaces de red elásticas (ENI) como backends es fundamental para el balanceo de cargas, la escalabilidad y la alta disponibilidad. Esto se aplica tanto si usas la CCI dedicada como 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 de Directorio de servicios.
  2. Directorio de servicios resuelve el nombre del servicio en la dirección IP interna del ILB Google Cloud .
  3. El ILB recibe las solicitudes de BigQuery y las distribuye a los servidores de backend configurados.
  4. Los backends del ILB son grupos de extremos de red (NEG) de conectividad híbrida, y cada uno apunta a la dirección IP privada de una ENI en tu VPC de AWS.
  5. El tráfico fluye desde el ILB, a través de los NEG, por la interconexión privada, hasta las ENI de AWS.
  6. Las ENI de AWS, que forman parte de un extremo de interfaz de VPC de Amazon S3 (AWS PrivateLink), proporcionan acceso privado al servicio de Amazon S3.

Internet pública (sin CCI)

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

Cuando consultes datos a través de 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ándares en Internet pública.
  • Costos de salida: La transferencia de datos genera cargos de salida de Internet estándar de tu proveedor de servicios en la nube remoto (por ejemplo, AWS), 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 Internet públicos, 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 redes adicional, interconexión de VPC ni configuración de Directorio de servicios en Google Cloud o tu proveedor de servicios en la nube remoto.

Descripción general de la arquitectura

Cuando consultas datos a través de Internet pública, Lakehouse se conecta directamente a tus extremos remotos de almacenamiento de objetos y catálogo sin necesidad de infraestructura de redes privadas Google Cloud o remotas en la nube.

El flujo de trabajo de la búsqueda en Internet pública sigue este proceso:

  1. BigQuery inicia una consulta en una tabla federada definida en tu catálogo de Lakehouse.
  2. Lakehouse se autentica de forma segura con tu catálogo remoto de Apache Iceberg usando las 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 Internet pública para identificar los archivos de datos subyacentes pertinentes (por ejemplo, en AWS Amazon S3).
  4. Las solicitudes de acceso a los datos de los objetos subyacentes se envían directamente desdeGoogle Cloud a través de 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 vende Lakehouse, y devuelve los bloques de datos solicitados a través de Internet pública a Google Cloud.

Almacenamiento en caché inteligente

Cuando consultas datos remotos de la nube, Lakehouse almacena automáticamente en caché los bloques de datos recuperados de forma local dentro de Google Cloud. El almacenamiento en caché se habilita automáticamente para todas las consultas entre nubes, lo que ayuda a minimizar las tarifas de salida de los proveedores de servicios en la nube remotos. Las consultas posteriores que tienen como objetivo los datos almacenados en caché se leen directamente desde el almacenamiento local de Google Cloud en lugar de volver a recuperar los datos en las nubes.

Ahorro de costos de salida

En la ejecución inicial de la consulta, Lakehouse recupera los bloques de datos necesarios del proveedor de nube remoto y completa la caché local. Las consultas posteriores que se dirigen a los mismos bloques de datos se leen directamente desde la caché local deGoogle Cloud en lugar de volver a recuperar los datos en las nubes.

Para las cargas de trabajo con patrones de consultas repetidos sobre el mismo conjunto de datos, el almacenamiento en caché reduce las tarifas de salida multinube, ya que atiende las solicitudes de datos desde el almacenamiento local. Los ahorros reales en los costos de salida dependen de factores como los patrones de acceso a las consultas, las tasas de modificación de datos y la retención de caché en la región de Google Clouddestino.

Cómo verificar el uso de la caché y el ahorro de costos de salida en las estadísticas de trabajos

Para verificar las tasas de acierto de caché y los ahorros en los costos de salida de una consulta, inspecciona las estadísticas de la consulta en la consola o la API de BigQuery (JobStatistics2). Debido a que una consulta puede hacer referencia a datos de varios proveedores, las estadísticas del trabajo proporcionan un campo object_storage_stats (objectStorageStats) repetido con una entrada para cada proveedor de servicios en la nube al que se accedió durante la ejecución.

Cada entrada de object_storage_stats informa las siguientes métricas:

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

Consideraciones sobre la residencia de datos y la jurisdicción

Cuando se crea un catálogo federado o una conexión en una región de Google Cloud , se almacenan datos en reposo en caché de forma local dentro de esa región de destino.

Si tus datos remotos en la nube residen en una región geográfica o jurisdicción diferente (por ejemplo, AWS Amazon S3 en la Unión Europea junto con el procesamiento de BigQuery en us-east4), las consultas entre nubes almacenan copias en caché de los datos remotos en reposo en la región deGoogle Cloud de destino. El usuario o administrador que cree la conexión o el catálogo debe asegurarse de que el almacenamiento en caché entre jurisdicciones cumpla con los requisitos de residencia de datos, soberanía y cumplimiento de su organización.

Compatibilidad con la encriptación y las CMEK

Las claves de encriptación administradas por el cliente (CMEK) no son compatibles con el almacenamiento en caché de Lakehouse. Todos los bloques de datos almacenados en caché se encriptan en reposo conGoogle-owned and Google-managed encryption keyspredeterminado.

Si tu organización aplica la restricción de política de la organización Restrict Non-CMEK Services (constraints/gcp.restrictNonCmekServices), Lakehouse inhabilita automáticamente el almacenamiento en caché para las consultas que acceden a tablas restringidas. Las consultas aún se ejecutan correctamente, pero no almacenan en caché los bloques de datos ni se benefician de los ahorros relacionados con la salida de la caché.

¿Qué sigue?