Apache Iceberg en Snowflake: portabilidad y dependencias

«Si guardamos las tablas en Iceberg, podremos cambiar de motor cuando queramos». La frase tiene una base técnica atractiva y un final demasiado optimista. Un formato abierto puede reducir el coste de mover o compartir los datos; cambiar una plataforma exige trasladar también decisiones, permisos, procesos y hábitos que rara vez caben dentro de un archivo.

Para quien trabaja con Snowflake, la pregunta útil es qué libertad necesita ejercer: consultar una misma tabla desde otro motor, incorporar datos gestionados fuera de la plataforma o poder abandonarla en el futuro. Son objetivos relacionados, pero sus costes y condiciones no coinciden. Comprarlos todos bajo la palabra «apertura» dificulta saber qué estamos consiguiendo.

¿Usar Iceberg elimina la dependencia de Snowflake?

Reduce ciertas dependencias del formato de tabla, pero no demuestra que una aplicación pueda cambiar de plataforma sin trabajo adicional. La portabilidad debe evaluarse también en el catálogo, los permisos, las transformaciones y la operación del conjunto.

Lo que abrió Iceberg fue la tabla

Iceberg organiza archivos y metadatos para representar tablas con estados consistentes. Su especificación describe cómo se identifican los datos, los esquemas y las instantáneas. Ese acuerdo permite que implementaciones diferentes interpreten una misma estructura. No exige que todos los motores tengan idéntico optimizador, catálogo de funciones o modelo de seguridad.

También importa la versión del formato. La especificación explica que las versiones introducen capacidades que pueden romper la compatibilidad con lectores antiguos; mantener una tabla en una versión anterior permite evitar funciones todavía no implementadas por determinados motores. Decir «soporta Iceberg» es el comienzo de una conversación de compatibilidad, no su conclusión.

La diferencia resulta más clara si imaginamos dos motores leyendo una tabla de ventas. Podemos obtener los mismos registros y seguir necesitando adaptar expresiones, reconstruir autorizaciones y revisar la forma en que cada plataforma ejecuta el trabajo. La portabilidad del almacenamiento ya aporta valor, aunque todavía no hayamos demostrado la portabilidad de la aplicación.

El caso de Netflix habla de metadatos antes que de libertad comercial

La propuesta de Iceberg para la incubadora de Apache, actualizada en 2019, documentaba un caso de Atlas en Netflix: un mes de métricas repartido entre 2,7 millones de archivos y 2.688 particiones. La planificación de una consulta sobre Hive con Parquet tardaba 9,6 minutos. Con Iceberg y filtrado por particiones, esa planificación se reducía a diez segundos.

La misma propuesta mostraba otra variante, con filtrado por particiones y mínimos/máximos: 25 segundos de planificación y 42 segundos de tiempo total de consulta. Son medidas distintas; confundir planificación con ejecución completa fabricaría una comparación falsa. Además, hablamos de un caso histórico publicado por los promotores del proyecto, no de un benchmark actual entre Snowflake y sus competidores.

El caso ayuda a entender el problema original: a cierta escala, averiguar qué archivos hacen falta puede convertirse en una carga considerable. Una estructura de metadatos mejor diseñada tiene utilidad operativa por sí misma. Presentar Iceberg únicamente como un arma contra la dependencia de proveedores deja fuera buena parte de su sentido técnico.

Quién administra la tabla sigue importando

La documentación de Snowflake consultada para este artículo distingue entre utilizar Snowflake como catálogo y emplear un catálogo externo. En el primer caso, Snowflake gestiona el ciclo de vida, incluida la compactación. Con catálogo externo no asume ese mantenimiento. Admite lectura y, en las integraciones compatibles con catálogos REST de Iceberg, también escritura; ya no sería correcto resumir toda la modalidad externa como «solo lectura».

Esto afecta a las personas que operan la plataforma. Si varios motores generan archivos, alguien debe sostener una política coherente de mantenimiento y conservación. Una arquitectura con más piezas puede ser la adecuada; lo problemático es venderla internamente como si repartir responsabilidades hiciera desaparecer el trabajo.

Hay un límite especialmente revelador: Snowflake documenta que las bases enlazadas a un catálogo no sincronizan el control de acceso remoto de usuarios y roles. También mantiene restricciones de compatibilidad, como los borrados por igualdad a nivel de fila. Compartir el formato no basta para dar por compartidas todas las capacidades ni todos los permisos.

Imaginemos un equipo que protege ciertos datos mediante una política aplicada al consultar desde su motor habitual. Incorporar un segundo lector exige comprobar qué protección recibe ese lector y qué credenciales utiliza. El contrato de interoperabilidad debe incluir el acceso efectivo, además del resultado de una consulta de demostración.

Mapa de portabilidad en cuatro capas

El mapa de portabilidad en cuatro capas distingue qué libertad está demostrada y cuál sigue siendo una expectativa. Es una clasificación propia para evaluar una decisión, no una certificación de compatibilidad.

Datos: Otro motor interpreta los archivos, metadatos y funciones de formato que usamos.
Catálogo: Puede descubrir y actualizar las tablas con la integración concreta elegida.
Significado y permisos: Conservamos el resultado de las transformaciones y los controles de acceso necesarios.
Operación: Hay responsables y capacidad para mantenimiento, incidentes y evolución fuera del origen.

Leer una tabla con otro motor demuestra una capacidad de la primera capa; no completa automáticamente las demás. Si la necesidad actual es compartir datos, esa evidencia puede bastar para justificar una adopción acotada. Si el argumento es poder salir de la plataforma, habrá que sostener el mapa completo y registrar los límites observados.

Formato abierto ≠ aplicación portable. Interoperabilidad ≠ independencia operativa. Dos motores pueden compartir datos y mantener obligaciones diferentes sobre catálogo, permisos y mantenimiento.

La opción de salida tiene un coste de conservación

Una salida creíble necesita mantenerse practicable. Si durante años acumulamos transformaciones muy específicas de una plataforma, la tabla puede seguir siendo abierta mientras la aplicación se vuelve cada vez más difícil de trasladar. Eso no convierte las funciones propietarias en malas decisiones: a menudo compran productividad y simplifican la operación. Lo importante es reconocer qué estamos intercambiando.

Podemos valorar esa elección con criterios comprensibles para el negocio:

Interoperabilidad inmediata: qué consumidor real utilizará los mismos datos y qué duplicación evitaremos.
Responsabilidad operativa: quién mantiene la tabla y responde ante escrituras incompatibles, permisos incorrectos o degradación.
Salida demostrable: qué parte de un producto de datos representativo se ha podido ejecutar fuera y qué trabajo quedó pendiente.

Son criterios de decisión, no una receta de migración. Una prueba pequeña y representativa puede revelar más dependencias que un inventario enorme de funciones marcadas en verde. Tendrá especial valor si incluye la actualización de datos y sus controles de acceso, porque una lectura aislada no representa toda la vida de un producto.

En la comparación entre Snowflake y Databricks, conviene separar las diferencias de plataforma de la posibilidad de compartir un formato. La elección puede seguir favoreciendo a Snowflake incluso cuando otra herramienta pueda leer nuestros archivos; el equipo puede valorar más su operación integrada que la independencia de cada componente.

La libertad útil se reconoce cuando podemos ejercerla. Si Iceberg permite incorporar un consumidor necesario o reducir una duplicación costosa, ya tenemos una razón concreta para adoptarlo. Si el argumento es una hipotética migración futura, merece la pena exigir algo más tangible que la promesa de que, llegado el día, todo encajará.