Google presentó en la cumbre Apache Iceberg, el mes pasado, una vista previa de un catálogo REST serverless para Apache Iceberg integrado con BigQuery y amplió esa propuesta en Next ’26 para habilitar interoperabilidad cross‑engine. La compañía afirmó que, gracias a esta integración, las mismas tablas Iceberg podrán ser consultadas y gestionadas por BigQuery y por motores como Spark, Flink y Trino sin necesidad de duplicar o copiar los datos.
La vista previa del catálogo REST serverless permite crear, actualizar y consultar tablas Iceberg compartidas desde distintos motores. Google añadió soporte gestionado para metadatos, mantenimiento automático de tablas, transacciones y replicación de cambios. También incorporó controles de acceso centralizados pensados para aplicar permisos de forma consistente entre los distintos engines que accedan a las tablas compartidas.
Técnicamente, la iniciativa extiende la infraestructura de BigQuery para manejar tablas Iceberg con el objetivo declarado de reducir costes y la complejidad operativa en casos como ingesta en streaming, pipelines de replicación y gobernanza. Google sostiene que al evitar copias y ofrecer un plano de control único se minimizan fricciones que hoy elevan el coste total de propiedad para muchos equipos de datos.
En paralelo, Google elevó al estado generalmente disponible a BigQuery ObjectRefs, una funcionalidad que permite combinar datos estructurados en tablas Iceberg con archivos no estructurados almacenados en Cloud Storage para análisis multimodal y flujos de IA. Mientras tanto, Knowledge Catalog — anteriormente conocido como Dataplex — permanece en vista previa como la capa destinada a gobernanza de metadatos, linaje y controles de acceso.
Hasta ahora, los clientes debían elegir entre almacenar tablas Iceberg en un catálogo REST gestionado por Google o en tablas administradas por BigQuery, lo que creaba limitaciones prácticas: por ejemplo, cargas ETL ejecutadas desde Spark hacia tablas registradas en el catálogo REST no podían escribir a través de BigQuery ni aprovechar sus funciones de gestión de almacenamiento. La vista previa pretende abordar esa restricción para permitir operaciones más integradas entre plataformas.
En términos de mercado, Apache Iceberg se ha consolidado como la opción predominante para lakehouses que necesitan soportar múltiples motores de cómputo. Google presenta su propuesta como una manera de conservar datos en formatos abiertos a la vez que facilita el uso conjunto de herramientas de procesamiento y análisis, tanto en la propia nube como en entornos externos.
Desde el punto de vista de interoperabilidad, Google afirma que la solución facilitará consultas cross‑cloud y cross‑engine, incluyendo acceso entre entornos en AWS, Azure, Databricks y Snowflake. Eso abre la puerta a flujos de trabajo de IA sobre datos multimodales y a arquitecturas en las que el almacenamiento se mantiene abierto mientras distintas capas de computación comparten el mismo catálogo y metadatos.
Voces del sector destacaron los nudos operativos que la iniciativa busca resolver. David Colbert señaló que los equipos sufren «fricción» en tareas como compactación, gestión de metadatos y orquestación, y añadió que «el punto del catálogo es clave» porque los formatos abiertos resuelven la portabilidad del almacenamiento, pero el plano de control determina la opción a largo plazo. Precious Pendo añadió que Google pretende capturar valor en la capa de razonamiento sobre los datos.
La nueva capacidad no elimina la necesidad de evaluar gobernanza y control del plano: las organizaciones deberán sopesar cómo gestionar permisos, linaje y dependencia de plataforma para evitar riesgos de bloqueo a futuro. La vista previa anunciada el mes pasado y ampliada en Next ’26 ofrece una alternativa técnica a la fragmentación, pero su adopción exigirá decisiones de arquitectura y gobierno alineadas con políticas corporativas y requisitos regulatorios.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
