Cómo funciona Lakehouse sin fronteras

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

Arquitectura

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

  • Almacenamiento: Cloud Storage y el almacenamiento de BigQuery funcionan como la capa de almacenamiento, con Apache Iceberg como el formato de tabla abierta recomendado para el almacenamiento interoperable de alto rendimiento en Cloud Storage. Con Lakehouse sin fronteras, tus datos no necesitan residir en Google Cloud. Si configuras conexiones multinube con 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 tiempo de ejecución de Lakehouse proporciona una fuente única de información para administrar metadatos. Centraliza el descubrimiento de metadatos en varios motores con varias 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 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 de tiempo 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 ayudar a garantizar la portabilidad de las cargas 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 varias rutas de acceso para la ingesta y el análisis de datos, lo que ayuda a garantizar un acceso coherente a los datos para los científicos de datos y analistas.

Jerarquía de recursos

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 tiempo de ejecución de Lakehouse asigne identidades lógicas a rutas de acceso de almacenamiento físico. Para interactuar con esta jerarquía de recursos y conectar tus motores de consulta al catálogo, usa extremos específicos, como se describe en la siguiente lista.

  1. Catálogo de tiempo 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 consulta a este servicio y administrar los catálogos subyacentes, configura las aplicaciones cliente con un extremo de catálogo específico, como el extremo del 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 nombres Proyecto/Catálogo/Espacio de nombres/Tabla (P.C.N.T), esto representa la instancia de catálogo específica que estás consultando.
  3. Espacio de nombres: Es una agrupación lógica de tablas dentro de un catálogo. Para los usuarios familiarizados con 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 de tiempo 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 interactúen 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 se transfieren a la arquitectura de Lakehouse.

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

Catálogo de tiempo de ejecución de Lakehouse

Dentro de la jerarquía de recursos, el catálogo de tiempo 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, lo que centraliza el descubrimiento de metadatos en motores de búsqueda dispares.

Implementa la API de catálogo de REST de Apache Iceberg 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 almacén de metadatos, incluidas las funciones clave, los motores compatibles, la configuración de extremos y las limitaciones, consulta Acerca del catálogo de Lakehouse en el entorno de ejecución.

Catálogo

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

Estas son algunas de las características clave de los catálogos:

  • 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 de 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 de las tablas.

Estas son algunas de las características clave de los espacios de nombres:

  • Regionalidad: Cuando creas un espacio de nombres, este usa automáticamente la misma región que su catálogo superior.
  • Flexibilidad de ubicación: Las opciones para especificar ubicaciones de espacios de nombres personalizados están determinadas por el tipo de almacén del catálogo.
  • Limitaciones de anidamiento: No se admiten los 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 Lakehouse de Google Cloud, puedes elegir entre los siguientes tipos de tablas:

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

Recomendado

  • Tablas de Apache Iceberg: Son tablas de Apache Iceberg creadas a partir de motores de código abierto y almacenadas en Cloud Storage. Estas ofrecen compatibilidad y administración abiertas a través del extremo de REST del catálogo de tiempo de ejecución de Lakehouse. Para garantizar que no haya dos tablas que ocupen la misma ubicación, las rutas de acceso de las tablas personalizadas deben estar anidadas en la ruta de acceso del espacio de nombres superior, 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 (DG) y V3 (versión preliminar). Las tablas de Iceberg V1 no son compatibles. Antes de usar tablas de V1 existentes con Lakehouse, debes actualizarlas a una versión compatible. Para obtener más información, consulta Actualiza las tablas de Iceberg de la versión 1 a la versión 2.

Compatible con BigQuery

  • Tablas de Apache Iceberg: Son 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 la tabla y los metadatos físicos se almacenan en Cloud Storage.
  • Tablas nativas: Son tablas completamente administradas por BigQuery que se pueden conectar al catálogo de tiempo de ejecución de Lakehouse para que puedas interoperar con motores de código abierto.
  • Tablas externas: Son tablas fuera del catálogo de tiempo de ejecución de Lakehouse en las que los datos y los metadatos se administran de forma automática. Estas 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 de tablas y sus capacidades.

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 de tiempo de ejecución de Lakehouse para identificar la tabla y la ubicación de sus metadatos.
  3. Autorización: Si el extremo que usas lo admite, el catálogo valida la solicitud con 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 conformados, y oro para las agregaciones seleccionadas a nivel empresarial). Usa BigQuery para la capa de consumo de oro para maximizar el rendimiento y la simultaneidad de las consultas.
  • Usa plantillas de sesión para cargas de trabajo interactivas: En el caso de los análisis exploratorios y la creación de notebooks, usa plantillas de sesión para estandarizar las configuraciones de 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 de Apache Spark sin servidores no interactivas, asigna nombres de lotes y trabajos personalizados. Esto mejora la observabilidad, lo que te ayuda a filtrar y hacer un seguimiento de las ejecuciones de trabajos en Cloud Logging y la consola de Google Cloud .
  • Habilita el registro de diagnóstico: Para las canalizaciones de ingeniería de datos complejas, habilita los paquetes de diagnóstico y asegúrate de que se conserven los registros del controlador y del ejecutor para ayudar con la solución de problemas y la compatibilidad.

¿Qué sigue?