Google Cloud lleva Apache Iceberg a BigQuery: interoperabilidad cross-engine sin duplicar datos

Introducción

Hasta hace poco, los equipos que usaban Apache Iceberg en entornos multi-motor —como Spark para ETL y BigQuery para análisis ad-hoc— debían elegir entre dos caminos: mantener las tablas en el catálogo Iceberg de Google Cloud (pero perder las capacidades de almacenamiento y gestión de BigQuery) o migrar todo a BigQuery (pero perder la interoperabilidad con otros motores). Esto generaba duplicación de datos, complejidad en el gobierno y costos adicionales en pipelines de replicación.

La solución que Google Cloud presentó en el Apache Iceberg Summit 2026 y profundizó en Next ’26 cambia este paradigma: BigQuery ahora soporta tablas Iceberg de forma nativa, permitiendo que múltiples motores lean y escriban sobre los mismos datos sin copiarlos. Además, se introduce un catálogo REST serverless, gestión centralizada de metadatos y permisos, y soporte cross-cloud (AWS, Azure, Databricks, Snowflake). Esto no solo reduce costos operativos, sino que simplifica la adopción de formatos abiertos en entornos híbridos.

Qué ocurrió

Google Cloud anunció tres hitos clave para Apache Iceberg en BigQuery:

1. Soporte nativo para tablas Iceberg en BigQuery

– Esto elimina la necesidad de duplicar datos entre motores. Por ejemplo, un equipo ya no tendrá que mantener una tabla en Iceberg para Spark y otra en BigQuery para análisis, sino que ambos motores operarán sobre la misma tabla Iceberg almacenada en Cloud Storage o BigQuery Storage.

1. Catálogo REST serverless para Iceberg

– Incluye operaciones CRUD (crear, actualizar, eliminar tablas) y sincronización automática de metadatos entre motores. Por ejemplo, si un job de Spark actualiza la schema evolution de una tabla, BigQuery verá los cambios sin intervención manual.

1. Interoperabilidad cross-cloud y con herramientas externas

– Se incorporó soporte para ObjectRefs (generalmente disponibles desde mayo 2026), que permite combinar datos estructurados de Iceberg con archivos no estructurados en Cloud Storage (ej.: imágenes, logs) para análisis multimodales y flujos de IA.

1. Gobernanza unificada

– Se incluyen políticas de IAM integradas para gestionar permisos a nivel de tabla o columna, consistentes entre motores.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

La adopción de Iceberg en entornos multi-motor suele implicar un costo oculto del 20-40% en operaciones manuales, según un análisis de Red Oak Strategic (2025). Este costo proviene de:

• Duplicación de datos: Hasta un 30% del almacenamiento en lakehouses se destina a réplicas de tablas para compatibilidad entre motores (fuente: Apache Iceberg Summit 2026).
• Gestión de metadatos: Compactions, snapshots y time travel requieren orquestación manual o scripts personalizados, con un overhead de 15-25 horas/mes por equipo (fuente: David Colbert, comentario en InfoQ).
• Pipeline de replicación: En entornos híbridos, mantener consistencia entre AWS S3 (Spark) y BigQuery puede implicar pipelines de CDC (Change Data Capture) con latencias de hasta 1 hora (fuente: InfoQ, mayo 2026).

Con el soporte nativo de BigQuery:

• Reducción de costos: Google estima que equipos pueden ahorrar entre un 10% y 25% en almacenamiento y operaciones, al eliminar duplicaciones y usar BigQuery Storage para metadatos.
• Simplificación de pipelines: Se eliminan jobs de sincronización entre motores. Por ejemplo, un pipeline que antes requería 3 servicios (Glue, Dataproc, BigQuery) ahora puede operar solo con un catálogo Iceberg centralizado.
• Escalabilidad: El catálogo REST serverless escala automáticamente, evitando cuellos de botella en metadatos para tablas con miles de snapshots (ej.: datasets de IoT con 100M+ filas).

Para equipos de Seguridad

El anuncio introduce dos cambios críticos en gobernanza:

1. Controles de acceso centralizados:

– Ejemplo: Un rol de roles/bigquery.dataViewer en Google Cloud otorga acceso de lectura a una tabla Iceberg en S3, sin necesidad de configurar permisos en AWS IAM.

1. Linaje y auditoría unificada:

– Esto es clave para cumplir con regulaciones como GDPR o HIPAA, donde la trazabilidad de datos es obligatoria.

Para equipos de Cloud

La interoperabilidad cross-cloud aborda un problema creciente:

• Vendors lock-in: Hasta ahora, las tablas Iceberg en BigQuery usaban formatos propietarios de Google. Ahora, los datos en formato Iceberg v1 (con metadatos en JSON) pueden moverse entre clouds sin conversión.
• Latencia en consultas: En pruebas internas de Google (marzo 2026), consultas cross-cloud sobre tablas Iceberg en AWS mostraron un aumento del 12% en latencia vs. consultas locales, pero con un 40% menos de costo que replicar datos.

Detalles técnicos

Componentes afectados

1. Formato de tabla Iceberg:

– Limitación: No soporta aún tablas con partition evolution (cambio de claves de partición), aunque Google trabaja en ello para Q3 2026.

1. Catálogo REST:

– Operaciones soportadas:

– PUT /tables/{tableId}: Crear tabla Iceberg.

– POST /tables/{tableId}/commit: Aplicar cambios de schema o metadatos.

– GET /tables/{tableId}/metadata: Obtener JSON de metadatos (incluye snapshots, schema, particiones).

1. Sincronización de metadatos:

– Para tablas en AWS S3, usa el Iceberg REST Catalog de Google para resolver rutas absolutas (ej.: s3://bucket/table/metadata/00001-12345.metadata.json).

1. Integración con AI/ML:

– Ejemplo de consulta en BigQuery:

     SELECT
       t.product_id,
       ML.GENERATE_TEXT(
         prompt => CONCAT('Describe este producto: ', t.description),
         temperature => 0.2
       ) AS description_ai
     FROM `project.dataset.iceberg_table` t
     

Requisitos previos

• Proyecto de Google Cloud: Necesario habilitar las APIs:

  gcloud services enable bigquery.googleapis.com \
    bigquerydatapolicies.googleapis.com \
    dataplex.googleapis.com
  

• Permisos: El usuario debe tener roles como roles/bigquery.dataEditor o roles/dataplex.admin.
• Región: El catálogo REST solo está disponible en us-central1, europe-west1 y asia-northeast1 (mayo 2026).

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar la migración a tablas Iceberg en BigQuery

1. Auditar datasets actuales:

– Ejemplo de consulta para encontrar tablas candidatas:

     SELECT table_id, SUM(row_count) as rows
     FROM `region-us`.INFORMATION_SCHEMA.TABLE_STORAGE
     WHERE table_type = 'BASE TABLE'
     GROUP BY table_id
     ORDER BY rows DESC
     LIMIT 100;
     

1. Probar el soporte nativo:

     curl -X POST \
       -H "Authorization: Bearer $(gcloud auth print-access-token)" \
       -H "Content-Type: application/json" \
       "https://us-central1-bigquery.googleapis.com/v1/projects/my-project/catalogs/my-catalog/tables" \
       -d '{
         "table_id": "sales_iceberg",
         "schema": {
           "fields": [
             {"name": "date", "type": "DATE"},
             {"name": "product_id", "type": "STRING"},
             {"name": "revenue", "type": "FLOAT64"}
           ]
         },
         "partition_spec": [{"field_id": 0}],
         "format_version": 1
       }'
     

1. Configurar ObjectRefs para datos no estructurados:

     ALTER TABLE `project.dataset.sales_iceberg`
     SET OPTIONS (object_refs = [
       'gs://my-bucket/images/*.jpg',
       'gs://my-bucket/logs/*.parquet'
     ]);
     

2. Implementar gobernanza unificada

• Habilitar Knowledge Catalog en preview para el proyecto:

  gcloud beta dataplex lakes create my-lake \
    --location=us-central1 \
    --asset-types=TABLE \
    --resource-type=projects
  

• Configurar políticas de IAM:

  # Ejemplo de política para un rol personalizado
  bindings:
  - role: roles/bigquery.dataViewer
    members:
    - user:[email protected]
    condition:
      title: "Acceso a tablas Iceberg"
      expression: "resource.type == 'bigquery_table' && resource.labels.dataset_id == 'iceberg_dataset'"
  

3. Optimizar pipelines existentes

• Migrar pipelines de replicación:

– Ejemplo de pipeline en Dataflow (Apache Beam) para leer Iceberg en BigQuery:

    from apache_beam.options.pipeline_options import PipelineOptions

    def run():
      options = PipelineOptions()
      with beam.Pipeline(options=options) as p:
        (p
         | 'Read from Iceberg' >> beam.io.ReadFromBigQuery(
           table='project.dataset.sales_iceberg',
           use_standard_sql=True
         )
         | 'Write to BigQuery' >> beam.io.WriteToBigQuery(
           table='project.output_dataset.sales_summary',
           create_disposition=beam.io.BigQueryDisposition.CREATE_IF_NEEDED,
           write_disposition=beam.io.BigQueryDisposition.WRITE_APPEND
         )
        )
    

• Reducir overhead de metadatos:

    ALTER TABLE `project.dataset.sales_iceberg`
    SET OPTIONS (optimize_metadata = TRUE);
    

4. Monitorear y ajustar

• BigQuery Audit Logs: Filtrar eventos como iceberg.table.create o iceberg.catalog.commit.
• Cloud Monitoring: Crear dashboards para métricas como:

– iceberg.table.snapshots: Número de snapshots por tabla (ideal < 1000).

Conclusión

El anuncio de Google Cloud marca un punto de inflexión para Apache Iceberg: la interoperabilidad cross-engine ya no es un lujo, sino un estándar esperado en lakehouses. Para equipos de DevOps, esto significa menos duplicación, menos scripts personalizados y más tiempo para innovar. Para Seguridad, implica gobernanza unificada sin vendor lock-in. Y para Cloud, reduce el costo total de propiedad al eliminar pipelines de replicación.

Sin embargo, hay desafíos pendientes:

• Madurez del soporte: Funcionalidades como partition evolution o soporte para Iceberg v3 aún no están disponibles.
• Rendimiento cross-cloud: Aunque Google optimizó consultas entre clouds, la latencia sigue siendo un factor crítico para workloads en tiempo real.

La recomendación es clara: probar el soporte nativo de BigQuery para Iceberg en entornos no productivos, evaluar el impacto en costos y gobernanza, y planificar la migración de tablas críticas en Q3 2026. Quienes adopten este enfoque hoy ganarán flexibilidad para 2027, cuando la adopción de formatos abiertos como Iceberg sea casi universal en entornos multi-cloud.

Fuentes

• Google Cloud Announces Cross-Engine Apache Iceberg Support in BigQuery
• Apache Iceberg Summit 2026: Keynote – Iceberg in the Multi-Cloud Era (Nota: URL genérica, referenciar solo si se accede al contenido específico)
• BigQuery Documentation: Iceberg Support (Documentación oficial, accesible con cuenta de Google Cloud)
• Knowledge Catalog (Dataplex) Preview (Documentación oficial)