Cómo funciona Lakehouse

La arquitectura técnica de Lakehouse para Apache Iceberg 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, y Apache Iceberg es el formato de tabla abierta recomendado para el almacenamiento interoperable y de alto rendimiento en Cloud Storage.

  • Catálogo: El catálogo de entornos de ejecución de Lakehouse proporciona una única fuente de verdad 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 las entradas en el catálogo de conocimiento de metadatos comerciales.

  • 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, aprovechan Apache Spark de código abierto con optimizaciones de ejecución para garantizar la portabilidad de la carga de trabajo y evitar la dependencia de un 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 garantiza un acceso coherente a los datos tanto para los científicos como para los analistas 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 del 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 a continuación.

  1. Catálogo del entorno 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 aplicaciones cliente con un extremo de catálogo específico, como el extremo de catálogo de Apache Iceberg REST.
  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: Proporciona compatibilidad para las 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 del entorno de ejecución de Lakehouse funciona como el servicio de metadatos regionales 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.

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 un solo bucket 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: Solo puedes asociar un catálogo con un solo bucket de Cloud Storage.
  • Replicación regional: La región de un catálogo coincide automáticamente con la región del bucket de Cloud Storage 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 y con permisos reducidos 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.

Las características clave de los espacios de nombres incluyen las siguientes:

  • Regionalidad: Cuando creas un espacio de nombres, este usa automáticamente la misma región que su catálogo principal.
  • 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 REST del catálogo de entorno de ejecución de Lakehouse.

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, mientras que 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 habilitar la interoperabilidad 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 autoadministran. 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 la Descripción general de la tabla.

Formatos de tabla admitidos

Solo se admiten las tablas de Apache Iceberg V2; no se admiten las tablas de Iceberg V1. Si tienes tablas de Iceberg V1 existentes, debes actualizarlas a la versión V2 (por ejemplo, ejecutando ALTER TABLE catalog.schema.table SET TBLPROPERTIES ('format-version'='2'); o usando operaciones de motor similares) antes de usarlas con Lakehouse para Apache Iceberg.

Secuencia de procesamiento de consultas

Cuando envías una consulta a la tabla de Lakehouse de Google Cloud, 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 muestra 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 conformes, y oro para las agregaciones seleccionadas a nivel empresarial). Usa BigQuery para la capa de consumo de oro y maximiza 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 facilita el filtrado y el seguimiento de las ejecuciones de trabajos en Cloud Logging y la Google Cloud consola.
  • 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 simplificar la solución de problemas y la capacidad de asistencia.

¿Qué sigue?