Como lidar com o controle de versão de grandes quantidades de dados (binários)


46

Eu sou um estudante de doutorado em Geofísica e trabalho com grandes quantidades de dados de imagem (centenas de GB, dezenas de milhares de arquivos). Eu sei svne gitrazoavelmente bem e vem a valorizar a história do projeto, combinado com a capacidade de facilmente trabalhar juntos e ter proteção contra corrupção de disco. Também acho gitextremamente útil ter backups consistentes, mas sei que o git não pode lidar com grandes quantidades de dados binários com eficiência.

Nos meus estudos de mestrado, trabalhei em conjuntos de dados de tamanho semelhante (também imagens) e tive muitos problemas para acompanhar versões diferentes em diferentes servidores / dispositivos. Difundir 100 GB na rede realmente não é divertido e me custa muito tempo e esforço.

Sei que outros cientistas parecem ter problemas semelhantes, mas não consegui encontrar uma boa solução.

Eu quero usar as instalações de armazenamento do meu instituto, então preciso de algo que possa usar um servidor "burro". Também gostaria de ter um backup adicional em um disco rígido portátil, porque gostaria de evitar a transferência de centenas de GB pela rede sempre que possível. Portanto, preciso de uma ferramenta que possa lidar com mais de um local remoto.

Por fim, eu realmente preciso de algo que outro pesquisador possa usar, para que não precise ser super simples, mas que possa ser aprendido em algumas horas.

Avaliei várias soluções diferentes, mas nenhuma parece se encaixar na conta:

  • svn é um tanto ineficiente e precisa de um servidor inteligente
  • hg bigfile / largefile pode usar apenas um controle remoto
  • O git bigfile / media também pode usar apenas um controle remoto, mas também não é muito eficiente
  • sótão não parece ter um log, ou capacidades diferentes
  • O bup parece realmente bom, mas precisa de um servidor "inteligente" para funcionar

Eu tentei git-annex, o que faz tudo o que eu preciso fazer (e muito mais), mas é muito difícil de usar e não está bem documentado. Eu o uso há vários dias e não consigo entender o assunto, então duvido que qualquer outro colega se interesse.

Como os pesquisadores lidam com grandes conjuntos de dados e o que outros grupos de pesquisa estão usando?

Para ser claro, estou interessado principalmente em como outros pesquisadores lidam com essa situação, não apenas nesse conjunto de dados específico. Parece-me que quase todo mundo deveria ter esse problema, mas não conheço ninguém que o tenha resolvido. Devo apenas manter um backup dos dados originais e esquecer todas essas coisas de controle de versão? É isso que todo mundo está fazendo?


1
@scaaahu Eu não acho que isso seja necessariamente uma questão de software; uma resposta aceitável também pode descrever um fluxo de trabalho ou uma combinação de ferramentas e sistemas. (De qualquer forma, estar no tópico em outro lugar não deve jogar na decisão de fechar uma pergunta aqui.)

2
Apenas para proteger contra corrupção de dados com dados de imagem, periodicamente executo um script que recalcula um arquivo de soma de verificação com todos os arquivos e suas somas de verificação md5. O arquivo de soma de verificação é então mantido no git. Agora eu posso ver imediatamente com o git diff se alguma das somas de verificação mudou. E também posso ver quais arquivos foram removidos e adicionados. E se houver, por exemplo, algum sinal de corrupção de dados, posso usar os backups regulares para restaurar versões antigas. Não é perfeito, mas melhor que nada.

1
@JukkaSuomela Acho que é uma pergunta razoável quando você tem conjuntos de dados muito grandes, se esses conjuntos de dados mudam com frequência ... nesses casos, o backup geralmente é usado como controle de versão.

1
Estou votando para encerrar esta questão como fora de tópico, porque lida com dados / bancos de dados, e não com algo específico da academia. As perguntas são ótimas e (IMHO) deve ser movido para DataScience.SE ou (talvez) Databases.SE.
Piotr Migdal

1
O cientista @Johann Data tem diferentes origens. A minha está na mecânica quântica, por exemplo. O ponto principal aqui é o seguinte: 1. O StackExchange desencoraja as chamadas perguntas de barco e 2. é melhor obter as melhores práticas do que como é resolvido por pessoas que tiveram que resolvê-lo, mas não tinham idéia.
Piotr Migdal

Respostas:


12

O que estou acabando usando é uma espécie de solução híbrida:

  • backup dos dados brutos
  • git do fluxo de trabalho
  • instantâneos manuais do fluxo de trabalho + dados processados ​​que são relevantes, por exemplo:
    • pré-processamento padrão
    • realmente demorado
    • para publicação

Acredito que raramente é sensato ter um histórico de revisão completo de grande quantidade de dados binários, porque o tempo necessário para revisar as alterações será tão grande que acabará por não render a longo prazo. Talvez um procedimento de captura instantânea semi-automática (eventualmente para economizar espaço em disco, ao não replicar os dados inalterados em diferentes capturas instantâneas) seja útil.


Bem, estou usando find . -type f -print0 | xargs -0 md5sum > checksums.md5para calcular as somas de verificação e md5sum -c checksums.md5somas de verificação e controlar a versão das somas de verificação. Isso ajuda a verificar os dados em locais diferentes / em máquinas diferentes. Parece ser o melhor que podemos fazer no momento,
Johann

Se, ao modificar seus dados, você sempre alterar o nome do arquivo, poderá ser uma boa solução. Caso contrário, eu recomendo verificar os dados em si, por exemplo, com rsync(uma cópia) dos dados originais. Uma outra possibilidade comum em neurociência (embora eu não goste muito porque às vezes não é tão bem documentada quanto deveria) é usar o pacote python nipype, que pode ser visto como um (tipo de) fluxo de trabalho gerenciador e gerencia automaticamente o cache de dados binários das etapas intermediárias da análise.
Norok2

@ norok você descreveu uma grande estrutura geral. Implementamos algo semelhante na ferramenta DVC - dê uma olhada na minha resposta abaixo. Agradecemos o seu feedback.
Dmitry Petrov

9

Eu lidei com problemas semelhantes com conjuntos de dados de biologia sintética muito grandes, nos quais temos muitos GB de dados de citometria de fluxo espalhados por muitos, muitos milhares de arquivos, e precisamos mantê-los consistentemente entre grupos colaboradores em (várias) instituições diferentes.

O controle de versão típico como svn e git não é prático para essa circunstância, porque simplesmente não foi projetado para esse tipo de conjunto de dados. Em vez disso, passamos a usar soluções de "armazenamento em nuvem", particularmente DropBox e Bittorrent Sync. O DropBox tem a vantagem de realizar pelo menos algum registro primitivo e controle de versão e gerenciar os servidores para você, mas a desvantagem de ser um serviço comercial, você deve pagar pelo armazenamento grande e colocar seus dados não publicados em um armazenamento comercial; você não precisa pagar muito, portanto, é uma opção viável. O Bittorrent Sync tem uma interface muito semelhante, mas você o executa em seus próprios servidores de armazenamento e ele não tem controle de versão. Ambos machucam minha alma de programador, mas são as melhores soluções que meus colaboradores e eu encontramos até agora.


Existe uma versão popular de código aberto do Dropbox, OwnCloud. Eu ainda não tentei.



6

Não controlamos a versão dos arquivos de dados reais. Não gostaríamos, mesmo que o armazenássemos como CSV, e não em formato binário. Como Riccardo M. disse, não vamos gastar nosso tempo revisando alterações linha por linha em um conjunto de dados de 10 milhões de linhas.

Em vez disso, juntamente com o código de processamento, eu controlo a versão dos metadados:

  • Modificação de data
  • Tamanho do arquivo
  • Contagem de linhas
  • Nomes de colunas

Isso me fornece informações suficientes para saber se um arquivo de dados foi alterado e uma idéia do que foi alterado (por exemplo, linhas adicionadas / excluídas, colunas novas / renomeadas), sem forçar o VCS.


5

Este é um problema bastante comum. Tive essa dor quando fiz projetos de pesquisa para uma universidade e agora - em projetos industriais de ciência de dados.

Eu criei e liberei recentemente uma ferramenta de código aberto para resolver esse problema - DVC .

Basicamente, combina seu código no Git e os dados no disco ou nas nuvens locais (armazenamento S3 e GCP). O DVC rastreia a dependência entre dados e código e cria o gráfico de dependência (DAG). Isso ajuda você a tornar seu projeto reproduzível.

O projeto DVC pode ser facilmente compartilhado - sincronize seus dados com uma nuvem (comando dvc sync), compartilhe seu repositório Git e forneça acesso ao seu bloco de dados na nuvem.

"aprendível em poucas horas" - é um bom ponto. Você não deve ter nenhum problema com o DVC se estiver familiarizado com o Git. Você realmente precisa aprender apenas três comandos:

  1. dvc init- como git init. Deve ser feito em um repositório Git existente.
  2. dvc import- importe seus arquivos de dados (fontes). Arquivo ou URL local.
  3. dvc run- etapas do seu fluxo de trabalho como dvc run python mycode.py data/input.jpg data/output.csv. O DVC obtém a dependência entre as etapas automaticamente, cria o DAG e o mantém no Git.
  4. dvc repro- reproduza seu arquivo de dados. Exemplo: vi mycode.py- altere o código e, em seguida dvc repro data/output.csv, reproduzirá o arquivo (e todas as dependências.

Você precisa aprender mais alguns comandos DVC para compartilhar dados através da nuvem e habilidades básicas de S3 ou GCP.

O tutorial do DVC é o melhor ponto de partida - "Controle de versão de dados: aprendizado de máquina iterativo"


1
Isso pode ser usado apenas com o armazenamento de arquivos binários grandes (principalmente vídeos). ML não é o objetivo. O objetivo é ter um repositório para armazenar arquivos binários grandes. O repositório deve ter cache, checkout / pull seletivo (como forforce) e mecanismo de bloqueio de arquivo / diretório. É adequado para esse fim?
hemu 28/05

1
@hemu Sim. O DVC funciona bem para o cenário básico de arquivos grandes de dados sem recursos de ML (como pipelines e reprodutibilidade de ML). A semântica de bloqueio forçado não é suportada devido à semântica do Git. Em vez disso, use check-out por arquivo.
Dmitry Petrov


0

Você pode dar uma olhada no meu projeto chamado DOT: Gerenciador de repositórios do Distrubuted Object Tracker.
É um VCS muito simples para arquivos binários para uso pessoal (sem colaboração).
Ele usa SHA1 para soma de verificação e desduplicação de bloco. Sincronização P2P completa.
Um recurso exclusivo: servidor TCP ad-hoc único para pull / push.
Também pode usar SSH para transporte.

Ainda não foi lançado, mas pode ser um bom ponto de partida.
http://borg.uu3.net/cgit/cgit.cgi/dot/about/


0

Você pode tentar usar o hangar . É um player relativamente novo para o mundo do controle de versão de dados, mas faz um trabalho muito bom testando os tensores em vez de controlar o blob. A documentação deve ser o melhor lugar para começar. Como os dados estão sendo armazenados como tensores, você poderá usá-los diretamente dentro do seu código ML (além do hangar, agora há carregadores de dados para PyTorch e Tensorflow). Com o hangar, você pode obter todos os benefícios do git, como ramificação de custo zero, fusão e viagens no tempo através da história. Um recurso interessante sobre a clonagem no hangar é que você pode fazer clonagem parcial . O que significa que, se você tiver 10 TB de dados em seu controle remoto e precisar apenas de 100 MB para criar um protótipo de modelo, poderá buscar apenas 100 MB por meio de clonagem parcial, em vez de um clone completo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.