F3

Qué es F3 (según se infiere del hilo)

• Formato de almacenamiento de datos columnar pensado como alternativa a Parquet/ORC/Nimble/Lance, no como un formato de archivo general.
• Diseñado para cargas de trabajo de analítica / “big data”, con foco en acceso aleatorio y extensibilidad.
• Incorpora decodificadores WebAssembly (Wasm) en cada archivo como un mecanismo autodescriptivo y compatible con versiones futuras.
• Los decodificadores parecen producir buffers al estilo Arrow; los metadatos del formato se definen mediante FlatBuffers.

Crítica de la documentación y del “por qué”

• Muchos lectores consideran que el README de GitHub es vago y con mucho tono de marketing: no queda claro qué hace el formato, qué problemas resuelve o dónde debería usarse.
• La justificación central está sobre todo en el artículo de investigación enlazado; el repositorio por sí solo se considera difícil de entender.
• Se pide que las ventajas frente a Parquet (con métricas) se resuman directamente en el README.

Motivación frente a Parquet y otros formatos

• Entre las carencias citadas de Parquet están: diseño ajeno al hardware, metadatos globales/engorrosos, dificultad para añadir nuevas codificaciones manteniendo compatibilidad y acceso aleatorio débil.
• Algunos sostienen que esto podría abordarse invirtiendo más ingeniería en Parquet o en formatos alternativos como Vortex o Lance.
• Otros ven valor en nuevos formatos para cargas mixtas de lotes + acceso aleatorio y para cargas de trabajo de ML, aunque la amplia compatibilidad de Parquet sigue siendo una gran ventaja competitiva.

Decodificadores Wasm embebidos: pros y contras

• Defensores:
  • Resuelve la compatibilidad futura para nuevas codificaciones sin actualizar a cada lector.
  • VM aislada, independiente de la plataforma; los decodificadores pueden ser funciones puras que devuelven buffers.
  • Ideas similares ya han existido (VM de RAR, fuentes, Anyblox); los runtimes de Wasm pueden limitar la memoria y el número de instrucciones.
• Escépticos:
  • Incrustar código ejecutable en archivos de datos aumenta la superficie de ataque (RCE, DoS, bombas de compresión).
  • Incluso con aislamiento, es probable que haya fallos en los motores Wasm o en las interfaces del host.
  • Hace que la ingesta de datos no confiables sea arriesgada a menos que Wasm se desactive, lo que socava una propuesta de valor clave.
  • Depurar decodificadores Wasm de terceros puede ser doloroso.

Rendimiento, adopción y longevidad

• Preocupa que la decodificación basada en Wasm pueda ser más lenta e interfiera con optimizaciones a nivel de motor (por ejemplo, la vectorización al estilo DuckDB).
• Se cuestiona si un proyecto de investigación con pocos commits recientes y sin apoyo del ecosistema puede desplazar a Parquet.
• Algunos ven F3 como potencialmente mejor para archivos de archivo histórico, pero otros sostienen que formatos simples, tipo texto (CSV/JSON) o el propio Parquet son más a prueba del futuro.
• Sentimiento general: idea interesante e ingeniosa, con serios obstáculos prácticos, de seguridad y de adopción.