Introdução ao sistema de arquivos distribuído 3FS da DeepSeek

 (maknee.github.io)
20 pontos por GN⁺ 2025-04-18 | 2 comentários | Compartilhar no WhatsApp
  • O 3FS é um sistema de arquivos distribuído open source de alto desempenho desenvolvido pela DeepSeek, com suporte a processamento de dados em larga escala e alta taxa de transferência
  • Ele funciona como um sistema de arquivos comum, mas na prática distribui os dados entre várias máquinas, oferecendo uma camada de abstração que dispensa o usuário de se preocupar com isso
  • Opera com 4 componentes principais (Meta, Mgmtd, Storage, Client), separando metadados, gerenciamento de nós, armazenamento real dos dados e tratamento das requisições dos usuários
  • Alcança consistência forte e tolerância a falhas com o algoritmo CRAQ, propagando com segurança as requisições de escrita por meio de uma estrutura em cadeia
  • O 3FS se diferencia de outros sistemas de arquivos distribuídos pela viabilidade de uso no mundo real e pela escalabilidade de desempenho

O que é o 3FS?

  • 3FS é a sigla de Fire-Flyer File System, um sistema de arquivos distribuído lançado pela DeepSeek
  • Foi lançado junto com a semana de open source da DeepSeek
  • Embora pareça um caminho de arquivo comum, na prática ele abstrai e disponibiliza dados armazenados de forma distribuída em várias máquinas

O que é um sistema de arquivos distribuído?

  • Para o usuário, parece um sistema de arquivos local, mas os dados na verdade ficam distribuídos entre vários servidores
  • Ex.: o caminho /3fs/stage/notes.txt parece um único arquivo, mas na prática está dividido e armazenado em vários servidores
  • O usuário pode usá-lo como um arquivo normal com comandos como mkdir e cat

Por que usar um sistema de arquivos distribuído?

  • Suporte a grandes volumes de dados (na escala de petabytes) e alta taxa de transferência
  • Garante estabilidade por meio de tolerância a falhas (fault tolerance) e redundância
  • Exemplos de uso real:
    • Frameworks de processamento paralelo como HDFS + Spark
    • Checkpointing em pipelines de treinamento de ML
    • Colossus, do Google
    • Haystack, o repositório de fotos da Meta
    • Exemplos de storage para IA: JuiceFS vs CephFS

Componentes do 3FS

  • É composto por 4 tipos principais de nós

Meta

  • Responsável pelo gerenciamento de metadados como caminhos de arquivos, atributos e localização
  • Processa requisições de clientes via RPC (open, stat, close etc.)
  • As informações de metadados são armazenadas no FoundationDB
  • Inode armazena informações como tamanho do arquivo e proprietário
  • DirEntry conecta o caminho ao inode (como em links simbólicos, um único arquivo pode existir em vários caminhos)

Mgmtd

  • Responsável pelo registro de nós e verificação de estado do cluster
  • Os nós se registram ao inicializar e enviam heartbeats periodicamente
  • Atua como um roteador central, eliminando a necessidade de manter conexões diretas entre todos os nós
  • Também gerencia as informações de configuração da cadeia CRAQ

Storage

  • Responsável pelo armazenamento real dos dados
  • Gerencia blocos de disco por meio do ChunkEngine baseado em Rust
    • Rastreia tamanho, offset, checksum, versão etc. dos blocos de disco
    • Fornece uma interface para que o usuário não precise interagir diretamente com os blocos
    • Os metadados são armazenados no LevelDB
  • Há vários workers diferentes
    • AllocateWorker aloca novos blocos
    • PunchHoleWorker recupera blocos não utilizados
    • AioReadWorker processa leituras assíncronas por meio da fila io_uring
  • Durante a escrita, os dados são encaminhados ao próximo nó seguindo a cadeia CRAQ

Client

  • Processa as requisições do usuário e se comunica com os outros nós
  • Fluxo de trabalho:
    • Consulta ao Mgmtd sobre a localização dos nós
    • Requisição ao Meta para operações de arquivo
    • Transferência de dados com o Storage

Algoritmo CRAQ

  • Sigla de Chain Replication with Apportioned Queries, oferecendo consistência forte (linearizability)
  • Fluxo de escrita:
    • Propagação da escrita em ordem Head → Middle → Tail
    • Nas etapas intermediárias, os dados são marcados como dirty (não podem ser lidos)
    • Após o commit no Tail, o estado clean é propagado de volta
  • Fluxo de leitura:
    • Se estiver clean, retorna imediatamente
    • Se estiver dirty, consulta o tail para obter os dados mais recentes

CRAQ do ponto de vista de desempenho

  • A velocidade de escrita é limitada pelo nó mais lento
  • Dados dirty acessados com frequência podem concentrar leituras no tail, gerando possível gargalo de leitura
  • Ex.: queda de desempenho em workloads Zipfianos
  • Em um cluster com 5 nós, a replicação em 3 nós minimiza a perda de desempenho em caso de falha

Diferenças em relação a outros sistemas de arquivos distribuídos

  • A estrutura é semelhante, mas há diferenças na aplicabilidade real e na forma de implementação
  • Itens de comparação:
    • Em quais workloads ele se destaca
    • Flexibilidade no ajuste de desempenho
    • Facilidade de implantação
    • Escalabilidade de throughput
    • Gerenciamento de latência dentro do SLO
    • Confiabilidade
  • Elementos técnicos em detalhe:
    • Causas de gargalos e como são tratadas
    • Presença ou ausência de locks
    • Estruturas de dados utilizadas
    • Hardware-alvo
    • Algoritmos de tolerância a falhas ou métodos de correção de erros usados

Próximo tema da série de blog

  • Está prevista uma verificação das alegações da DeepSeek por meio de análise de desempenho real
  • Itens a revisar:
    • Alegações da DeepSeek sobre gargalos do FUSE
    • Reprodutibilidade dos gráficos de desempenho
    • Análise de cenários de degradação de desempenho
    • Fatores de gargalo (CPU, memória, disco, rede)
    • Em quais workloads o desempenho é superior
    • Comparação com sistemas existentes
    • Diferenças em relação às abordagens usadas para resolver problemas em sistemas existentes
    • Avaliação de possibilidades de melhoria direta

Materiais adicionais

Leituras relacionadas

2 comentários

 
softer 2025-04-19

Era um problema sobre o qual eu também estava pensando, e isso...
 
GN⁺ 2025-04-18
Comentários do Hacker News

  • O S3FS é um sistema de arquivos de metadados escalável, comparado a vários sistemas de arquivos distribuídos

    • Inclui Collosus, Tectonic (Meta), ADLSv2 (Microsoft), HopsFS (Hopsworks) e PolarFS (Alibaba)
    • O S3FS usa FoundationDB, o Collosus usa BigTable, o Tectonic usa um KV store, e o HopsFS usa RonDB
    • Os pontos importantes do S3FS são: (1) suporte a cliente FUSE, o que facilita o uso, e (2) suporte a armazenamento NVMe, sem ficar limitado por I/O de disco
    • O HopsFS adiciona armazenamento em camadas, guardando dados recentes em NVMe e dados de arquivo no S3

  • Ao avaliar esses sistemas, é preciso considerar limites teóricos, eficiência e limitações práticas

    • Em teoria, sistemas de arquivos distribuídos paralelos como o Lustre podem escalar infinitamente
    • Para avaliar a eficiência, calcula-se quanto armazenamento e throughput é possível obter com nós com X TiB de disco
    • Em comparação com o FSx for Lustre, é possível operar o 3FS na AWS com custo 12–30% menor
    • Ainda fica a dúvida se é realmente possível montar o sistema de arquivos no tamanho de implantação que as pessoas querem
    • Faz sentido que a DeepSeek construa esses sistemas para obter internamente as propriedades que deseja
    • No Archil, espera-se encontrar configurações padrão melhores que a maioria das pessoas possa usar sem precisar gerenciar clusters enormes

  • Há interesse em uma comparação com o SeaweedFS

    • O SeaweedFS é usado para armazenar dados meteorológicos, com cerca de 3 PB de dados usados para treinamento de ML

  • Pergunta sobre por que não usar o CephFS

    • O CephFS foi amplamente testado em cenários do mundo real e demonstrou confiabilidade até em escala de petabytes
    • É uma solução open source, pode rodar no armazenamento NVMe mais rápido e alcançar IOPS muito altos com interconexões acima de 10 gigabits

  • Pergunta sobre comparação com o JuiceFS

    • Há planos de rodar o JuiceFS sobre o S3 Garage em um setup pessoal de homelab
    • O Garage suporta apenas replicação, não suporta erasure coding nem sharding
    • A escolha foi feita porque a configuração parece simples

  • Como operador de pequeno porte e usuário de homelab, provavelmente não haverá necessidade de usar um sistema de arquivos distribuído em larga escala

    • Há curiosidade sobre backup e recuperação ao lidar com dados em escala de petabytes

  • A configuração é complexa, mas não está claro quais recursos são essenciais para workloads de deep learning

    • Os recursos necessários são armazenamento em escala de petabytes, paralelismo de leitura/escrita e redundância
    • É difícil alcançar consistência, e ela não parece necessária aqui

  • Pergunta sobre quão fácil é desativar o sistema de arquivos distribuído da DeepSeek

    • Por exemplo, uma universidade dos EUA foi autorizada a usar a DeepSeek para pesquisa, mas precisa garantir que os dados não saiam do sistema de arquivos local do cluster de pesquisa

  • Pergunta se isso poderia ser replicado com discos ZFS distribuídos em vários dispositivos