Conceptos clave

Una arquitectura de Lakehouse sin fronteras te permite unificar el análisis de datos en entornos distribuidos y sistemas de almacenamiento de formato abierto en Google Cloud. Comprender estos conceptos básicos te ayuda a evaluar arquitecturas y configurar catálogos unificados, procesamiento de varios motores y administración en tus cargas de trabajo de Lakehouse.

En lugar de proporcionar una lista exhaustiva de funciones, esta referencia describe la terminología principal que se usa en toda la documentación de Lakehouse.

Conceptos básicos

Los siguientes conceptos forman la base de la arquitectura de Lakehouse de Google Cloud.

Data lakehouse

Un data lakehouse reúne el ahorro de costos y la flexibilidad de un data lake con la administración de datos y el rendimiento de un almacén de datos. Te permite almacenar datos en formatos abiertos en Cloud Storage y usar funciones de BigQuery, como controles de seguridad precisos y consultas rápidas.

Arquitectura de medallón

Un patrón de diseño común en un data lakehouse es la arquitectura de medallón, que organiza los datos de forma lógica en capas progresivas de estructura y calidad:

  • Capa de bronce (sin procesar): Transfiere y almacena datos sin procesar en formatos abiertos, como Apache Iceberg, en Cloud Storage.
  • Capa Silver (limpia): Limpia, filtra y enriquece los datos sin procesar en tablas estandarizadas.
  • Capa oro (seleccionada): Ofrece tablas agregadas a nivel empresarial completamente seleccionadas. En el lakehouse de Google Cloud, BigQuery se suele usar para entregar la capa de oro para el consumo, los informes y el análisis de alto rendimiento.

Interoperabilidad abierta

La interoperabilidad abierta es la capacidad de varios sistemas analíticos y transaccionales, como BigQuery, Apache Spark y Apache Flink, de operar en una sola copia de datos en formatos abiertos, como Apache Iceberg. Esto elimina la necesidad de duplicar los datos y garantiza una vista coherente de los datos en herramientas dispares.

Catálogo de tiempo de ejecución de Lakehouse

El catálogo de tiempo de ejecución de Lakehouse es un servicio de metadatos centralizado y sin servidores que actúa como la fuente única de información para el Lakehouse de Google Cloud. Permite que varios motores, como Apache Spark, Apache Flink y BigQuery, descubran y consulten las mismas tablas de forma simultánea.

Tipos de catálogos

El catálogo de tiempo de ejecución de Lakehouse ofrece diferentes tipos de catálogos para administrar tus metadatos.

Extremo del catálogo de REST de Apache Iceberg

Este es un catálogo basado en el extremo del catálogo de REST de Apache Iceberg. Proporciona interoperabilidad entre los motores de código abierto y BigQuery, y admite funciones como la venta de credenciales y la recuperación ante desastres.

Parámetros de configuración de almacenamiento del catálogo

Cuando creas un extremo de catálogo de REST de Apache Iceberg, puedes elegir entre dos modelos de almacenamiento:

  • Catálogo de varios bucket (recomendado): Te permite asignar un nombre a tu catálogo de forma independiente y configurar una ubicación de almacenamiento predeterminada (default_location) y hasta 128 buckets de Cloud Storage o rutas de acceso secundarias adicionales en restricted_locations. Cuando configures los motores de consultas de cliente (como Spark o Trino), establece la ruta de acceso del almacén en bl://projects/PROJECT_ID/catalogs/CATALOG_ID.
  • Catálogo de un solo bucket: Es una configuración heredada en la que el catálogo está bloqueado en un solo bucket de Cloud Storage y hereda el nombre del bucket. Cuando configures los motores de consulta del cliente, establece la ruta de acceso del almacén en gs://CLOUD_STORAGE_BUCKET_NAME.

Catálogo personalizado de Apache Iceberg para BigQuery

Esta es una integración que usa el catálogo de BigQuery directamente como el servicio de metadatos de respaldo para las tablas administradas de Apache Iceberg.

Extremo del catálogo de Apache Hive

Este extremo 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), lo que te permite ejecutar cargas de trabajo de Apache Hive o Spark en un servicio de almacén de metadatos completamente administrado en Google Cloud.

Tipos de tablas

Lakehouse de Google Cloud admite varios formatos de tabla, según el motor que se use para administrar los datos y el extremo del catálogo que estés usando.

Tablas de Apache Iceberg

Estas son tablas de Apache Iceberg que creas a partir de motores de código abierto y almacenas en Cloud Storage. El catálogo de entorno de ejecución de Lakehouse administra estas tablas y proporciona acceso a ellas a través del extremo del catálogo de REST de Apache Iceberg. Los motores de código abierto tienen acceso de lectura y escritura a estas tablas, mientras que BigQuery tiene acceso de lectura y escritura (versión preliminar). Esta opción es la mejor si quieres que tu flujo de trabajo de ETL se administre con motores de código abierto.

Tablas de BigQuery

Estas tablas se administran con BigQuery.

Tablas de Apache Iceberg

Estas son tablas de Apache Iceberg que creas desde BigQuery y almacenas en Cloud Storage. BigQuery controla todo el diseño y la optimización de los datos. Si bien varios motores pueden leer estas tablas, BigQuery es el único que puede escribir en ellas directamente.

Tablas nativas

BigQuery administra estas tablas y almacena los datos en el almacenamiento de BigQuery. Puedes conectar estas tablas al catálogo de tiempo de ejecución de Lakehouse.

Tablas externas

Las tablas externas residen fuera del catálogo de tiempo de ejecución de Lakehouse. Los datos y metadatos se autoadministran en un catálogo de terceros (como Cloud Storage, S3 o Azure Blob Storage). BigQuery solo puede leer estas tablas.

Funciones de la tabla

Evolución de la tabla

Lakehouse de Google Cloud admite la evolución de tablas de Apache Iceberg, lo que te permite cambiar el esquema o la especificación de partición de una tabla con el tiempo sin reescribir los datos de la tabla ni volver a crearla.

Viaje en el tiempo

El viaje en el tiempo te permite consultar los datos de una tabla tal como existían en un momento específico o un ID de instantánea. Esto es útil para auditar, reproducir experimentos o restablecer datos después de una eliminación accidental.

Almacenamiento de metadatos en caché

El almacenamiento en caché de metadatos es una función que acelera el rendimiento de las consultas para tablas externas. Almacena una copia de los metadatos de la tabla en el almacenamiento de BigQuery, lo que reduce la necesidad de leer archivos de metadatos de Cloud Storage durante la ejecución de la consulta.

Administración de tablas de Lakehouse de Google Cloud

La administración de tablas de Lakehouse de Google Cloud simplifica el mantenimiento de Lakehouse automatizando tareas como la compactación y la recolección de elementos no utilizados para las tablas administradas. Esto garantiza un rendimiento óptimo de las consultas y la eficiencia del almacenamiento.

Conceptos de interoperabilidad

Acceso a datos multinube

El acceso a datos multinube en Lakehouse sin límites te permite conectarte a catálogos externos remotos (como Databricks Unity Catalog, AWS Glue, Snowflake Horizon Catalog, Workday Data Lake o SAP BDC). Sincroniza los metadatos de otros proveedores de servicios en la nube, lo que te permite consultar datos con BigQuery o motores externos de código abierto a través del extremo del catálogo de Apache Iceberg REST, sin migrar los datos.

Conjuntos de datos públicos

Lakehouse sin límites aloja conjuntos de datos públicos de alta calidad que se entregan a través del extremo del catálogo de REST de Apache Iceberg, lo que proporciona acceso de solo lectura para la exploración y las pruebas sin administrar la infraestructura.

Estructura de nombres de P.C.N.T.

La estructura de nombres P.C.N.T. es la convención de cuatro partes que se usa para identificar y consultar tablas de forma única en el catálogo de entornos de ejecución de Lakehouse desde BigQuery. Significa Project.Catalog.Namespace.Table:

  • Proyecto: Es el ID del proyecto de Google Cloud .
  • Catálogo: Es el nombre del catálogo de tiempo de ejecución de Lakehouse.
  • Espacio de nombres: Es la agrupación lógica de tablas (similar a un conjunto de datos).
  • Tabla: Es el nombre de la tabla de datos.

Conceptos de seguridad

Conexiones

Una conexión es un recurso de BigQuery que almacena credenciales para acceder a datos externos. En Lakehouse de Google Cloud, las conexiones delegan el acceso a Cloud Storage permitiendo que la cuenta de servicio de la conexión acceda al bucket de almacenamiento en tu nombre.

Venta de credenciales

La venta de credenciales es un mecanismo de seguridad que ayuda a reforzar el control de acceso cuando se usa el catálogo de entorno de ejecución de Lakehouse. Cuando está habilitado, el servicio genera credenciales de corta duración y alcance reducido diseñadas para otorgar acceso solo a las rutas de acceso de archivos específicas que se requieren para una consulta.

Administración unificada

La administración unificada te permite definir y aplicar políticas de seguridad y administración de datos de forma centralizada a través de la integración en Knowledge Catalog. Cuando registras tablas en el catálogo de tiempo de ejecución de Lakehouse, el sistema registra automáticamente las entradas correspondientes en el catálogo de metadatos empresariales (Knowledge Catalog), lo que habilita el linaje de datos, la búsqueda semántica y la administración centralizada en todos los motores sin mover ni copiar archivos.

Conceptos del motor de consultas

Lakehouse de Google Cloud separa el almacenamiento del procesamiento, lo que permite que varios motores de análisis interactúen con tablas abiertas.

Managed Service para Apache Spark

Managed Service para Apache Spark (antes Dataproc sin servidores) proporciona un entorno de ejecución completamente administrado para procesar formatos de tablas abiertos, como Apache Iceberg. Admite dos modos principales de ejecución:

  • Lotes sin servidores: Están diseñados para canalizaciones de procesamiento de datos automatizadas y no interactivas, y cargas de trabajo de ETL. Este modelo de pago por ejecución elimina la administración de clústeres, quita la contención de recursos entre trabajos y automatiza el mantenimiento de la infraestructura.
  • Sesiones interactivas sin servidores: Están diseñadas para el análisis exploratorio de datos, la ingeniería de datos y la experimentación de ciencia de datos. Las sesiones interactivas potencian los notebooks de Apache Spark de forma interna con Spark Connect o kernels de Spark remotos, lo que proporciona un entorno de escalado automático sin configuración de infraestructura.

Niveles de servicio

Cuando ejecutas cargas de trabajo de Apache Spark en el catálogo de tiempo de ejecución de Lakehouse, puedes seleccionar entre diferentes niveles de servicio:

  • Nivel Estándar: Es el nivel de ejecución predeterminado adecuado para las cargas de trabajo de procesamiento por lotes estándar.
  • Nivel Premium: Proporciona funciones avanzadas, incluida la compatibilidad con sesiones de notebooks interactivas sin servidores y funciones que aceleran el rendimiento, como Lightning Engine.

Plantillas de sesión

Las plantillas de sesión simplifican la configuración de las sesiones interactivas sin servidores. Permiten que los administradores definan y conserven la configuración común del entorno (como las propiedades del catálogo, la configuración de red y las versiones del entorno de ejecución). Esto promueve la coherencia y mejora la productividad de los desarrolladores, ya que minimiza la configuración repetida. Las plantillas de sesión se pueden crear y administrar con la consola deGoogle Cloud , la CLI de gcloud, la API de REST o Terraform.

Conceptos de confiabilidad

Replicación entre regiones

La replicación entre regiones replica los metadatos en varias regiones para garantizar la disponibilidad del catálogo durante las interrupciones regionales.

Conmutación por error

La conmutación por error es el proceso de cambiar entre las regiones principal y secundaria durante una interrupción regional para mantener las operaciones del catálogo.