Durante años, los procesos de integración de datos han seguido un patrón bastante sencillo. Herramientas de extracción, replicación o ETL como AWS Glue, Fivetran, Informatica, Qlik, SNP Glue o Azure Data Factory generaban ficheros en formatos abiertos —principalmente Parquet— que posteriormente eran consumidos por plataformas analíticas como Snowflake, Databricks, Fabric o Spark.
Sin embargo, estamos asistiendo a un cambio de paradigma. Cada vez más fabricantes están evolucionando sus productos para que el resultado final de los procesos de integración no sea únicamente un conjunto de ficheros Parquet, sino directamente una tabla Apache Iceberg.
Y aunque a primera vista pueda parecer un cambio menor, la realidad es que supone una transformación profunda en la forma de construir arquitecturas de datos abiertas, interoperables y preparadas para IA.
El modelo tradicional: ETL → Parquet → Plataforma Analítica
Durante años la arquitectura predominante ha sido:
SAP / ERP / CRM │ ▼ETL / Replicación │ ▼ Parquet Files │ ▼ Data Lake │ ▼Snowflake / Fabric / Databricks
Este enfoque sigue siendo válido y continúa siendo el patrón predominante para muchos escenarios.
Por ejemplo, cuando una herramienta como SNP Glue o AWS Glue deposita ficheros en Amazon S3, Snowflake normalmente accede a ellos mediante Storage Integrations, utilizando stages, COPY INTO o Snowpipe para cargar la información. Un Storage Integration no deja de ser la capa que permite autenticarse contra S3, Azure Storage o Google Cloud Storage y acceder a los ficheros almacenados allí.
La principal ventaja de este modelo es su simplicidad.
La principal limitación es que los motores analíticos trabajan sobre ficheros, no sobre tablas abiertas compartidas.
El siguiente paso: ETL → Apache Iceberg
La aparición de Apache Iceberg cambia completamente la conversación.
Ahora la arquitectura evoluciona hacia algo parecido a:
SAP / ERP / CRM │ ▼ETL / Replicación │ ▼ Apache Iceberg │ ▼ AWS S3 / Azure Storage / Google Storage │ ▼SnowflakeFabricDatabricksSparkTrinoFlink
La diferencia fundamental es que ya no persistimos únicamente ficheros físicos, sino también metadatos transaccionales que convierten esos ficheros en una tabla abierta gobernada.
Esto permite que distintos motores accedan simultáneamente a la misma información sin necesidad de mover los datos. Precisamente este concepto aparece repetidamente en la estrategia de interoperabilidad de Snowflake, donde Apache Iceberg se posiciona como el mecanismo para acceder a datos «in place» desde múltiples motores. ¿Será la base del Open Data Hub?
Además, Snowflake está reforzando esta visión mediante Horizon Catalog, Open Catalog y soporte creciente para Iceberg como elemento central de interoperabilidad.
¿Por qué las herramientas ETL están empezando a generar Iceberg?
La respuesta es sencilla:
Las organizaciones cada vez utilizan más de una plataforma de datos.
Hace apenas unos años era habitual elegir una única plataforma analítica.
Hoy encontramos situaciones donde conviven:
- Snowflake para Data Warehouse.
- Fabric para BI y agentes.
- Databricks para Data Science.
- Spark para procesamiento distribuido.
- Trino para virtualización.
Mantener múltiples copias de los mismos datos para cada motor introduce costes, complejidad y problemas de gobierno.
Apache Iceberg resuelve este problema permitiendo que todos los motores compartan una única copia física y un único catálogo lógico.
Beneficios de persistir los datos como Apache Iceberg
- Interoperabilidad real
La misma tabla puede ser consumida por Snowflake, Fabric, Databricks, Spark o Trino sin transformaciones adicionales. - Reducción de copias
Se minimiza la proliferación de datasets duplicados en distintas plataformas.
Una tabla, un catálogo, múltiples motores - Independencia tecnológica
La organización evita el lock-in sobre una plataforma concreta, por lo que si mañana se decide incorporar un nuevo motor analítico, los datos ya están preparados para ello. - Mejor gobierno del dato
La combinación de Iceberg con catálogos abiertos como Apache Polaris permite centralizar políticas y metadatos. - Mejor alineamiento con IA y Agentes
Los agentes necesitan contexto, metadatos y acceso consistente a la información.
¿Tiene desventajas?
Sí, y es importante entenderlas
- Mayor complejidad operacional
Gestionar una tabla Iceberg es más complejo que gestionar simples ficheros Parquet.
Ahora aparecen conceptos como:
– Snapshots
– Manifest Files
– Metadata Files
– Catálogos
– Compaction - Más componentes a gobernar
Además del almacenamiento, es necesario gestionar:
– Iceberg Catalog
– Permisos
– Políticas
– Evolución de esquemas - No todas las herramientas ofrecen un soporte maduro
Aunque la adopción está creciendo muy rápidamente, el ecosistema todavía se encuentra evolucionando.
Algunos conectores producen Iceberg de forma nativa, mientras otros siguen persistiendo únicamente Parquet. - Coste de metadatos
El beneficio de la gobernanza y versionado tiene un coste: la gestión de metadatos adicionales.
¿Qué significa esto para Snowflake?
Quizá la consecuencia más interesante es que también está cambiando la forma en la que Snowflake accede al almacenamiento.
Históricamente utilizábamos:
Storage Integration ↓External Stage ↓COPY INTO
Pero cuando hablamos de Iceberg aparece un nuevo concepto:
External Volume ↓Iceberg Table
La diferencia es fundamental:
- Storage Integration = acceso a ficheros
- External Volume = acceso a tablas Iceberg
Snowflake está apostando claramente por esta evolución, incorporando capacidades como:
- Snowflake Storage for Apache Iceberg.
- Horizon Catalog como plano de interoperabilidad.
- Gestión de motores externos sobre Iceberg.
- Aplicación consistente de políticas en ecosistemas multi-motor.
Reflexión final
Durante años el debate estuvo centrado en qué motor analítico utilizar. Hoy la conversación está cambiando. La pregunta ya no es únicamente dónde procesar los datos, sino cómo almacenarlos para que cualquier motor pueda utilizarlos.
Apache Parquet seguirá siendo la piedra angular física de muchos Data Lakes, pero cada vez más organizaciones comenzarán a exigir que sus herramientas de integración produzcan directamente tablas Apache Iceberg. Porque el verdadero valor ya no está en los ficheros. Está en disponer de un modelo abierto, gobernado e interoperable que permita que los datos sobrevivan a las tecnologías que los consumen
Foto de portada gracias a Anna Shvets de Pexels: https://www.pexels.com/es-es/foto/pastillas-de-medicacion-aislado-sobre-fondo-amarillo-3683096/
Alb3rto Alonso 