Acerca del lakehouse multinube

Lakehouse entre nubes para Apache Iceberg 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.

Como parte de Lakehouse, 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.

Casos de uso

Lakehouse en múltiples nubes 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.
  • Las estadísticas unificadas te permiten realizar análisis avanzados con funciones coherentes y optimización de hardware en todos tus datos, independientemente de dónde se encuentren.
  • La IA y el AA en múltiples nubes te permiten aplicar modelos de IA, agentes autónomos y aprendizaje automático directamente a tus datos remotos sin migrarlos.

Cómo funciona Lakehouse en varias nubes

Las consultas de Lakehouse entre nubes consultan datos remotos con el siguiente proceso:

  1. Detección de metadatos: El Lakehouse de Google Cloudse conecta a catálogos remotos de Apache Iceberg REST, como Databricks Unity o AWS Glue. Lakehouse detecta 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 la 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é temporalmente esos segmentos de datos de forma 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 entre nubes.

Catálogos admitidos

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

  • Catálogo de Unity de Databricks: Se admite en Amazon Web Services (AWS) yGoogle Cloud.
  • AWS Glue: Se admite en Amazon Web Services (AWS).

Conceptos básicos

En esta sección, se describen los componentes clave esenciales para usar el Lakehouse en varias nubes.

Catálogos remotos de REST de Apache Iceberg

Esta es la capa de metadatos. Te conectas a catálogos de REST de Apache Iceberg remotos. El lakehouse descubre los datos sin copiar ningún archivo. A través de la federación de tokens de OIDC o las credenciales de OAuth, Lakehouse se autentica de forma segura sin necesidad de claves de acceso de larga duración.

Capa de transporte

Esta es la capa de transporte. Puedes configurar Lakehouse para consultar datos almacenados en proveedores de nube remotos a través de Internet público 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 de red privada y dedicada con Cross-Cloud Interconnect o interconexión de socio.

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.
  • Costos reducidos: 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 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 Google Cloudnube privada virtual (VPC) 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, 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 Google Cloud ILB.
  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, 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 se transfieren a través de la 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 a través de la 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ú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 redes adicional, intercambio de tráfico entre VPCs ni configuración de Directorio de servicios en Google Cloud ni en tu proveedor de servicios en la nube remoto.

Descripción general de la arquitectura

Cuando consultas datos a través de Internet público, Lakehouse se conecta directamente a los extremos remotos de tu catálogo y almacenamiento de objetos 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 a través de 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.

¿Qué sigue?