Tras una década de dominio de Parquet, ¿puede WASM moverlo?
Tienes una tabla Parquet que lleva ocho años acumulando datos, un volumen ni grande ni pequeño, unos trescientos y pico GB. Un día te llega un nuevo requisito: hacer consultas puntuales sobre esa tabla — nada de full scan, solo recuperar unas decenas de filas por clave primaria. Lo intentas y descubres que Parquet no es que no pueda, pero cada vez tienes que rebuscar en los column chunks de los row groups para localizar la página objetivo, con páginas de cientos de miles de filas y una sobrecarga de I/O que no tiene nada que ver con lo que pide la consulta.
Y piensas: llevamos más de diez años con formatos de almacenamiento columnar, ¿cómo es que ni siquiera hacen bien un acceso aleatorio como Dios manda?
Este es exactamente el punto de partida del artículo de SIGMOD con el que el grupo de bases de datos de CMU presentó F3 (Future File Format). Y es también exactamente el punto que pisa la fibra más sensible de las guerras de formatos.
Un formato nuevo, un problema viejo
El problema que F3 pretende resolver se resume en una frase: los formatos de almacenamiento columnar actuales (Parquet, ORC) nacieron en la era Hadoop; su disposición de almacenamiento y sus mecanismos de evolución ya no son adecuados para el hardware y las cargas de trabajo actuales. Los row groups de Parquet tienen una granularidad gruesa, los metadatos son planos y las codificaciones de columna están congeladas en la especificación — para que una codificación nueva llegue a producción, hay que esperar a que todas las implementaciones de reader se actualicen. Y un dato que cita el artículo de F3 es particularmente revelador: la versión de Parquet más utilizada hoy sigue siendo la v1, de 2013.
Parquet ni siquiera ha logrado reemplazarse a sí mismo.
La solución de F3 ataca por dos flancos. A nivel de layout, introduce una jerarquía más fina: IOUnit (unidad básica de I/O) → EncUnit (unidad básica de codificación, 64K filas por defecto) → sub-EncUnit vectoriales opcionales. Esta jerarquía permite al reader hacer proyecciones con granularidad más fina — ¿quieres solo unas miles de filas de una columna concreta? Recorres el índice de EncUnits y te saltas los bloques irrelevantes.
A nivel de extensibilidad, la idea central de F3 es embeber el decodificador dentro del propio archivo como un binario WASM. Cada EncUnit puede llevar un WASM ID que apunte a un decodificador almacenado al final del archivo. Si el reader no reconoce esa codificación localmente, carga el módulo WASM y decodifica — sin necesidad de actualizar el reader, sin esperar a que la comunidad llegue a un consenso. El artículo afirma que los decodificadores WASM ocupan del orden de KB, «negligible storage cost».
Estas son las dos cartas de F3: acceso aleatorio más fino, y usar WASM para sortear el bloqueo de compatibilidad.
Qué hay detrás de los números
El benchmark de F3 compara Parquet, ORC, Vortex, Lance y Nimble. De los experimentos del artículo se desprenden varias tendencias:
- Acceso aleatorio: la latencia de las consultas puntuales de F3 es significativamente menor que la de Parquet, especialmente en escenarios con pocas columnas y pocas filas. No es magia — la jerarquía de EncUnits permite de forma natural una granularidad de I/O menor.
- Tasa de compresión y velocidad de descompresión: en líneas generales, a la par con Parquet. F3 usa por defecto codificación Cascade (similar a la codificación por defecto de Vortex) para cada EncUnit de 64K filas, combinada con compresión Zstd/LZ4. No gana, pero tampoco pierde.
- Sobrecarga del decodificador WASM: usar el decodificador WASM es más lento que la decodificación nativa, pero el artículo se esfuerza en argumentar que la diferencia está dentro de lo aceptable. Aquí hay que hacer un juicio de ingeniería: la razón de ser del decodificador WASM es garantizar que «el archivo se puede leer». Es un fallback, no un acelerador.
En conjunto, lo que F3 muestra en el benchmark es una postura de «mejora en ciertas dimensiones, sin perder contra Parquet en el global». Para un artículo de SIGMOD, este resultado es suficiente. Para una guerra de reemplazo de formato, este resultado no basta.
Compatibilidad: el verdadero foso
El comentario más votado en la discusión de HN fue de vouwfietsman, y dijo algo muy cruel pero difícil de refutar:
Parquet is unfortunately very good just by virtue of being first, and so widely supported.
¿Cuán sólido es el nicho ecológico de Parquet? Basta enumerar algunos hechos: Spark, DuckDB, Pandas, Polars, Snowflake, BigQuery, Redshift Spectrum, AWS Athena, Trino, Presto, ClickHouse (tablas externas)… Prácticamente todas las herramientas de datos que se te ocurran soportan Parquet de forma nativa. Su especificación es abierta, pero tras el roce continuo entre más de veinte implementaciones principales, se ha formado un estándar de facto. Un archivo Parquet que generes lo puede leer cualquier herramienta — es el resultado de diez años de corrección de bugs y adaptación de interoperabilidad acumulados por la comunidad.
Esto nos lleva a una paradoja: F3 intenta resolver con WASM el problema de que «las codificaciones nuevas no puedan ser leídas por readers antiguos», pero lo que de verdad frena a un formato nuevo es el coste de adopción ecológica.
¿Qué tendría que hacer una empresa para migrar a F3?
- Añadir un reader de F3 en todos los motores de consulta que use (el fallback WASM solo puede decodificar EncUnits, no sustituye una implementación completa de reader — parseo de cabeceras, recorrido de metadatos, predicate pushdown, poda de proyección, todo eso necesita código nativo).
- Soportar escritura F3 en todos los pipelines de datos (ETL/ELT).
- Hacer que todas las herramientas de gobernanza de datos (catálogo, schema registry, linaje) puedan parsear los metadatos de F3.
- Conseguir que los partners externos con los que compartes datos puedan leer F3.
Esto no lo resuelve un decodificador WASM. El foso de Parquet es el tejido ecológico acumulado durante una década.
Las tensiones del enfoque WASM
El diseño WASM de F3 desató una subdiscusión intensa en HN, concentrada en tres niveles.
El primer nivel es la seguridad. Meter código ejecutable dentro de un archivo, por muy maduro que sea el sandbox de WASM, dispara de forma natural las alarmas de cualquier ingeniero de seguridad. Alguien trazó la analogía con JavaScript en PDF — el estándar incluyó esa capacidad, pero todo visor sensato la desactiva por defecto. Los defensores de F3 replican que el decodificador WASM es solo una pure function, sin capacidad de I/O, y el sandbox puede limitar el número de instrucciones y la memoria máxima. Pero los flujos de trabajo de ingeniería de datos a menudo implican archivos de fuentes no confiables, y permitir la ejecución de WASM arbitrario sigue siendo una opción que muchos equipos de seguridad no aceptarán.
El segundo nivel es el posicionamiento de rendimiento. vouwfietsman lo clavó: el valor central del almacenamiento columnar es intercambiar acceso aleatorio por rendimiento analítico mediante escaneo secuencial. F3 convierte la mejora del acceso aleatorio en su principal argumento de venta, pero el acceso aleatorio nunca fue el objetivo de diseño del almacenamiento columnar. Si optimizas el acceso aleatorio a costa de ralentizar el full scan (aunque solo sea por la ruta de decodificación WASM), estás sacrificando la ventaja principal para ganar una capacidad secundaria.
El tercer nivel es la coherencia de las decisiones técnicas. La capa de metadatos de F3 usa FlatBuffers de Google para serializar el esquema y la información de layout. El decodificador WASM necesita pasar datos de un lado a otro entre el lenguaje anfitrión y la memoria WASM, y el propio parseo de FlatBuffers conlleva su sobrecarga. Hay quien opina que introducir la combinación de runtime WASM + serialización/deserialización FlatBuffers equivale a meter dos capas de abstracción en la ruta de lectura — justo la parte que el almacenamiento columnar querría mantener lo más ligera posible.
Estas objeciones no significan que el diseño de F3 sea incorrecto. Pero apuntan a una proposición central: F3 intenta resolver la contradicción secundaria de la evolución de formatos, no la principal. La contradicción principal es «cómo conseguir que todo el mundo quiera migrar», no «cómo hacer que una codificación nueva llegue a tierra».
El eco de la historia
En los comentarios de HN alguien colgó xkcd #927 («Standards»), alguien mencionó el destino de OpenDoc — un formato de archivo técnicamente superior que acabó perdiendo contra el efecto red. Y también hubo quien dijo que no hay que ser tan pesimista: si F3 ofrece en ciertos nichos un valor que Parquet no puede dar (por ejemplo, almacenes de features online que necesitan acceso aleatorio frecuente, o dominios verticales que necesitan codificaciones personalizadas), no necesita ganar todo el mercado, solo consolidarse en su propio nicho ecológico.
Nos inclinamos a pensar que ambos diagnósticos no son mutuamente excluyentes. La historia de la sustitución de formatos sí respalda de forma abrumadora la tesis de «la compatibilidad primero», pero en la historia nunca había aparecido un diseño como «embeber el decodificador dentro del archivo». La llegada de WASM ha cambiado la estructura de costes del código ejecutable multiplataforma — hace diez años era impensable embeber un entorno de ejecución con sandbox dentro de un archivo; hoy es solo una línea: wasmtime::Module::new().
Puede que F3 no reemplace a Parquet, pero el paradigma del decodificador WASM que propone podría acabar siendo absorbido por Parquet o por otros formatos. El mejor final no es la sustitución, sino la contaminación — que el formato antiguo aprenda tu buen diseño y tú sigas corriendo hacia la siguiente tierra de nadie.
Desde la tendencia actual
F3 sigue siendo por ahora un prototipo de investigación — el README comienza declarando que «no debe usarse en entornos de producción», el repositorio de GitHub tiene solo 4 commits y los scripts de reproducción del benchmark aún no están completos. Le queda mucho camino de ingeniería por delante antes de que un equipo pueda evaluarlo seriamente como alternativa.
Y desde la perspectiva de la tendencia de la industria, la posición de Parquet es prácticamente inamovible a corto plazo. El auge de formatos de tabla abiertos como Iceberg, Delta Lake y Hudi ha fijado aún más a Parquet como la capa base de la arquitectura lakehouse — la guerra de formatos de tabla se está librando en las capas superiores, y el formato de archivo ha quedado, paradójicamente, aún más «bloqueado». No es muy factible estar migrando a Iceberg y al mismo tiempo cambiar el formato de archivo subyacente: es el doble de coste de migración.
Pero la pregunta que plantea F3 es valiosa. El cuello de botella evolutivo de Parquet es real — que la v1 siga dominando el mundo sin haberse movido en diez años no es un estado normal. La idea del decodificador WASM, aunque al final no la capitalice F3, puede que acabe materializándose en la spec de otra versión de otro formato.
Dicho de otro modo: esto no va a ser el funeral de Parquet, pero podría ser el primer latido del formato de almacenamiento columnar de la próxima generación.
Referencias: artículo de SIGMOD de F3 · repositorio GitHub · discusión en HN