Cómo funciona Lakehouse sin fronteras

La arquitectura técnica de Lakehouse sin fronteras admite la interoperabilidad entre motores centralizando la administración de metadatos y controlando las consultas a través de rutas específicas.

Arquitectura

La creación del Lakehouse de Google Cloud consta de los siguientes componentes técnicos:

  • Almacenamiento: El almacenamiento de Cloud Storage y BigQuery actúa como la capa de almacenamiento, con Apache Iceberg como el formato de tabla abierta recomendado para el almacenamiento interoperable y de alto rendimiento en Cloud Storage. Con Lakehouse sin fronteras, tus datos no necesitan residir en Google Cloud. Si configuras conexiones multinube (vista previa) a catálogos remotos compatibles, puedes mantener tus datos en otros sistemas de almacenamiento en la nube, como Amazon S3, y consultarlos sin migrar archivos ni compilar canalizaciones de ETL.

  • Catálogo: El catálogo de entornos de ejecución de Lakehouse proporciona una única fuente de información para administrar los metadatos. Centraliza el descubrimiento de metadatos en varios motores con diversas opciones de compatibilidad, como el extremo del catálogo de REST de Apache Iceberg. Los registros de tablas en el catálogo registran automáticamente entradas en el Knowledge Catalog de metadatos empresariales.

  • Motor de consultas: BigQuery y los motores de código abierto, incluidos Apache Spark, Apache Flink y Trino, interoperan sin problemas conectándose al catálogo del entorno de ejecución de Lakehouse. Los motores de procesamiento, como Managed Service para Apache Spark, usan Apache Spark de código abierto con optimizaciones de ejecución para garantizar la portabilidad de la carga de trabajo y evitar la dependencia del proveedor.

  • Administración: Knowledge Catalog proporciona políticas centralizadas de seguridad, linaje y administración en todo tu lakehouse.

  • Herramientas de escritura y análisis de datos: Los motores y las herramientas integrados proporcionan múltiples rutas para la transferencia y el análisis de datos, lo que ayuda a garantizar un acceso coherente a los datos tanto para los analistas como para los científicos de datos.

Jerarquía de recursos

El Lakehouse de Google Cloud organiza los datos con una jerarquía que se alinea con los estándares de Apache Iceberg y los conceptos de bases de datos estándar. Esta estructura permite que el catálogo de entorno de ejecución de Lakehouse asigne identidades lógicas a rutas de almacenamiento físicas. Para interactuar con esta jerarquía de recursos y conectar tus motores de consultas al catálogo, debes usar extremos específicos, como se describe en la siguiente lista.

  1. Catálogo de entornos de ejecución de Lakehouse: Es el recurso de servicio regional de nivel superior en Google Cloud que aloja tus metadatos. Para conectar motores de consultas a este servicio y administrar los catálogos subyacentes, debes configurar las aplicaciones cliente con un extremo de catálogo específico, como el extremo de catálogo de REST de Apache Iceberg.
  2. Catálogo: Es un contenedor lógico dentro del servicio de catálogo de tiempo de ejecución. En la estructura de nomenclatura Proyecto/Catálogo/Espacio de nombres/Tabla (P.C.N.T), esto representa la instancia de catálogo específica que consultas.
  3. Espacio de nombres: Es una agrupación lógica de tablas dentro de un catálogo. Para los usuarios que conocen BigQuery, un espacio de nombres es funcionalmente similar a un conjunto de datos.
  4. Tabla: Es la entidad específica que apunta a los datos en Cloud Storage. Los metadatos de la tabla contienen el esquema, la información de partición y un puntero al estado actual de la tabla a través de un archivo metadata.json de Apache Iceberg.

Extremos compatibles

El catálogo del entorno de ejecución de Lakehouse proporciona varios extremos para conectar tus datos en Cloud Storage y BigQuery.

  • Extremo del catálogo de REST de Apache Iceberg: Proporciona una interfaz de REST estándar para una amplia compatibilidad con motores de código abierto, como Apache Spark, Apache Flink y Trino. Esta es la interfaz recomendada para las cargas de trabajo nuevas y ofrece interoperabilidad completa de lectura y escritura.

  • Catálogo personalizado de Apache Iceberg para el extremo de BigQuery: Permite que los motores interoperen directamente con el catálogo de BigQuery. Esta interfaz se usa principalmente para las tablas de Apache Iceberg administradas por BigQuery y las cargas de trabajo existentes que realizan la transición a la arquitectura de Lakehouse.

  • Extremo del catálogo de Apache Hive (versión preliminar): Proporciona compatibilidad para cargas de trabajo de código abierto que dependen de la interfaz del metastore de Apache Hive (HMS). Esto te permite ejecutar cargas de trabajo de Apache Hive o Spark en un servicio de metastore completamente administrado en Google Cloud.

Catálogo de entorno de ejecución de Lakehouse

Dentro de la jerarquía de recursos, el catálogo de entorno de ejecución de Lakehouse funciona como el servicio de metadatos regional de nivel superior en Google Cloud. Actúa como el contenedor raíz que aloja tus instancias de catálogo individuales, centralizando el descubrimiento de metadatos en diferentes motores de búsqueda.

Implementa la API de Apache Iceberg REST Catalog de código abierto para administrar espacios de nombres y tablas, y proporciona extensiones específicamente para la administración de catálogos.

Para obtener más información sobre el servicio de metastore, incluidas las capacidades clave, los motores compatibles, la configuración de extremos y las limitaciones, consulta Acerca del catálogo del entorno de ejecución de Lakehouse.

Catálogo

Un catálogo es un contenedor lógico de metastore respaldado por ubicaciones de almacén de Cloud Storage. En la estructura de nomenclatura Project.Catalog.Namespace.Table (P.C.N.T), el catálogo representa la instancia única del metastore que conecta los metadatos de la tabla abierta con los motores de consultas.

Las características clave de los catálogos incluyen las siguientes:

  • Asociación de almacenamiento: La relación entre un catálogo y su almacenamiento subyacente depende del tipo de catálogo que configures.
  • Replicación regional: La región de un catálogo coincide automáticamente con la región del bucket subyacente.
  • Delegación de acceso: Los administradores pueden habilitar la venta de credenciales en el catálogo para delegar el acceso, lo que permite que se generen automáticamente credenciales de corta duración con un alcance reducido en lugar de otorgar a los usuarios permisos directos para el bucket.

Espacio de nombres

Un espacio de nombres es una agrupación lógica de tablas dentro de un catálogo, que funciona de manera similar a una base de datos, un esquema o un conjunto de datos de BigQuery. Proporciona una estructura para organizar y administrar los controles de acceso a las tablas.

Entre las características clave de los espacios de nombres, se incluyen las siguientes:

  • Regionalidad: Cuando creas un espacio de nombres, este usa automáticamente la misma región que su catálogo principal.
  • Flexibilidad de ubicación: Las opciones para especificar ubicaciones de espacios de nombres personalizados se determinan según el tipo de almacén del catálogo.
  • Limitaciones de anidación: No se admiten espacios de nombres anidados (subespacios de nombres).
  • Límites de seguridad: Puedes otorgar roles de IAM a nivel del espacio de nombres para administrar el acceso a todas las tablas que contiene.

Tablas

Cuando compilas con el Lakehouse de Google Cloud, puedes elegir entre los siguientes tipos de tablas:

Compatible con el catálogo de entorno de ejecución de Lakehouse

Recomendado

  • Tablas de Apache Iceberg: Tablas de Apache Iceberg creadas a partir de motores de código abierto y almacenadas en Cloud Storage. Estos ofrecen compatibilidad y administración abiertas a través del extremo de REST del catálogo del entorno de ejecución de Lakehouse. Para garantizar que no haya dos tablas en la misma ubicación, las rutas de acceso de las tablas personalizadas deben anidarse en la ruta de acceso del espacio de nombres principal, y las ubicaciones de las tablas resultantes reciben automáticamente un sufijo de cadena aleatorio para evitar conflictos.

    Formatos de tabla admitidos

    Se admiten las tablas de Apache Iceberg V2 (GA) y V3 (versión preliminar). No se admiten las tablas de Iceberg V1. Antes de usar tablas de la versión 1 existentes con Lakehouse, debes actualizarlas a una versión compatible. Para obtener más información, consulta Actualiza las tablas de Iceberg V1 a V2.

Compatible con BigQuery

  • Tablas de Apache Iceberg: Tablas de Apache Iceberg creadas y administradas por BigQuery. Los metadatos de estas tablas se almacenan en el catálogo de BigQuery, y los datos de las tablas y los metadatos físicos se almacenan en Cloud Storage.
  • Tablas nativas: Tablas completamente administradas por BigQuery que se pueden conectar al catálogo del entorno de ejecución de Lakehouse para permitirte interoperar con motores de código abierto.
  • Tablas externas: Tablas fuera del catálogo del entorno de ejecución de Lakehouse en las que los datos y los metadatos se administran por sí mismos. Estos admiten el acceso delegado a través de conexiones para los datos almacenados en Cloud Storage, Amazon S3 o Azure Blob Storage.

Para obtener una comparación detallada de estas opciones, consulta Información sobre los tipos y las capacidades de las tablas.

Secuencia de procesamiento de consultas

Cuando envías una consulta a una tabla de Apache Iceberg administrada por Lakehouse, la solicitud sigue una ruta específica para aplicar políticas y recuperar metadatos antes de que se procesen los datos.

  1. Envío: Envías una consulta en SQL a un motor compatible, como Apache Spark, Trino o BigQuery.
  2. Solicitud de metadatos: El motor solicita metadatos de la tabla al catálogo del entorno de ejecución de Lakehouse para identificar la tabla y la ubicación de sus metadatos.
  3. Autorización: Si el endpoint que usas lo admite, el catálogo valida la solicitud en función de Identity and Access Management (IAM) y las políticas de seguridad detalladas.
  4. Respuesta de metadatos: El catálogo devuelve los metadatos. Si la venta de credenciales está habilitada, también proporciona un token de corta duración para ayudar con el acceso seguro al almacenamiento.
  5. Recuperación de datos: El motor usa los metadatos y el token opcional para leer archivos de datos directamente desde Cloud Storage.
  6. Ejecución: El motor procesa los datos y devuelve los resultados.

Prácticas recomendadas

Cuando diseñes y operes un data lakehouse en Google Cloud, ten en cuenta las siguientes prácticas recomendadas:

  • Adopta una arquitectura de medallón: Estructura tu almacén de datos en capas lógicas progresivas (bronce para la transferencia sin procesar, plata para los datos limpios y ajustados, y oro para las agregaciones seleccionadas a nivel empresarial). Usa BigQuery para la capa de consumo de datos de referencia para maximizar el rendimiento y la simultaneidad de las consultas.
  • Usa plantillas de sesión para cargas de trabajo interactivas: Para el análisis exploratorio y la creación de notebooks, usa plantillas de sesión para estandarizar la configuración del entorno en los equipos de desarrollo y reducir la configuración repetitiva.
  • Asigna identificadores de lotes personalizados: Cuando envíes cargas de trabajo por lotes no interactivas de Apache Spark sin servidores, asigna nombres personalizados a los lotes y trabajos. Esto mejora la observabilidad, lo que te ayuda a filtrar y hacer un seguimiento de las ejecuciones de trabajos en Cloud Logging y en la consola de Google Cloud .
  • Habilita el registro de diagnóstico: Para las canalizaciones complejas de ingeniería de datos, habilita los paquetes de diagnóstico y asegúrate de que se conserven los registros del controlador y del ejecutor para facilitar la solución de problemas y la asistencia.

¿Qué sigue?