Procedencia y versionado para conjuntos de datos pequeños

Objetivo

Hacer que cada conjunto de datos usado en un informe responda a tres preguntas: de dónde proviene, qué se le hizo y qué versión exacta produjo esta cifra.

Requisitos previos

Un repositorio para el código, una ubicación de almacenamiento para los archivos demasiado grandes para él, y la regla de que los datos en bruto nunca se editan en el lugar. El modelo de datos PROV del W3C aporta el vocabulario: entidades (archivos, tablas), actividades (la ejecución de un script de limpieza), agentes (una persona o un programa) y relaciones como wasGeneratedBy, used, wasAttributedTo y wasDerivedFrom.

Pasos

1. Mantener los datos en bruto inmutables en un directorio o bucket raw/; nombrar los archivos con el origen y la fecha de obtención, y registrar el origen exacto (URL, consulta, ajustes de exportación, quién los proporcionó) en un README junto a ellos.
2. Calcular y almacenar una suma de verificación para cada archivo en bruto; las referencias posteriores citan la suma de verificación, no solo el nombre.
3. Derivar, nunca sobrescribir: cada transformación es un script que lee una versión y escribe un archivo nuevo; el script y sus parámetros son la procedencia de la salida.
4. Versionar los datos junto con el código. Los archivos que caben se confirman directamente; para los archivos más grandes, se confirma un puntero. La guía de introducción de DVC muestra que dvc add data/data.xml produce un pequeño archivo .dvc con el hash del archivo, que Git rastrea mientras el contenido va a una caché y a un remoto configurado. Git LFS funciona con el mismo principio: la página del proyecto describe cómo sustituye los archivos grandes por punteros de texto dentro de Git mientras el contenido reside en un servidor remoto.
5. Describir el paquete: un descriptor datapackage.json que sigue el estándar Data Package enumera los recursos con sus rutas y licencias y, para los archivos tabulares, un Table Schema (nombres de campo, tipos, restricciones, valores ausentes), de modo que las herramientas puedan validar los archivos y quien los lea sepa qué significa cada columna.
6. Etiquetar el estado usado por un informe: una etiqueta de Git o un hash de commit que cubra el código y los punteros de datos; incluir ese identificador en el informe.
7. Escribir una breve nota de procedencia por cada archivo derivado en términos de PROV, por ejemplo clean.csv wasDerivedFrom raw/export-2026-09-01.csv; wasGeneratedBy clean.py@abc123; wasAttributedTo <agent>. Basta con prosa; el vocabulario la mantiene consistente entre proyectos.

Resultado esperado

Cualquier cifra de un informe se resuelve en un commit, una suma de verificación de los datos y un script; una exportación en bruto corregida produce una versión nueva en lugar de una edición imposible de rastrear.

Límites y base de verificación

Los datos personales y las licencias limitan lo que puede almacenarse y compartirse; los registros de procedencia no deben convertirse en una copia de datos restringidos. Las actualizaciones muy frecuentes (flujos continuos) necesitan una base de datos con historial de auditoría en lugar de archivos. El flujo de trabajo sigue las especificaciones y la documentación citadas; no se afirma ninguna medición de su costo.