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

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?

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.

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.

Usei o controle de versão nos buckets do Amazon S3 para gerenciar 10 a 100 GB em 10 a 100 arquivos. A transferência pode ser lenta, por isso ajudou a compactar e transferir em paralelo ou apenas executar cálculos no EC2. A biblioteca boto fornece uma boa interface python.

Tente olhar para o Git Large File Storage (LFS) . É novo, mas pode ser a coisa que vale a pena olhar.

A meu ver, uma discussão sobre o Hacker News menciona algumas outras maneiras de lidar com arquivos grandes:

• anexo git (e, por exemplo, usá-lo com o Amazon S3 )
• Extensão Mercurual Largefiles

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.

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"

Eu não os usei, mas houve uma discussão semelhante em um grupo financeiro

sugestões de software para repositório de dados scidb , zfs, http://www.urbackup.org/

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/

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.