Sistema de versionamento de dados

• Data Version Control é um conjunto de ferramentas baseado em um modelo semelhante ao Git para gerenciar dados como código, permitindo que equipes de dados, AI/ML e ciência de dados apliquem práticas de engenharia de software
• Para infraestrutura de AI/ML e dados em grande escala, o lakeFS é a opção voltada a lidar com armazenamentos de objetos multimodais e data lakes em escala de petabytes em ambientes complexos de operações de AI e big data
• Para projetos menores de ciência de dados, a extensão Git DVC é direcionada a permitir que cientistas de dados individuais incorporem o versionamento de dados ao fluxo de trabalho com baixa sobrecarga
• O DVC é oferecido como open source gratuito e também conta com a extensão DVC for VS Code; o repositório no GitHub exibe 15.713 estrelas
• Com a entrada da comunidade DVC na família lakeFS, é possível consultar separadamente a divisão de papéis entre lakeFS e DVC e as FAQs relacionadas

---

O papel do Data Version Control

• Data Version Control tem como objetivo “gerenciar dados da mesma forma que se gerencia código”
• Por meio de um modelo semelhante ao Git, sua estrutura ajuda equipes de dados, AI/ML e ciência de dados a aproveitar boas práticas de engenharia de software
• Os casos de uso se dividem em dois grandes grupos
  • Equipes de AI/ML e infraestrutura de dados
  • Fluxos de trabalho locais e pequenos projetos de ciência de dados

Público-alvo por produto e caminhos para começar

• lakeFS é uma infraestrutura de versionamento de dados para equipes corporativas de AI e engenharia de dados
  • É voltado a operações complexas de AI e ambientes de big data
  • Lida com armazenamentos de objetos multimodais e data lakes em escala de petabytes
  • Como links iniciais, são oferecidos Get started with lakeFS e Book a Demo
• DVC é uma extensão do Git para cientistas de dados individuais
  • Tem como objetivo oferecer versionamento de dados fácil para pequenos projetos de ciência de dados
  • Pode ser aplicado a fluxos de trabalho de ciência de dados com sobrecarga mínima
  • O link para começar é Get started with DVC
• Também é possível usá-lo no VS Code por meio da extensão DVC for VS Code
• A comunidade DVC entrou para a família lakeFS, com informações relacionadas em lakeFS and DVC e FAQs
• O repositório GitHub do DVC é treeverse/dvc, e a página exibe 15.713 estrelas

[GN⁺]

Opiniões no Hacker News

• Usei DVC na maioria dos projetos nos últimos 5 anos, e a vantagem é que ele funciona como o Git
  Se os cientistas entendem branches, commits e diffs, conseguem entender o DVC também. A desvantagem também é que ele funciona como o Git, porque, na prática, muitos cientistas não entendem ou não usam bem branches, commits e diffs. O melhor ponto é que ele praticamente força a seguir Ten Simple Rules for Reproducible Computational Research. Nas equipes em que trabalhei, reprodutibilidade era um grande desafio

  • Senti algo parecido, e a resistência a aprender Git é bem grande, o que até dá para entender em certa medida
    Pesquisadores sabem o que é Git e que ele tem valor, mas acham que leva tempo demais para aprender e querem avançar logo. Para esses pesquisadores, comecei a criar uma ferramenta chamada Calkit(https://github.com/calkit/calkit) para simplificar e integrar Git e DVC. Quero convencê-los de que trabalhar de forma reprodutível é mais rápido no longo prazo e, no fim, permite usar o trabalho de maneira mais direta para acelerar o avanço de toda a área

• Sou mantenedor e autor do DVC, e fico feliz em ver o DVC na primeira página
  Posso responder a perguntas sobre o DVC e o projeto irmão DataChain https://github.com/iterative/datachain. O DataChain é uma ferramenta de versionamento de dados com pressupostos um pouco diferentes, sem cópia de arquivos e com transformações de dados embutidas

  • Fico curioso sobre qual é a diferença entre DVC e Git puro se os arquivos de dados forem todos arquivos de texto
  • Trabalho principalmente como consultor em engenharia de dados e não sou especialista em MLOps, mas tenho interesse nessa área
    Temos 10 anos de arquivos Parquet vindos de mais de 300 tópicos Kafka e estamos migrando agora para Apache Iceberg. Pretendemos fazer backfill só quando necessário, e seria bom poder rastrear esse processo com Git. Fico curioso se isso se encaixa bem nesse uso. Outra possibilidade é rastrear mudanças de schema de uma forma melhor do que fazemos hoje. Estou nessa área há mais de 20 anos e acho que anything-as-code combina bem com dados

• Fico feliz em ver o DVC sendo discutido aqui
  Como ferramenta, ele simplificou muito o versionamento de dados e modelos e foi um grande ponto de virada para muita gente na área de MLOps. É uma abordagem inteligente, em especial por armazenar arquivos grandes em qualquer object storage, vinculando-os diretamente ao repositório Git, sem um servidor de aplicação separado como o git-lfs nem reescritas do Git. No DagsHub https://dagshub.com, há muito tempo temos integração direta com o DVC, permitindo que equipes façam visualização e rotulagem de datasets, gestão de modelos, execução colaborativa de experimentos e rastreamento de código, dados e modelos em um só lugar. Se você já usa ou está considerando o DVC, também há a opção de usá-lo como parte de uma toolchain mais próxima de ponta a ponta

• Fico curioso sobre como ele se compara ao Oxen
  https://github.com/Oxen-AI/Oxen

  • Sou mantenedor do Oxen, e o motivo inicial para criá-lo foi que o DVC era bem lento e tinha muitas funcionalidades de que não precisávamos
    Internamente, otimizamos a estrutura de árvore de Merkle, o algoritmo de hash, o protocolo de rede etc. para torná-lo rápido mesmo com datasets grandes. Em https://oxen.ai, também há um frontend bem decente para visualizar e consultar dados
  • Se desse para usar isso junto com o GitHub, acho que eu migraria do DVC imediatamente
  • Nunca tinha ouvido falar do Oxen, mas parece uma alternativa muito interessante, e gostaria de ouvir alguém que tenha usado os dois
    Minha primeira impressão é que o DVC foi feito para ser usado junto com o Git, com o DVC gerenciando pastas arbitrárias dentro de um repositório Git, enquanto o Oxen parece mais uma alternativa de repositório de dados separado. Além disso, o Oxen tem muitas integrações com dataframes, dados tabulares e dados de treinamento/inferência de IA, preenchendo lacunas que o DVC não cobre. Por outro lado, o DVC integra um motor completo de pipelines DAG, importação/exportação e backends substituíveis

• Não consigo visualizar muito bem como isso interage com os dados
  Se eu armazeno tabelas Delta no ADLS e não posso trazer dados de produção para a máquina local, fico na dúvida se ainda dá para usar. Também me pergunto se faz sentido usar DVC quando basta olhar o log do Delta para alternar para versões anteriores

  • Pelo jeito que uso, o DVC é parecido com git LFS com suporte a vários backends, e também pode ser visto como um git-annex mais simples
    Além disso, há funcionalidades mais específicas de MLOps. É prático para versionar o treinamento de modelos em que os dados em cima do S3 mudam

• Nós também avaliamos o DVC, mas, para certos casos de uso, o paradigma do Git não foi muito útil
  Eram arquivos de vídeo enormes que quase não mudavam, e precisávamos de uma cópia dos dados na origem e de mais uma cópia em cada sistema que executava o treinamento. No fim, fomos para arquivos e pastas em um NAS, e isso funcionou bem o suficiente. Parece possível um modelo híbrido em que só os metadados do dataset sejam gerenciados e versionados pelo DVC. Mas isso foi há alguns anos, e fico curioso se hoje existem mais soluções de versionamento de dados on-premises. Da última vez que procurei, a maioria parecia ser orientada à nuvem

• Fico curioso sobre quais seriam as vantagens do DVC em comparação com o Apache Iceberg
  Se alguém já usou os dois, gostaria de ouvir sua opinião

  • Se essa é a sua dúvida, você também deveria olhar o Icechunk, que foi tornado open source esta semana
    É parecido com o Apache Iceberg, mas é uma ferramenta para dados multidimensionais como Zarr. https://earthmover.io/blog/icechunk e https://news.ycombinator.com/item?id=41850352
  • Não vejo uma vantagem clara; parece usar uma ferramenta já conhecida em um lugar onde ela não se encaixa
    Talvez o Iceberg seja mais adequado para modelos que mudam mais devagar do que esse método
  • Minha cabeça ainda não está muito organizada, mas, tentando explicar, um bom exemplo de dados blob aqui seria um conjunto de arquivos de vídeo 1080p bem longos
    Em resumo, faz sentido colocar dados blob não estruturados no DVC e dados estruturados no Iceberg. O ponto em que o DVC é melhor que o Iceberg é que você não precisa forçar dados blob para dentro de um formato tabular e pode evitar as etapas incômodas de processamento que vêm junto com isso. Na prática, também não precisa rodar uma etapa de processamento para extrair os dados blob de arquivos Parquet; basta baixar cada arquivo como ele é com um comando como dvc pull. Depois de modificar os arquivos localmente, dá para fazer commit com algo em torno de três comandos, e também não é necessário um pipeline de ingestão de dados para forçar os blobs para dentro de uma tabela. Como não há schema algum, basta colocar no repositório e fazer commit sem se preocupar com tipos. É possível fazer rollback acompanhando todo o histórico de commits, não apenas até o último vacuum/checkpoint. Forçar dados blob para dentro de formatos de dados tabulares é quase uma receita de sofrimento, e colocar blobs em um repositório estilo Git é muito mais rápido e fácil. Isso vale especialmente quando você precisa de todo o histórico de versões ou de branches para resultados diferentes; aplicar filtros ffmpeg diferentes por branch a arquivos de vídeo 1080p longos e depois permitir que as pessoas acessem todos os resultados e o histórico seria um pesadelo no Iceberg, mas é fácil no DVC. No fim, como tudo fica versionado, é como criar um data lake que não vira um pântano de dados

• Tive muitos problemas ao usar com um dataset formado por muitos arquivos jpg
  A indexação que verificava todos os arquivos a cada dvc status levava vários minutos, e o cache também não funcionava. Infelizmente, tive que desistir

  • Sim, o desempenho é bem ruim, e o cache pode causar muita dor de cabeça
    Isso é especialmente verdade se você usa um sistema de arquivos que não suporta reflink. Para datasets grandes em shards, como WebDataset, outras soluções são melhores, principalmente se o pipeline de machine learning puder fazer streaming diretamente do armazenamento de objetos

• Também ouvi falar do lakeFS como ferramenta de versionamento de dados sobre armazenamento de objetos S3
  Fico curioso se o DVC consegue competir nesse espaço