Flujos de trabajo de reproducibilidad más allá de los contenedores: versionado de datos y seguimiento de procedencia

Comida clave

• Los contenedores resuelven un problema. Congelan el entorno del software, pero no rastrean qué cambió en sus datos o cómo evolucionó su análisis.
• El control de versiones de datos agrega una capa faltante. Herramientas como DVC y Datalad brindan control de versiones de estilo Git a conjuntos de datos, lo que facilita la reproducción de resultados con entradas exactas, archivos de parámetros y salidas seleccionadas.
• La procedencia es la pista de auditoría. Registra cada transformación que le sucedió a sus datos, desde archivos RAW hasta cifras finales.
• Los contenedores, el control de versiones de datos y el seguimiento de procedencias son complementarios. Juntos, cubren el código, el entorno, los datos y el linaje.

Qué saber primero

Los contenedores como Docker y Singularity se han convertido en una parte casi obligatoria de la investigación reproducible. Resuelven un problema real: si le envías a alguien una imagen de Docker, esa persona debería poder ejecutar el código y obtener los mismos resultados en otra máquina.

Esta es la razón por la cual las revistas y los revisores piden cada vez más imágenes de contenedores junto con papeles. Pero los contenedores dejan dos brechas críticas abiertas.

Primero, los contenedores no rastrean los cambios en sus datos. Un conjunto de datos evoluciona con el tiempo a medida que lo limpia, filtra y reprocesa. Cuando reproduce un resultado seis meses después, necesita saber qué versión de los datos produjo esa cifra. Los contenedores no registran eso por defecto.

En segundo lugar, los contenedores no capturan el linaje. Si un script de análisis es incorrecto, un parámetro se modificó accidentalmente o se aplicó un paso de preprocesamiento de manera inconsistente, es posible que no haya un registro automatizado de lo que sucedió. Se queda confiando en la memoria, las notas manuales o la suerte.

Este artículo explica cómo los flujos de trabajo científicos modernos abordan esas brechas a través del control de versiones de datos y el seguimiento de procedencias. El versionado de datos rastrea los cambios del conjunto de datos a lo largo del tiempo. El seguimiento de procedencia registra cada transformación aplicada a los datos.

Los contenedores no son suficientes

Antes de discutir la versión de datos, ayuda a comprender qué hacen y qué no hacen los contenedores.

Un contenedor captura:

• El sistema operativo, generalmente una distribución de Linux.
• Paquetes instalados y sus versiones.
• su código y archivos de configuración.
• El comando utilizado para ejecutar el análisis.

Un contenedor no captura automáticamente:

• Los archivos exactos utilizados como entradas, a menos que se incorporen a la imagen.
• Parámetros de tiempo de ejecución, a menos que se registren explícitamente.
• Salidas intermedias generadas durante una tubería.
• El orden y la lógica de las transformaciones aplicadas a los datos.

La consecuencia práctica es simple. Puede ejecutar un contenedor en otra máquina y obtener la misma salida solo si también se controlan las entradas y el contexto de ejecución. Si desea reproducir un análisis específico de hace meses, especialmente uno con varios pasos y un conjunto de datos cambiante, necesita más que un contenedor.

Considere un escenario común. Entrena una simulación de campo de fase en imágenes de microestructuras experimentales. Las imágenes se limpian durante el preprocesamiento y luego se dividen en conjuntos de capacitación y validación. Seis meses después, alguien te pide que reproduzcas la simulación.

Abre el contenedor, ejecuta el comando y obtiene el resultado incorrecto. La razón puede ser que el conjunto de datos se reorganizó, se agregaron nuevas muestras o que el punto de entrada usó cualquier archivo que sucediera en un directorio. Sin entradas versionadas y una pista de auditoría, el contenedor por sí solo no puede probar lo que sucedió.

Aquí es donde se hacen necesarios el control de versiones de datos y el seguimiento de procedencias.

¿Qué es la versión de datos?

El versionado de datos aporta la misma idea que hace que Git sea útil para el código en el mundo de los conjuntos de datos. En lugar de rastrear cada archivo binario grande directamente, crea instantáneas o punteros ligeros a estados de datos específicos en momentos específicos.

La idea central es simple:

1. Realiza un cambio en el conjunto de datos, como agregar archivos, modificar archivos o reorganizar carpetas.
2. Confirma una instantánea que registra qué cambió y dónde vive los datos actuales.
3. Más tarde, puede consultar esa instantánea para restaurar el estado de datos exacto que produjo un resultado específico.

Dos herramientas líderes en el ecosistema científico de Python son DVC y Datalad.

DVC: control de versión de datos

DVC es una herramienta de versión de datos ampliamente adoptada para los flujos de trabajo basados en Python. Funciona generando pequeños archivos de metadatos que rastrean ubicaciones de datos y sumas de verificación mientras los datos reales se encuentran en el almacenamiento remoto, como buckets de nube, discos locales o redes compartidas.

Varias características de DVC son importantes para los flujos de trabajo científicos:

• Definición de tubería. Los archivos dvc.yaml le permiten describir la canalización de análisis, incluidas las entradas, las salidas, los pasos de procesamiento y las dependencias.
• Seguimiento de experimentos. dvc exp run Crea espacios de nombres de experimentos aislados para que pueda probar configuraciones de parámetros sin abarrotar el historial de Git.
• Almacenamiento remoto. DVC puede enviar datos a controles remotos configurados como S3, almacenamiento de Google en la nube, servidores SSH o sistemas de archivos compartidos.
• Viaje en el tiempo. Puede consultar una confirmación de git, ejecutar dvc pull y dvc checkout, y restaurar el estado de los datos desde ese punto.

Un flujo de trabajo científico típico puede verse así:

# Initialize DVC in your project
dvc init

# Add your dataset
dvc add data/raw_microstructures/

# Commit only the lightweight metadata
git add data/raw_microstructures.dvc
git commit -m "Initial microstructure dataset"

# Define a processing pipeline
dvc run -d data/raw_microstructures.dvc -o data/cleaned/ 
    python src/preprocess.py

# Run experiments
dvc exp run --set-param preprocessing.threshold=0.5

drogadicto

Datalad está diseñado para conjuntos de datos científicos y utiliza Git-Annex bajo el capó. Es especialmente útil para grandes conjuntos de datos que pueden abarcar muchos archivos, como simulaciones, mediciones experimentales, datos de imágenes o colecciones de investigación institucional.

Datalad ofrece varias ventajas científicas específicas:

• Diseño centrado en datos. Datalad trata cada directorio como un conjunto de datos con historial versionado.
• Recuperación de datos bajo demanda. En lugar de tirar de todo, Datalad puede buscar archivos o subdirectorios específicos cuando sea necesario.
• Replicación incorporada. Datalad puede administrar repositorios de hermanos en todas las instituciones para obtener redundancia y cumplimiento.
• Integración HPC. Las extensiones pueden admitir sistemas de programación por lotes como SLURM y PBS.

Un flujo de trabajo básico de Datalad se ve así:

# Initialize a dataset
datalad create -s my-dataset

# Add data using git-annex under the hood
datalad add data/raw_images/

# Record a provenance-rich commit
datalad save -m "Add raw imaging data, batch 2024-01"

# Clone to another machine and fetch data on demand
datalad clone my-dataset
datalad get data/processed_results/

Cuándo usar cuál

El DVC suele ser mejor para los equipos que trabajan en entornos de ciencia de datos de Python que necesitan seguimiento de canalizaciones y gestión de experimentos. Se integra naturalmente con herramientas como scikit-learn, PyTorch y otros flujos de trabajo de Python.

Datalad suele ser mejor para los proyectos de curación de datos a largo plazo, especialmente cuando los conjuntos de datos son grandes, distribuidos entre instituciones o se espera que sobrevivan durante muchos años.

No son mutuamente excluyentes. Ambos usan Git como parte de su columna vertebral de control de versiones, y ambos se pueden combinar con entornos de ejecución en contenedores.

¿Qué es el seguimiento de procedencias?

La procedencia es el registro sistemático de dónde provienen los datos y qué sucedió. En los flujos de trabajo científicos, la procedencia responde a preguntas prácticas:

• ¿Qué versión de los datos de entrada se utilizó?
• ¿Qué parámetros se aplicaron durante el procesamiento?
• ¿Qué archivos intermedios se generaron?
• ¿Qué versiones de software estaban activas cuando se produjo la salida?
• ¿Quién ejecutó el flujo de trabajo y cuándo?

Dos tipos de procedencia importan en los flujos de trabajo científicos.

La procedencia prospectiva describe lo que sucederá. Es la especificación del flujo de trabajo planificado: la receta de cómo los datos deben moverse a través del análisis. Las herramientas como CWL y WDL usan formatos declarativos para especificar qué debe suceder cuando se ejecuta un flujo de trabajo.

La procedencia retrospectiva describe lo que realmente sucedió. Registra registros de ejecución, instantáneas de entorno, sumas de verificación de datos y archivos de tiempo de ejecución exactos. Esta es la pista de auditoría que respalda la reproducibilidad.

RO-Crate: artefactos de investigación de empaque con procedencia

RO-Crate es un estándar para los resultados de la investigación de empaquetado, archivos de datos, definiciones de flujo de trabajo, parámetros y registros en un archivo legible por máquina.

Un archivo RO-Crate suele ser un directorio o archivo zip que contiene:

• Archivos de datos y salidas de análisis.
• Un archivo ro-crate-metadata.json con metadatos JSON-LD.
• Definiciones de flujo de trabajo como CWL, NextFlow o SnakeMake archivos.
• Registros de ejecución y capturas de entorno.

Ro-Crate es útil porque es liviano y portátil. No necesita una base de datos o servicio especial para inspeccionarlo. Cualquier persona con los archivos puede leer los metadatos y comprender la procedencia.

El formato admite tanto la procedencia prospectiva, que describe lo que planea hacer el flujo de trabajo, como la procedencia retrospectiva, que registra lo que realmente se ejecutó.

RO-Crate está ganando fuerza en la computación científica. Las plataformas como Galaxy, WorkflowHub y Zenodo admiten las exportaciones de RO-Crate, por lo que es útil para los artefactos de investigación listos para la publicación.

Poniéndolo todo junto: un patrón de flujo de trabajo práctico

Los contenedores, el control de versiones de datos y el seguimiento de procedencia funcionan mejor cuando se usan juntos. Cada uno cubre una capa de reproducibilidad diferente.

Paso 1: Verifique sus datos con DVC o Datalad

Comience por versionando las entradas RAW. Use dvc add o datalad add para cada conjunto de datos que se introduce en el análisis. Confirme los archivos de metadatos de DVC o Git-Anex a Git junto con el código.

Paso 2: Defina su Pipeline

Si usa DVC, escriba un archivo dvc.yaml que describa cada paso de procesamiento como una etapa. Si usa Datalad, use scripts documentados, archivos de parámetros consistentes y repositorios de hermanos cuando sea necesario.

Paso 3: Contenedoriza la ejecución

Encuentre scripts de análisis en un contenedor que pueda ejecutarse en todas las máquinas. El contenedor mantiene consistentes los paquetes de Python, las bibliotecas C++ y los binarios. No reemplaza las entradas versionadas.

Paso 4: Captura la procedencia con RO-Crate o CWLPROV

Al final de cada ejecución de flujo de trabajo, el paquete de artefactos se convierte en un archivo RO-Crate. Esto te da:

• Un solo directorio o archivo zip que contiene datos, código, registros y metadatos.
• Procedencia legible por máquina vinculada a conjuntos de datos.
• Identificadores persistentes cuando se depositan en repositorios como Zenodo o FigShare.

El flujo de trabajo en la práctica

Your Project Directory
├── .git/                     # Code and metadata
├── .dvc/                     # DVC pipeline state
├── src/                      # Analysis scripts
├── data/                     # Versioned datasets
├── results/                  # Output data
├── dvc.yaml                  # Pipeline definition
├── params.yaml               # Parameter file
└── Dockerfile                # Container definition

Ejecutar el flujo de trabajo puede verse así:

# Restore exact data state
dvc checkout

# Run with pinned container
docker run -v $(pwd):/workspace my-analysis:1.2 python src/run.py

# Package results with provenance
ro-crate add data/results.csv params.yaml results/

Errores comunes

Estas son trampas comunes cuando los investigadores adoptan el control de versiones de datos y el seguimiento de procedencias.

1. Seguimiento de cada archivo intermedio

Versionar cada archivo intermedio suele ser innecesario y puede volverse dañino. Infla el almacenamiento y los metadatos sin mejorar la reproducibilidad.

Solo pista:

• Entradas RAW, que son los archivos adquiridos originales.
• Datos preprocesados, que es la versión curada que se usa realmente para el análisis.
• Archivos de salida final, como figuras, tablas y salidas de simulación publicadas.

No versione cada archivo CSV o Scratch temporal a menos que sea necesario reproducir el resultado final.

2. Olvidar los archivos de parámetros de la versión

Si los parámetros se pasan solo como argumentos de línea de comandos, es posible que no se puedan recuperar solo de Git. Los archivos de parámetros son tan importantes como los archivos de datos.

Verificarlos explícitamente:

dvc add configs/params.yaml
git add configs/params.yaml.dvc

3. Suponiendo que los contenedores resuelvan todo

Los contenedores son valiosos, pero son solo una capa. Un contenedor sin entradas versionadas y procedencia no es suficiente para demostrar cómo se produjo un resultado específico.

Piense en los contenedores como la capa de entorno. Todavía necesita versionado de datos para entradas y seguimiento de procedencia para el historial del flujo de trabajo.

4. Ignorar la configuración de almacenamiento remoto

DVC y Datalad funcionan mejor cuando el almacenamiento remoto se configura antes de tiempo. Sin controles remotos, los archivos de metadatos pueden apuntar a rutas locales que desaparecen cuando se mueve a un clúster oa un entorno de nube.

Configure los controles remotos al inicio del proyecto, no durante una crisis de fecha límite.

Elegir la herramienta adecuada para su proyecto

El panorama de herramientas es diverso. Utilice este marco de decisión como punto de partida.

También puedes combinar herramientas. Por ejemplo, use DVC para el control de versiones de datos, Docker for Environment Reproductibility y RO-Crate para empaquetar la ejecución final del flujo de trabajo para su publicación.

Qué hacer a continuación

Si está iniciando un nuevo proyecto, la ruta es sencilla:

1. Inicialice un repositorio de Git para el código.
2. Agregue DVC con dvc init y conjuntos de datos sin procesar de versión.
3. Escriba scripts de análisis como archivos de Python o scripts bash.
4. Container el flujo de trabajo con Docker o Singularity.
5. Resultados del paquete con RO-Crate en cada hito principal.

Si está trabajando en un proyecto existente, comience con poco:

1. Agregue DVC al repositorio y a los conjuntos de datos de clave de versión.
2. Escriba un archivo dvc.yaml que describa la canalización.
3. Containerizar el principal paso de ejecución.
4. Cree un archivo RO-Crate para obtener el resultado más importante.

Este enfoque incremental le permite agregar capas de reproducibilidad sin reescribir todo el proyecto.

Guías relacionadas

• Versionamiento e integridad en el software de investigación: una mirada más amplia al control de versiones, la reproducibilidad y la trazabilidad del flujo de trabajo para los equipos de software de investigación.
• depuración de python para código científico — Patrones de depuración que funcionan junto con flujos de trabajo reproducibles.

Este artículo cubre la versión de datos y el seguimiento de procedencias como herramientas prácticas para flujos de trabajo científicos reproducibles. DVC, Datalad y RO-Crate se mantienen activamente y se utilizan ampliamente en el ecosistema científico de Python. Para conocer los últimos detalles de configuración, consulte siempre la documentación oficial de cada herramienta.