F3

Artigo original ↗ Discussão no Hacker News ↗

Um novo formato de arquivo colunar chamado F3 pretende ser uma alternativa “à prova do futuro” ao Parquet ao incorporar decodificadores WebAssembly (Wasm) diretamente em cada arquivo, prometendo melhor extensibilidade, acesso aleatório e layouts sensíveis ao hardware. Comentadores questionam a documentação vaga do projeto, a falta de atividade recente e o ecossistema limitado, e debatem se incorporar decodificadores executáveis vale o custo adicional de segurança e complexidade operacional — especialmente em comparação com o tooling consolidado do Parquet e seu layout simples e bem especificado. Muitos veem a ideia como interessante para arquivamento ou usos de nicho, mas duvidam que ela possa substituir formatos existentes sem vantagens claras e comprovadas, além de amplo suporte dos engines.

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.