Cómo lidiar con el control de versiones de grandes cantidades de datos (binarios)

Soy estudiante de doctorado en Geofísica y trabajo con grandes cantidades de datos de imágenes (cientos de GB, decenas de miles de archivos). Yo sé svny gitbastante bien y llegado a valorar la historia del proyecto, combinado con la capacidad de trabajar juntos fácilmente y tienen protección contra daños en el disco. gitTambién me parece extremadamente útil para tener copias de seguridad consistentes, pero sé que git no puede manejar grandes cantidades de datos binarios de manera eficiente.

En mis estudios de maestría trabajé en conjuntos de datos de tamaño similar (también imágenes) y tuve muchos problemas para rastrear diferentes versiones en diferentes servidores / dispositivos. Difundir 100GB en la red realmente no es divertido, y me costó mucho tiempo y esfuerzo.

Sé que otros en la ciencia parecen tener problemas similares, pero no pude encontrar una buena solución.

Quiero usar las instalaciones de almacenamiento de mi instituto, así que necesito algo que pueda usar un servidor "tonto". También me gustaría tener una copia de seguridad adicional en un disco duro portátil, porque me gustaría evitar transferir cientos de GB a través de la red siempre que sea posible. Entonces, necesito una herramienta que pueda manejar más de una ubicación remota.

Por último, realmente necesito algo que otro investigador pueda usar, por lo que no es necesario que sea súper simple, sino que se pueda aprender en unas pocas horas.

He evaluado muchas soluciones diferentes, pero ninguna parece encajar:

• svn es algo ineficiente y necesita un servidor inteligente
• hg bigfile / largefile solo puede usar un control remoto
• git bigfile / media también puede usar solo un control remoto, pero tampoco es muy eficiente
• el ático no parece tener un registro o capacidades diferentes
• bup se ve muy bien, pero necesita un servidor "inteligente" para funcionar

Lo intenté git-annex, lo que hace todo lo que necesito que haga (y mucho más), pero es muy difícil de usar y no está bien documentado. Lo he usado durante varios días y no pude entenderlo, así que dudo que algún otro compañero de trabajo esté interesado.

¿Cómo manejan los investigadores los grandes conjuntos de datos y qué utilizan otros grupos de investigación?

Para ser claros, estoy principalmente interesado en cómo otros investigadores abordan esta situación, no solo este conjunto de datos específico. Me parece que casi todos deberían tener este problema, pero no conozco a nadie que lo haya resuelto. ¿Debo mantener una copia de seguridad de los datos originales y olvidar todo este control de versiones? ¿Es eso lo que todos los demás están haciendo?

Lo que estoy terminando usando es una especie de solución híbrida:

• copia de seguridad de los datos sin procesar
• git del flujo de trabajo
• instantáneas manuales de flujo de trabajo + datos procesados, que son relevantes, por ejemplo:
  • preprocesamiento estándar
  • realmente consume mucho tiempo
  • para publicación

Creo que rara vez es sensato tener un historial de revisión completo de una gran cantidad de datos binarios, porque el tiempo requerido para revisar los cambios eventualmente será tan abrumador que a la larga no dará resultado. Tal vez un procedimiento de instantánea semiautomático (eventualmente para ahorrar algo de espacio en disco, al no replicar los datos sin cambios en diferentes instantáneas) sería de ayuda.

He tratado problemas similares con conjuntos de datos de biología sintética muy grandes, donde tenemos muchos, muchos GB de datos de citometría de flujo distribuidos en muchos, miles de archivos, y necesitamos mantenerlos consistentemente entre grupos colaboradores en (múltiples) instituciones diferentes.

El control de versiones típico como svn y git no es práctico para esta circunstancia, porque simplemente no está diseñado para este tipo de conjunto de datos. En cambio, hemos caído en el uso de soluciones de "almacenamiento en la nube", particularmente DropBox y Bittorrent Sync. DropBox tiene la ventaja de que hace al menos algunos registros primitivos y control de versiones y gestiona los servidores por usted, pero la desventaja de que es un servicio comercial, tiene que pagar por un gran almacenamiento, y está poniendo sus datos no publicados en un almacenamiento comercial; Sin embargo, no tiene que pagar mucho, por lo que es una opción viable. Bittorrent Sync tiene una interfaz muy similar, pero la ejecuta usted mismo en sus propios servidores de almacenamiento y no tiene ningún control de versión. Ambos hirieron mi alma de programador, pero son las mejores soluciones que mis colaboradores y yo hemos encontrado hasta ahora.

He usado el control de versiones en buckets de Amazon S3 para administrar 10-100GB en archivos 10-100. La transferencia puede ser lenta, por lo que ha ayudado a comprimir y transferir en paralelo, o simplemente ejecutar cálculos en EC2. La biblioteca boto proporciona una bonita interfaz de Python.

Intenta mirar Git Large File Storage (LFS) . Es nuevo, pero podría ser lo que vale la pena mirar.

Como veo, una discusión en Hacker News menciona algunas otras formas de lidiar con archivos grandes:

• git-annex (y, por ejemplo, usarlo con Amazon S3 )
• Extensión Mercurual Largefiles

No controlamos la versión de los archivos de datos reales. No quisiéramos incluso si lo almacenamos como CSV en lugar de en forma binaria. Como dijo Riccardo M. , no vamos a pasar nuestro tiempo revisando los cambios fila por fila en un conjunto de datos de 10M filas.

En cambio, junto con el código de procesamiento, controlo la versión de los metadatos:

• Fecha de modificación
• Tamaño del archivo
• Número de filas
• Nombres de columna

Esto me da suficiente información para saber si un archivo de datos ha cambiado y una idea de lo que ha cambiado (por ejemplo, filas agregadas / eliminadas, columnas nuevas / renombradas), sin estresar el VCS.

Este es un problema bastante común. Tuve este dolor cuando hice proyectos de investigación para una universidad y ahora, en proyectos de ciencia de datos industriales.

Creé y lancé recientemente una herramienta de código abierto para resolver este problema: DVC .

Básicamente combina su código en Git y datos en su disco local o nubes (almacenamiento S3 y GCP). DVC rastrea la dependencia entre datos y código y crea el gráfico de dependencia (DAG). Le ayuda a hacer que su proyecto sea reproducible.

El proyecto DVC podría compartirse fácilmente: sincronice sus datos en una nube (comando dvc sync), comparta su repositorio Git y brinde acceso a su depósito de datos en la nube.

"Aprender en unas pocas horas" - es un buen punto. No debería tener ningún problema con DVC si está familiarizado con Git. Realmente necesitas aprender solo tres comandos:

1. dvc init- como git init. Debe hacerse en un repositorio Git existente.
2. dvc import- Importa tus archivos de datos (fuentes). Archivo local o URL.
3. dvc run- pasos de su flujo de trabajo como dvc run python mycode.py data/input.jpg data/output.csv. DVC deriva la dependencia entre sus pasos automáticamente, crea DAG y lo mantiene en Git.
4. dvc repro- Reproduce tu archivo de datos. Ejemplo: vi mycode.py- cambie el código y luego dvc repro data/output.csvreproducirá el archivo (y todas las dependencias).

Debe aprender un par de comandos DVC más para compartir datos a través de la nube y las habilidades básicas S3 o GCP.

El tutorial de DVC es el mejor punto de partida: "Control de versión de datos: aprendizaje automático iterativo"

No los he usado pero hubo una discusión similar en un grupo financiero

sugerencias de software de repositorio de datos scidb , zfs, http://www.urbackup.org/

Puede echar un vistazo a mi proyecto llamado DOT: administrador de repositorios de Distrubuted Object Tracker.
Es un VCS muy simple para archivos binarios para uso personal (sin colaboración).
Utiliza SHA1 para la suma de comprobación y la deduplicación de bloque. Sincronización P2P completa.
Una característica única: servidor TCP ad hoc de una sola vez para pull / push.
También puede usar SSH para el transporte.

Todavía no se ha lanzado, pero podría ser un buen punto de partida.
http://borg.uu3.net/cgit/cgit.cgi/dot/about/

Puedes intentar usar el hangar . Es un jugador relativamente nuevo en el mundo del control de versiones de datos, pero hace un buen trabajo versionando los tensores en lugar de versionar el blob. La documentación debe ser el mejor lugar para comenzar. Dado que los datos se almacenan como tensores, debería poder usarlos directamente dentro de su código ML (además, el hangar ahora tiene cargadores de datos para PyTorch y Tensorflow). Con el hangar, puede obtener todos los beneficios de git, como la ramificación, la fusión y el viaje en el tiempo sin costo a través de la historia. Una buena característica de la clonación en el hangar es que podría hacer una clonación parcial . Lo que significa que si tiene 10 TB de datos en su control remoto y solo necesita 100 MB para crear prototipos de su modelo, puede obtener solo 100 MB mediante clonación parcial en lugar de un clon completo.