Data Versioning

Data versioning tracks changes to training datasets over time — the same reproducibility problem model versioning solves for trained artifacts, applied to the data those models are trained on.

Why Data Versioning Is Genuinely Different From Code Versioning

Git works well for code because code files are small and text-based. Training datasets are often large (gigabytes), frequently binary, and change in ways plain Git handles poorly — storing every full version of a large dataset directly in a Git repository quickly becomes impractical. Data versioning tools solve this specific problem: track changes and enable reproducibility, without bloating a code repository with huge binary files.

DVC (Data Version Control) — The Standard Tool

# DVC tracks large data files OUTSIDE git, while storing a small
# pointer/metadata file INSIDE git -- the best of both worlds
dvc init
dvc add data/training_data.csv        # creates training_data.csv.dvc (a small pointer file)
git add data/training_data.csv.dvc .gitignore
git commit -m "Track training data v1 with DVC"

# Data itself is pushed to a separate remote storage (S3, GCS, etc.)
dvc remote add -d storage s3://my-bucket/dvc-storage
dvc push

The actual large data file lives in remote storage (S3, Google Cloud Storage, etc.); Git only tracks the small .dvc pointer file, which records a hash of the data's exact contents — giving Git-style version history without storing huge binaries directly in the repository.

Reproducing an Exact Past Dataset Version

# Roll back code AND data together to a specific past state
git checkout v1.2.0        # roll back the code + .dvc pointer files
dvc checkout                # pull the EXACT data version that pointer refers to

# Now training with this exact code + exact data reproduces the original run precisely

This is the core payoff: checking out an old code commit alongside its matching DVC-tracked data pointer reconstructs the exact training conditions from that point in time — essential for debugging a past model or satisfying an audit requirement.

Simpler Alternative — Content-Hash-Based Manual Versioning

import hashlib

def hash_dataset(filepath):
    with open(filepath, "rb") as f:
        return hashlib.sha256(f.read()).hexdigest()

data_hash = hash_dataset("data/training_data.csv")
print(f"Dataset version identifier: {data_hash[:12]}")
# Record this hash alongside the model's metadata --
# a lightweight way to prove EXACTLY which data version trained a given model

Practical Use Cases

• Reproducing a past training run exactly, for debugging or auditing
• Tracking how a dataset evolves as new data arrives over time, without losing the ability to reference earlier snapshots

Common Mistakes

• Storing large datasets directly in a Git repository — this bloats repo size and makes cloning painfully slow; use a dedicated tool like DVC instead.
• Versioning the model without also versioning the exact data it was trained on, leaving an incomplete reproducibility record.

Interview Relevance

Q: "Why can't you just use Git directly to version large training datasets?" Git is optimized for small, text-based files with line-by-line diffs — large binary datasets bloat the repository, slow down every clone and checkout, and don't diff meaningfully; tools like DVC keep a small pointer file in Git while storing the actual large data in separate, purpose-built remote storage.

Practice Question

A bug is discovered in a production model. Explain, step by step, how data versioning combined with model versioning would let you reproduce the exact conditions that produced the buggy model.

Related ML Notes

• Model Versioning
• Experiment Tracking
• Data Preprocessing