Snowflake declaró el 29 de octubre la disponibilidad general del acceso a tablas Apache Iceberg gestionadas externamente a través de su catálogo Horizon. La función deja atrás la fase de vista previa y permite que motores ajenos a la plataforma lean y escriban esas tablas usando la API del catálogo REST de Iceberg que expone Horizon.
La lista de motores que la propia compañía menciona define bien el alcance: Apache Spark, Trino, DuckDB y PyIceberg. Las tablas pueden residir tanto en bases de datos enlazadas a un catálogo externo como en bases de datos estándar de Snowflake, y en ambos casos se aplican los controles de acceso basados en roles de la plataforma. Ese es el punto que diferencia este anuncio de una simple interoperabilidad de formato: no se trata solo de que varios motores entiendan los mismos ficheros Parquet, sino de que el permiso concedido a un rol dentro de Snowflake siga vigente cuando quien consulta es un proceso de Spark que vive fuera.
Conviene leer también las excepciones. El acceso a tablas Iceberg gestionadas externamente cuando llevan aplicadas políticas de protección de datos de Snowflake —enmascaramiento, filas filtradas por política— sigue en vista previa, es decir, no cubierto por los compromisos de servicio de una función general. Y la capacidad no está disponible en los despliegues FedRAMP Moderate ni FedRAMP High, una limitación que afecta al sector público estadounidense y que no debería condicionar a una organización europea, pero que conviene tener presente en entornos multinacionales.
El movimiento encaja en la tendencia que lleva dos años reordenando el mercado: la separación entre el almacenamiento, que se estandariza en formatos abiertos de tabla, y el motor de cálculo, que pasa a ser una elección reversible. Iceberg se ha consolidado como ese punto de encuentro, y el catálogo —la pieza que resuelve qué tablas existen, dónde están sus metadatos y quién puede tocarlas— se ha convertido en el terreno donde los fabricantes compiten de verdad. Abrir Horizon a motores externos es, en ese contexto, una apuesta por ser el catálogo de referencia aunque el cálculo se vaya a otra parte.
Para un arquitecto de datos en España la implicación es concreta. Si una organización ya tiene Snowflake como plataforma principal y mantiene cargas de procesamiento en Spark o consultas federadas con Trino, hasta ahora el patrón habitual era duplicar datos o montar una capa de permisos paralela para esos motores. Con esta función, esa duplicidad deja de ser necesaria y el gobierno del acceso se concentra en un único sitio, que es justo lo que suele fallar en las arquitecturas híbridas: no la lectura de los datos, sino la coherencia de quién puede leer qué.
La prueba que merece la pena hacer antes de rediseñar nada es medir el rendimiento real de esa lectura externa frente al que se obtiene dentro de la plataforma, y comprobar si las políticas de protección que ya estén en uso caen dentro de la parte que sigue en vista previa. De eso depende que la función sea aprovechable hoy o un plan para más adelante.
Más en Dataprix: clasificación de plataformas de datos para empresas de Dataprix
Fuente: Snowflake (notas de versión)
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.