Acerca del lakehouse multinube

Cross-Cloud Lakehouse 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.

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

  • Conversational Analytics: Compila agentes especializados basados en tus fuentes de datos exactas, incluidas las tablas entre nubes, para analizar datos en las nubes desde una sola conversación.
  • Knowledge Catalog: Usa las funciones de Knowledge Catalog para la creación de perfiles de datos y las estadísticas con fuentes de datos federadas.

Casos de uso

Cross-Cloud Lakehouse admite varios casos de uso clave para acceder a datos en varios proveedores de servicios en la nube:

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

Cómo funciona Cross-Cloud Lakehouse

Cross-Cloud Lakehouse consulta datos remotos con el siguiente proceso:

  1. Detección de metadatos: Google CloudLakehouse de se conecta a catálogos remotos de REST de Apache Iceberg, como Databricks Unity o AWS Glue. 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: Si eliges enrutar el tráfico a través de una interconexión privada (por ejemplo, CCI dedicada o interconexión de socio), se reducen significativamente los costos de transferencia de datos en comparación con la Internet pública y se hace que la latencia sea muy 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 en Google Cloud un almacenamiento especializado. Las consultas posteriores usan la caché local, lo que evita una parte importante de los cargos de salida entre nubes.

Catálogos compatibles

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

  • Catálogo de Unity de Databricks: Compatible con Amazon Web Services (AWS) y Google Cloud.
  • AWS Glue: Compatible con Amazon Web Services (AWS).
  • Snowflake: Compatible con Amazon Web Services (AWS) y Google Cloud.
  • SAP Business Data Cloud (BDC): Compatible con el conector de SAP BDC.

Conceptos básicos

En esta sección, se describen los componentes clave esenciales para usar Cross-Cloud Lakehouse.

Catálogos remotos de REST de Apache Iceberg

Esta es la capa de metadatos. Te conectas a catálogos remotos de REST de Apache Iceberg. 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 requerir claves de acceso de larga duración.

Los catálogos federados de Cross-Cloud Lakehouse sincronizan los metadatos de los catálogos remotos de REST de Apache Iceberg según un intervalo de actualización. La actualización de metadatos en segundo plano de un catálogo puede tardar más cuanto más recursos de espacio de nombres y tabla haya. Si la actualización anterior se excede, se omitirá la actualización actual, pero la siguiente se programará en el intervalo siguiente.

Capa de transporte

Esta es la capa de transporte. Puedes configurar Lakehouse para consultar datos almacenados en proveedores de servicios en la nube remotos a través de la Internet pública o una interconexión privada dedicada. Esta sección no se aplica a las conexiones de SAP Business Data Cloud (BDC).

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 interconexión privada entre nubes con Cross-Cloud Interconnect dedicada o Cross-Cloud Interconnect 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 la Internet pública.
  • Reducción de costos: Posiblemente, cargos de salida más bajos de AWS en comparación con la salida de Internet, en especial cuando se combina con la capacidad de interconexión privada.
  • Rendimiento coherente: 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, configura una ruta de BigQuery a tu bucket de Amazon S3 de AWS a través de tu interconexión privada. Un componente clave en la Google Cloud nube 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.

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

El flujo de trabajo de 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 de the Google Cloud ILB.
  3. El ILB recibe las solicitudes de BigQuery y las distribuye a los backends configurados.
  4. Los backends de ILB son grupos de extremos de red de conectividad híbrida (NEG), cada uno de los cuales 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, a través de 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 viajan 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 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 de la red, el ancho de banda y la latencia 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 redes adicional, intercambio de tráfico entre 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 la Internet pública, Lakehouse se conecta directamente a tu catálogo remoto y a los extremos de almacenamiento de objetos sin requerir privadas Google Cloud o infraestructura de redes de nube remota.

El flujo de trabajo de consulta de 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 con credenciales almacenadas en Secret Manager o 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 de AWS).
  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 encriptación TLS estándar.
  5. El servicio de almacenamiento remoto verifica la solicitud con credenciales temporales y con alcance que proporciona Lakehouse y muestra los bloques de datos solicitados a través de la Internet pública a Google Cloud.

¿Qué sigue?