F3 - un formato de archivo de datos de código abierto para el futuro

• F3 es un formato de archivo de datos diseñado pensando en la eficiencia, la interoperabilidad y la escalabilidad
• Ofrece una forma de organización de datos que corrige las limitaciones de diseño de formatos de generaciones anteriores como Parquet, mientras mantiene la interoperabilidad y la extensibilidad mediante decodificadores Wasm integrados
• Los archivos F3 autodescriptivos están estructurados para contener no solo datos y metadatos, sino también el binario de WebAssembly que decodifica los datos
• El enfoque de integrar el decodificador dentro del archivo requiere un espacio mínimo de almacenamiento de unos pocos kilobytes y está diseñado para garantizar compatibilidad en cualquier plataforma, incluso cuando no exista un decodificador nativo
• Es un proyecto de Future-proof File Format que proporciona una estructura de organización de datos y una API genérica para que los desarrolladores puedan agregar fácilmente nuevos métodos de codificación
• Su estado actual es un prototipo de investigación que valida las ideas del artículo, y no debe usarse en producción
• La compilación solo se ha probado en Debian 12 sobre máquinas Intel, y la compilación del paquete PoC y las pruebas unitarias se ejecutan con cargo build -p fff-poc y cargo test -p fff-poc
• La definición del formato de archivo se basa en FlatBuffer, y también se incluyen el código principal, la implementación de decodificación Wasm, y los benchmarks y scripts para los experimentos del artículo
• La licencia es MIT License

[GN⁺]

Comentarios en Hacker News

• No me queda claro por qué recibió tantas recomendaciones, y como la landing page tampoco convence, parece mejor leer el paper: https://dl.acm.org/doi/epdf/10.1145/3749163
  Parece un formato de almacenamiento orientado a columnas que intenta compensar algunas desventajas de Parquet, pero el verdadero campo de batalla de estos formatos es la compatibilidad, y un formato nuevo arranca en desventaja en ese punto
  Parquet es demasiado fuerte solo por haber sido el primero en difundirse ampliamente, y según el paper, la versión de Parquet más usada sigue siendo la más antigua, de 2013, así que ni siquiera Parquet ha logrado reemplazar a Parquet
  Para que F3 supere eso, harían falta resultados muy sólidos, y no parece que los tenga
  Personalmente, tampoco aborda mi mayor queja sobre Parquet, el tema de una sola tabla por archivo, así que hasta el nombre se siente algo exagerado, y además, aunque mete un binario Wasm para decodificación, igual necesitas FlatBuffers para parsear ese bloque, lo que desdibuja el objetivo
  Su principal logro parece ser la mejora en acceso aleatorio, pero el almacenamiento orientado a columnas existe justamente para sacrificar acceso aleatorio y obtener análisis rápidos, y F3 da la impresión de sacrificar análisis rápidos por culpa del decodificador Wasm, así que no termino de entenderlo

  • Lo de una sola tabla por archivo en Parquet se parece más a una expectativa que los motores de consulta le atribuyen al formato que a una limitación del formato en sí
    Spark, DataFusion y DuckDB probablemente no sabrían muy bien qué hacer aunque les dieras un archivo con múltiples tablas
    Es cierto que Parquet hace muchas cosas bien, pero eso no significa que, por haber llegado primero, deba ser para siempre el único formato de archivos para análisis
    El análisis rápido y las cargas de trabajo modernas de aprendizaje automático mezclan de forma natural escaneos por lotes y acceso aleatorio
    Algunos autores de F3 también escribieron un paper que analiza en detalle las desventajas de Parquet: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
    Formatos recientes como Vortex, Lance y F3 intentan resolver los problemas resumidos en ese paper
    Lance tiene ideas interesantes, y Vortex reemplaza los codificadores de caja negra de Parquet por codificaciones transparentes, enfocándose en extensibilidad y rendimiento
    Eso permite reducir el compromiso entre decodificación masiva y decodificación elemento por elemento, logrando a la vez escaneos completos eficientes y acceso aleatorio muy rápido
    Por ejemplo, LangChain explicó que reconstruyó un sistema basado en archivos Parquet usando Vortex y vio una gran mejora de velocidad: https://www.langchain.com/blog/introducing-smithdb
    Como referencia, estoy desarrollando Vortex, así que he pensado bastante en la pregunta de “¿por qué crear un formato nuevo?”
  • Creo que la simplicidad de Parquet no es una desventaja sino una ventaja
    Si necesitas varias tablas, puedes empaquetar varios archivos Parquet en un tar, y es una simplicidad elegantísima porque resulta fácil de leer en cualquier lenguaje que tenga bibliotecas para tar y Parquet
  • Cuando trabajaba con Parquet imaginé un formato llamado .parquetz
    Si fuera un archivo zip con varios archivos Parquet sin comprimir adentro, podrías mover múltiples tablas en un solo archivo y aun así permitir acceso mediante range requests
  • Comparado con el ruido que hoy traen la mayoría de las landing pages, que parecen hechas con ChatGPT, esto hasta se siente como un cambio

• Es bastante ingenioso que no dependa de SDK o bibliotecas por lenguaje y que, si no existen, pueda hacer fallback a métodos Wasm integrados
  “Cada archivo F3 autodescriptivo incluye no solo los datos y los metadatos, sino también el binario WebAssembly (Wasm) que decodifica los datos. El espacio de almacenamiento necesario para incrustar el decodificador en cada archivo es pequeño (del orden de kilobytes) y garantiza compatibilidad en todas las plataformas incluso cuando no existe un decodificador nativo”

  • ¿Entonces ni siquiera hace falta que un atacante cree a propósito un archivo dañado, y basta con meter código malicioso dentro del propio archivo de datos?
  • Se ve genial, pero siento que podría romperse en formatos muy complejos
    ¿Cómo sería un decodificador incrustado para PDF?
    Como está tan acoplado a los bytes del archivo, el autor del archivo sí puede elegir qué formato tiene sentido, pero no todos los formatos tienen una única “etapa correcta de decodificación”
  • No entiendo cómo se supone que esto debería funcionar
    ¿Con qué decodifica el decodificador?
    Va a depender por completo del tipo de datos: algunos formatos son flujos de bytes, otros son planos de píxeles 2D, otros necesitan vértices, planos de píxeles 2D y mapas UV, y en algunos casos un grafo de objetos es más natural
  • Parece el regreso de los applets
  • ¿En qué mejora Wasm a los bindings de C?

• No entiendo qué están viendo los demás para hablar de esto
  En el README casi no hay información sobre qué es esto ni qué problema resuelve; solo veo una explicación de FlatBuffers y enlaces a directorios del código fuente
  ¿Me estoy perdiendo de algún contexto?

  • Hay un paper enlazado: https://dl.acm.org/doi/epdf/10.1145/3749163

• Parece que hace falta un poco más de “por qué”
  Dicen que supera las desventajas de Parquet, pero me da curiosidad cuáles son exactamente
  Desde luego, no sería por tener un soporte de herramientas más amplio
  ¿Por qué habría que dejar Parquet u ORC y usar esta estructura?

  • El “por qué” está enlazado en la bibliografía al final del README, y no parece que esto esté hecho para consumirse de forma aislada solo desde este repositorio
    Conviene ver primero el paper: https://doi.org/10.1145/3749163
  • Al principio no entendía en absoluto de qué iba, pero hay un buen punto sobre cómo Parquet no considera bien el hardware y cómo sus metadatos son algo globales
    Este artículo me pareció interesante: https://medium.com/@reliabledataengineering/f3-the-future-pr...
  • Buena parte de esto parece algo que podría resolverse invirtiendo más tiempo de desarrollo en Parquet
  • El paper menciona Parquet, ORC, Nimble, Lance, TSFile, Bullion y BtrBlocks

• Algunos dijeron que era genial, pero haciendo de molesto escéptico de HN, esto se ve algo tonto
  Los formatos de compresión de datos son algo secundario frente a lo que se va a hacer con esos datos después de decodificarlos
  Un archivo de audio y una imagen SVG son cosas totalmente distintas, y aunque hubiera una VM embebida que descompusiera video a píxeles en bruto, eso no haría que un editor de texto pudiera reproducir ese video, así que no aparece una interoperabilidad fundamentalmente nueva
  Cada formato nuevo sigue necesitando manejo específico del formato
  Por ejemplo, si inventaras una compresión de video mejor que H.265 pero no todos los sistemas la soportaran, podría servir para meter un decodificador y reproducirlo en hardware viejo
  Pero incluso eso muestra una debilidad. Es poco probable que hardware antiguo pueda manejar bien por software la decodificación de formatos de video del futuro, y aunque esta idea hubiera aparecido en los 90, no habría hecho posible ver Netflix en un i386
  Del mismo modo, también dudo que esto hubiera permitido abrir archivos de Word 2021 en Word 97, porque no existe una correspondencia 1:1 entre las estructuras de datos
  Si esa compatibilidad no es una victoria clara, no sé cuál sería el objetivo
  Los inconvenientes sí están claros. Si aparece un bug en el decodificador que haya que corregir, ¿cómo parcheas todos los archivos que ya llevan ese decodificador embebido?
  Además están el sobrecosto en tamaño y los riesgos de seguridad, y esto añade una superficie de ataque considerable a todos los parsers de formatos, aumentando las oportunidades de ejecución remota de código, ataques de agotamiento de recursos, etc.
  No es que siempre sea un enfoque equivocado, pero importa cuál es la ganancia

  • Parece que todavía no te has topado con el problema que resuelve esta familia de formatos
    Si buscas formatos de almacenamiento columnar, hoy en día sus ventajas y desventajas están bastante bien documentadas
    Claro, no es para decodificar video

• Una ventaja de algunos formatos modernos es que las herramientas pueden leerlos con una velocidad percibida muy alta
  Por ejemplo, DuckDB puede aplicar todo tipo de optimizaciones al leer su propio formato nativo o Parquet
  Pero no tengo claro si esas optimizaciones podrán aplicarse con eficacia a un formato que requiere ejecutar un bloque de Wasm para entenderlo
  Ya sea con SIMD o sin SIMD, si haces una pasada sobre los datos y esa pasada no entiende la consulta, quizá ya perdiste desde ahí
  Solo hojeé el inicio del paper, así que el formato real podría ser menos general de lo que suena

  • Según entiendo, es un mecanismo de fallback

• Más o menos puedo imaginarlo como reemplazo de los EXE autoextraíbles, pero gran parte de la razón para elegir un formato de archivo específico es por las funciones concretas que ofrece ese formato
  Un sistema autodescriptivo podría caer en el mismo estado que otros formatos: “demasiadas funciones en competencia y nadie puede manejar todas”
  Por ejemplo, ¿este archivo puede usarse eficientemente con mmap?
  Tal vez sí si por dentro imita a tar, pero no lo sabrás hasta ejecutarlo
  ¿Se puede saltar a una posición específica de bytes y descomprimir solo una parte?
  Quizá solo soporte la versión preliminar pública de la navegación ISO-36898533, y la biblioteca de archivos que usas dejó de soportarla hace 6 años
  Si reescribes 1 MB en medio, ¿solo hay que cambiar las páginas correspondientes en disco, o hay que reescribir todo?
  Puede que el bloque de Wasm soporte 97 APIs para eso, 35 de ellas copias con otro nombre, y que haya terminado siendo más grande que los propios datos, pero a nadie le importó
  Al final hay 19 opciones reconocibles, pero la aceleración nativa de Wasm del CPU solo maneja dos o tres, así que igual quizá haya que especializar bastante el código
  Al menos con *.tar.gz uno tiene cierta idea de lo que se puede hacer

• Bien. El mundo siempre necesita formatos de datos mejores
  Solo que creo que el README llamaría más la atención si pusiera de inmediato las ventajas frente a Parquet y otros formatos de archivo
  Cuando alguien entre a https://github.com/future-file-format/f3, debería poder ver por qué valdría la pena probarlo
  Publiquen ventajas y métricas, y las métricas pueden ser solo las que les favorezcan
  Puede que tenga buenos casos de uso, pero con el README actual no queda claro quién debería usarlo ni por qué

• Si vas a guardar datos a escala de PB durante más de 10 años, no quisiera depender de que en el futuro siga existiendo un intérprete de Wasm y además sea lo bastante rápido como para leer los archivos
  Quiero una especificación de bytes simple y bien documentada, como Parquet
  Además, meter la lógica de decodificación dentro de un binario Wasm añade una capa de ejecución activa a algo que debería ser almacenamiento en frío

  • El formato WinRAR también incluye bytecode de la RAR VM como parte del archivo para lograr compresión más moderna en archivos multimedia
    Está sandboxeado y fue ampliamente aceptado, y Wasm tiene esa misma capacidad de aislamiento
    Incluso podría considerarse mejor para preservación a largo plazo
    Porque no necesitas llevar aparte el programa de descompresión; ya viene dentro del propio archivo
  • ¿Quieres decir que no te gustaría ejecutar una función personalizada de parseo de datos de hace 10 años cada vez que leas un solo registro de datos?

• Si la decodificación falla, me preocupa tener que depurar el Wasm que metió otra persona, y que además pueda contener bugs arbitrarios
  Podría ayudar que hubiera una biblioteca decodificadora estándar que el proyecto mantenga y pruebe, pero no estoy seguro de si eso mata la ventaja de flexibilidad que ofrece este enfoque

  • Como Wasm tiene ejecución determinista, si la decodificación falló de mi lado, también debería haber fallado del lado de quien lo creó
    Es decir, no es un problema nuevo creado por mi sistema, y ellos deberían poder reproducirlo de forma independiente de cualquier cliente