Iceberg en Arquitecturas Multi-Cloud y Data Mesh

El patrón Open Lakehouse

El Open Lakehouse combina lo mejor de data lake y data warehouse con Iceberg como la capa de almacenamiento unificada:

┌─────────────────────────────────────────────────────────────┐
│                    TU ALMACENAMIENTO                        │
│              S3 / ADLS / GCS (Iceberg Tables)               │
├──────────┬──────────────┬──────────────────────────────────┤
│Snowflake │    Spark     │   Flink   │ Trino │  DuckDB      │
│(SQL + ML)│ (ETL grande) │(Streaming)│(Ad-hoc│(Local dev)   │
└──────────┴──────────────┴──────────────────────────────────┘

Los datos viven UNA SOLA VEZ en tu almacenamiento. Cada motor lee y escribe en el mismo formato.

Patrón: Snowflake como hub de cómputo

Spark procesa datos crudos → escribe Iceberg en S3 → Snowflake los analiza sin copiarlos:

# En Spark (PySpark)
df = spark.read.parquet("s3://raw-data/")
df_transformed = transform(df)

# Escribir como Iceberg en S3
df_transformed.writeTo("glue_catalog.mi_bd.ventas_procesadas") \
    .option("write.target-file-size-bytes", "134217728") \
    .createOrReplace()

-- En Snowflake (sin copiar datos)
SELECT fecha, region, SUM(monto)
FROM mi_glue_db.mi_bd.ventas_procesadas
WHERE fecha >= '2026-01-01'
GROUP BY 1, 2;

Patrón: Data Mesh con Iceberg

En un Data Mesh, cada dominio publica sus datos como productos de datos en su propio almacenamiento:

-- Equipo de Marketing publica su tabla Iceberg como producto de datos
CREATE ICEBERG TABLE marketing.public.segmentos_clientes (
    cliente_id NUMBER,
    segmento VARCHAR,
    ltv_estimado FLOAT,
    fecha_calculo DATE
)
CATALOG = 'SNOWFLAKE'
EXTERNAL_VOLUME = 'vol_marketing_s3'
BASE_LOCATION = 'productos-datos/segmentos/';

-- Equipo de Ventas (otra cuenta Snowflake) puede leerlo
-- sin que Marketing pierda control del almacenamiento
CREATE EXTERNAL VOLUME vol_marketing  -- apunta al S3 de Marketing
  ...;
CREATE ICEBERG TABLE segmentos_externos
  EXTERNAL_VOLUME = vol_marketing
  CATALOG = 'polaris_marketing'
  CATALOG_TABLE_NAME = 'segmentos_clientes';

Compartición Cross-Cloud con Iceberg

Iceberg permite compartir datos entre nubes (AWS ↔ Azure) sin replicarlos:

-- Empresa en Azure quiere que su partner en AWS acceda a datos
-- 1. Empresa Azure crea tabla Iceberg en ADLS
-- 2. Empresa AWS crea External Volume apuntando al ADLS
-- 3. Solo se paga egress de red, no duplicación de storage

-- En la cuenta AWS de Snowflake:
CREATE EXTERNAL VOLUME vol_partner_adls
  STORAGE_LOCATIONS = (
    (
      NAME = 'azure-westeurope'
      STORAGE_PROVIDER = 'AZURE'
      STORAGE_BASE_URL = 'azure://partner-storage.blob.core.windows.net/shared/'
      AZURE_TENANT_ID = 'partner-tenant-id'
    )
  );

Snowpark + Iceberg: Pipeline completo

from snowflake.snowpark import Session

session = Session.builder.getOrCreate()

# Leer tabla Iceberg externa (Glue)
df = session.table("mi_glue_db.analytics.eventos_web")

# Transformar con Snowpark
df_agregado = df \
    .filter(df["fecha"] >= "2026-01-01") \
    .group_by("usuario_id", "fecha") \
    .agg({"eventos": "count", "revenue": "sum"}) \
    .rename({"COUNT(eventos)": "num_eventos", "SUM(revenue)": "revenue_dia"})

# Escribir resultado como nueva tabla Iceberg en Snowflake
df_agregado.write \
    .mode("overwrite") \
    .save_as_table("analytics.iceberg.metricas_diarias")
    # Esta tabla se escribe en S3 via External Volume

Conclusión: Por qué Iceberg importa estratégicamente

1. Vendor independence: Tus datos no están atrapados en el formato propietario de ningún proveedor
2. Cost optimization: Paga el almacenamiento de tu cloud, no el markup de Snowflake
3. Multi-engine flexibility: El mejor motor para cada trabajo (Spark para ETL masivo, Snowflake para SQL interactivo)
4. Future-proof: Iceberg es el estándar ganador del open table format

Snowflake adoptó Iceberg porque entendió que el futuro es abierto. Posicionarse con este mensaje en LATAM es estratégico.