F3 - um formato de arquivo de dados open source para o futuro

• F3 é um formato de arquivo de dados projetado com eficiência, interoperabilidade e escalabilidade em mente
• Ele oferece uma forma de organização de dados que corrige as limitações de layout de formatos de geração anterior, como o Parquet, mantendo interoperabilidade e extensibilidade por meio de decodificadores Wasm embutidos
• Um arquivo F3 autodescritivo armazena não apenas dados e metadados, mas também o binário WebAssembly que decodifica os dados
• A abordagem de embutir o decodificador no arquivo exige um espaço mínimo de armazenamento na casa dos kilobytes e foi projetada para garantir compatibilidade em qualquer plataforma, mesmo quando não houver um decodificador nativo
• É um projeto de Future-proof File Format que fornece uma estrutura de organização de dados e uma API genérica para que desenvolvedores possam adicionar facilmente novos métodos de codificação
• O estado atual é um protótipo de pesquisa que valida as ideias do artigo, e seu uso em produção é proibido
• O build foi testado apenas no Debian 12 em máquinas Intel, e a construção do pacote PoC e os testes unitários são executados com cargo build -p fff-poc e cargo test -p fff-poc
• A definição do formato de arquivo é baseada em FlatBuffer, e o projeto também fornece o código principal, a implementação de decodificação em Wasm, além de benchmarks e scripts usados nos experimentos do artigo
• A licença é MIT License

[GN⁺]

Comentários do Hacker News

• Não entendo muito bem por que isso recebeu tantas recomendações, e a landing page também não é grande coisa, então parece melhor ler o artigo: https://dl.acm.org/doi/epdf/10.1145/3749163
  Parece um formato de armazenamento colunar que tenta compensar algumas desvantagens do Parquet, mas o verdadeiro campo de batalha desses formatos é a compatibilidade, e um formato novo já nasce em desvantagem nesse ponto
  O Parquet é forte demais só por ter sido o primeiro a se disseminar amplamente, e segundo o artigo, a versão de Parquet mais usada ainda é a mais antiga, de 2013, ou seja, nem o próprio Parquet conseguiu substituir o Parquet
  Para o F3 superar isso, parece que seriam necessários resultados muito fortes, mas não parece ser o caso
  Pessoalmente, ele também não trata do meu maior incômodo com o Parquet, o problema de uma única tabela por arquivo, então o nome também parece um pouco exagerado; e, embora inclua um binário Wasm para decodificação, ainda exige FlatBuffers para fazer o parsing desse bloco, o que embaralha o objetivo
  O principal resultado parece ser a melhoria no acesso aleatório, mas armazenamento colunar surgiu justamente para abrir mão do acesso aleatório e obter análises rápidas, e o F3 parece sacrificar análises rápidas por causa do decodificador Wasm, então não faz muito sentido para mim

  • A questão de uma única tabela por arquivo no Parquet está mais próxima das expectativas que os motores de consulta impõem ao formato do que do formato em si
    Spark, DataFusion e DuckDB provavelmente não saberiam muito bem o que fazer mesmo que recebessem um arquivo com várias tabelas
    É verdade que o Parquet faz muita coisa bem, mas isso não significa que, só por ter chegado primeiro, ele deva ser para sempre o único formato de arquivo para análises
    Análises rápidas e cargas de trabalho modernas voltadas a aprendizado de máquina misturam, por natureza, varreduras em lote e acesso aleatório
    Alguns autores do F3 já escreveram um artigo tratando em detalhe das desvantagens do Parquet: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
    Formatos recentes como Vortex, Lance e F3 estão tentando resolver os problemas organizados nesse artigo
    O Lance tem ideias interessantes, e o Vortex troca os codificadores caixa-preta do Parquet por codificações transparentes, com foco em extensibilidade e desempenho
    Com isso, dá para reduzir o compromisso entre decodificação em grande volume e decodificação por elemento, obtendo ao mesmo tempo varreduras completas eficientes e acesso aleatório muito rápido
    Por exemplo, a LangChain explica que refez um sistema baseado em arquivos Parquet com Vortex e viu um grande ganho de velocidade: https://www.langchain.com/blog/introducing-smithdb
    Só para contextualizar, eu desenvolvo o Vortex, então já pensei bastante, em primeira mão, sobre a pergunta “por que criar um formato novo?”
  • Vejo a simplicidade do Parquet como vantagem, não desvantagem
    Se forem necessárias várias tabelas, basta agrupar vários arquivos Parquet em um tar; é algo lindamente simples e fácil de ler em qualquer linguagem que tenha bibliotecas de tar e Parquet
  • Já imaginei um formato chamado .parquetz para trabalhar com Parquet
    Se fosse um arquivo zip contendo vários arquivos Parquet sem compressão, daria para transportar várias tabelas em um único arquivo e ainda acessá-las via range requests
  • Comparado com a maioria das landing pages de hoje, cheias daquele ruído que parece feito por ChatGPT, isto aqui até foge do padrão

• A ideia de não depender de SDKs ou bibliotecas específicos de cada linguagem e, na falta deles, poder recorrer a métodos Wasm embutidos é bem engenhosa
  “Cada arquivo F3 autoexplicativo inclui não só os dados e os metadados, mas também um binário WebAssembly (Wasm) para decodificar os dados. O espaço de armazenamento necessário para embutir um decodificador em cada arquivo é pequeno (na casa dos kilobytes) e garante compatibilidade em todas as plataformas, mesmo quando não houver um decodificador nativo”

  • Então o atacante nem precisaria criar de propósito um arquivo corrompido; bastaria colocar o código de ataque dentro do próprio arquivo de dados?
  • Parece legal, mas acho que pode ruir em formatos de alta complexidade
    Como seria um decodificador embutido para PDF?
    Como ele ficaria fortemente acoplado aos bytes do arquivo, o autor do arquivo até pode escolher que tipo de formato faz sentido, mas nem todo formato tem uma única “etapa correta de decodificação”
  • Não consigo entender como isso deveria funcionar
    O decodificador decodifica para quê?
    Isso dependeria totalmente do tipo de dado: alguns formatos são fluxos de bytes, outros são planos bidimensionais de pixels, outros precisam de vértices, plano bidimensional de pixels e mapa UV, e em alguns casos um grafo de objetos seria mais natural
  • Parece a volta dos Applets
  • Em que o Wasm é melhor do que bindings em C?

• Não faço ideia do que as pessoas estão vendo para falar disso
  No README quase não há informação sobre o que isso é ou que problema resolve; só vejo explicações sobre FlatBuffers e links para diretórios do código-fonte
  Será que perdi algum contexto?

  • Há um artigo linkado: https://dl.acm.org/doi/epdf/10.1145/3749163

• Parece faltar um pouco mais de “por quê”
  Dizem que supera as desvantagens do Parquet, mas fico curioso sobre quais desvantagens são essas
  Certamente não seria pelo amplo suporte de ferramentas
  Por que abandonar Parquet ou ORC e usar essa estrutura?

  • O “por quê” está ligado às referências no fim do README, e não parece que isso foi feito para ser consumido isoladamente só por este repositório
    É melhor começar pelo artigo: https://doi.org/10.1145/3749163
  • No começo eu não entendi absolutamente nada do que estavam falando, mas há um bom ponto sobre o Parquet não considerar muito bem o hardware e ter metadados meio globais
    Achei este texto interessante: https://medium.com/@reliabledataengineering/f3-the-future-pr...
  • Uma boa parte disso parece algo que poderia ser resolvido investindo mais tempo de desenvolvimento no Parquet
  • O artigo menciona Parquet, ORC, Nimble, Lance, TSFile, Bullion, BtrBlocks

• Algumas pessoas disseram que é genial, mas fazendo o papel do chato cético do HN, isso parece um tanto tolo
  O formato de compressão de dados é secundário em comparação com o que você vai fazer com os dados depois de decodificá-los
  Arquivos de áudio e imagens SVG são completamente diferentes, e só porque existe uma VM embutida que decodifica vídeo para pixels brutos não quer dizer que você possa reproduzir esse vídeo num editor de texto, então não surge nenhuma interoperabilidade fundamentalmente nova
  Cada novo formato ainda exige tratamento específico para aquele formato
  Por exemplo, se você cria uma compressão de vídeo melhor que H.265, mas nem todas as plataformas a suportam, pode haver utilidade em embutir um decodificador para reproduzi-la em hardware antigo
  Mas isso também expõe a fraqueza da ideia. É improvável que hardware antigo lide bem com decodificação por software de formatos de vídeo do futuro, e, mesmo que essa ideia tivesse surgido nos anos 1990, isso não faria um i386 rodar Netflix
  Da mesma forma, também duvido que isso permitisse abrir um arquivo do Word 2021 no Word 97, porque não existe correspondência 1:1 entre as estruturas de dados
  Se essa compatibilidade não é uma vitória óbvia, então não sei qual é o objetivo
  As desvantagens são claras. Se aparecer um bug no decodificador que precise ser corrigido, como você vai aplicar patch em todos os arquivos que já embutiram aquele decodificador?
  Também há overhead de tamanho e risco de segurança, além de adicionar uma superfície de ataque significativa a todos os parsers de formato, aumentando as chances de execução remota de código, esgotamento de recursos e afins
  Não é sempre uma abordagem errada, mas o importante é qual é o ganho

  • Acho que você ainda não encontrou o problema que essa família de formatos resolve
    Se procurar por formatos de armazenamento orientados a colunas, hoje em dia os prós e contras estão bem documentados
    Claro, não é para decodificação de vídeo

• Parte da vantagem de alguns formatos modernos é que as ferramentas conseguem lê-los com velocidade percebida muito alta
  Por exemplo, o DuckDB pode aplicar todo tipo de otimização ao ler seu próprio formato nativo ou Parquet
  Mas não sei até que ponto essas otimizações podem ser aplicadas de forma eficaz a um formato em que você precisa executar um bloco de Wasm para entender o formato
  Seja sem SIMD ou com otimização SIMD, se esse passe por cima dos dados não entende a consulta enquanto percorre os dados uma vez, você talvez já tenha saído perdendo
  Só passei os olhos pelo começo do artigo, então o formato real pode ser menos genérico do que parece

  • Pelo que entendi, é um mecanismo de fallback

• Consigo até imaginar isso substituindo EXEs autoextratores, mas boa parte do motivo para escolher um formato de arquivo específico é pelas funcionalidades concretas que ele oferece
  Um sistema autodescritivo também pode cair no mesmo estado dos outros formatos: “tem funcionalidades concorrentes demais e ninguém consegue tratar todas”
  Por exemplo, este arquivo pode ser mapeado com mmap de forma eficiente?
  Talvez possa, se por dentro ele imitar um tar, mas você não sabe antes de executar
  Dá para ir até uma posição específica em bytes e descomprimir só uma parte?
  Talvez ele só suporte a versão preliminar pública da navegação ISO-36898533, e a biblioteca de arquivos que você usa tenha removido esse suporte há 6 anos
  Se eu reescrever 1 MB no meio, basta trocar as páginas correspondentes no disco ou preciso regravar tudo?
  O bloco de Wasm pode suportar 97 APIs para isso, 35 delas cópias com nome diferente, e acabar ficando maior que os próprios dados sem que ninguém se importasse
  No fim, existem 19 opções reconhecíveis, mas a aceleração nativa de Wasm da CPU só lida com duas ou três, então ainda pode ser necessário especializar pesadamente o código
  Pelo menos com *.tar.gz dá para ter alguma noção do que é possível

• Bom. O mundo sempre precisa de formatos de dados melhores
  Só acho que o README chamaria mais atenção se trouxesse logo de cara as vantagens em relação ao Parquet e a outros formatos de arquivo
  Quando alguém entra em https://github.com/future-file-format/f3, deveria conseguir ver por que vale a pena testar isso
  Coloquem vantagens e métricas; as métricas podem até ser escolhidas de forma favorável
  Pode haver bons casos de uso, mas olhando só para o README atual, não está claro quem deveria usar isso nem por quê

• Se eu estivesse guardando dados em escala de PB por mais de 10 anos, não gostaria de depender da existência futura de um interpretador Wasm que continue existindo e seja rápido o suficiente para ler os arquivos
  Eu preferiria uma especificação de bytes simples e bem documentada, como a do Parquet
  Além disso, colocar a lógica de decodificação dentro de um binário Wasm é adicionar uma camada de execução ativa onde deveria haver armazenamento frio

  • O formato WinRAR também inclui bytecode da RAR VM como parte do arquivo para alcançar compressão mais moderna em arquivos de mídia
    Isso é colocado em sandbox e foi amplamente aceito, e o Wasm tem a mesma capacidade de sandbox
    Para preservação de longo prazo, pode até ser melhor
    Você não precisa carregar um descompressor separado, porque ele já vem dentro do próprio arquivo
  • Quer dizer que você não gostaria de executar uma função personalizada de parsing de dados com 10 anos de idade toda vez que fosse ler um único registro de dados?

• Se a decodificação falhar, preocupa ter que depurar um Wasm inserido por outra pessoa, e ainda por cima ele pode conter bugs arbitrários
  Pode ajudar se houver uma biblioteca decodificadora padrão, mantida e testada pelo projeto, mas não sei se isso acabaria matando a vantagem da flexibilidade que essa abordagem oferece

  • Wasm tem execução determinística, então se a decodificação falhou do meu lado, também deveria ter falhado do lado de quem criou
    Ou seja, não é um problema novo criado pelo meu sistema, e eles deveriam conseguir reproduzi-lo independentemente de qualquer cliente