F3

O que é o F3 (como inferido do thread)

• Formato de armazenamento de dados colunar destinado a ser uma alternativa a Parquet/ORC/Nimble/Lance, não um formato de arquivo geral.
• Projetado para workloads de analytics / “big data”, com foco em acesso aleatório e extensibilidade.
• Incorpora decodificadores WebAssembly (Wasm) em cada arquivo como um mecanismo autodescritivo e compatível com versões futuras.
• Os decodificadores parecem produzir buffers no estilo Arrow; os metadados do formato são definidos via FlatBuffers.

Crítica à documentação e ao “porquê”

• Muitos leitores consideram o README do GitHub vago e excessivamente voltado ao marketing: não fica claro o que o formato faz, quais problemas resolve ou onde deve ser usado.
• A justificativa central está sobretudo no artigo de pesquisa लिंकado; o repositório sozinho é considerado difícil de entender.
• Há pedidos para que as vantagens sobre Parquet (com métricas) sejam resumidas diretamente no README.

Motivação versus Parquet e outros formatos

• As limitações citadas do Parquet incluem: design alheio ao hardware, metadados globais/incômodos, dificuldade em adicionar novas codificações mantendo compatibilidade e fraco acesso aleatório.
• Alguns argumentam que isso poderia ser resolvido investindo mais engenharia no Parquet ou em formatos alternativos como Vortex ou Lance.
• Outros veem valor em novos formatos para cargas mistas de batch + acesso aleatório e workloads de ML, embora a ampla compatibilidade do Parquet continue sendo uma grande vantagem competitiva.

Decodificadores Wasm incorporados: prós e contras

• Defensores:
  • Resolve a compatibilidade com versões futuras para novas codificações sem atualizar todo leitor.
  • Máquina virtual independente de plataforma, em sandbox; decodificadores podem ser funções puras que retornam buffers.
  • Ideias semelhantes já existiram (RAR VM, fontes, Anyblox); runtimes Wasm podem limitar memória e contagem de instruções.
• Céticos:
  • Incorporar código executável em arquivos de dados aumenta a superfície de ataque (RCE, DoS, compression bombs).
  • Mesmo com sandbox, bugs em engines Wasm ou em interfaces de host são prováveis.
  • Torna arriscada a ingestão de dados não confiáveis, a menos que o Wasm seja desativado, o que enfraquece uma proposta central de valor.
  • Depurar decodificadores Wasm de terceiros pode ser doloroso.

Desempenho, adoção e longevidade

• Há preocupação de que a decodificação baseada em Wasm seja mais lenta e interfira em otimizações no nível do engine (por exemplo, vetorização estilo DuckDB).
• Questiona-se se um projeto de pesquisa com poucos commits recentes e sem suporte do ecossistema consegue deslocar o Parquet.
• Alguns veem o F3 como potencialmente melhor para arquivamento, mas outros argumentam que formatos simples, semelhantes a texto (CSV/JSON), ou o próprio Parquet, são mais à prova do futuro.
• O sentimento geral: uma ideia interessante e engenhosa, mas com sérios obstáculos práticos, de segurança e de adoção.