213 points by shcheklein 4 days ago | 50 comments
bramathon 4 days ago
[1] https://journals.plos.org/ploscompbiol/article?id=10.1371/jo...
dmpetrov 4 days ago
Happy to answer any questions about DVC and our sister project DataChain https://github.com/iterative/datachain that does data versioning with a bit different assumptions: no file copy and built-in data transformations.
ajoseps 4 days ago
miki123211 4 days ago
It essentially makes sure that your results can reproducibly be generated from your original data. If any script or data file is changed, the parts of your pipeline that depend on it, possibly recursively, get re-run and the relevant results get updated automatically.
There's no chance of e.g. changing the structure of your original dataset slightly, forgetting to regenerate one of the intermediate models by accident, not noticing that the script to regenerate it doesn't work any more due to the new dataset structure, and then getting reminded a year later when moving to a new computer and trying to regen everything from scratch.
It's a lot like Unix make, but with the ability to keep track of different git branches and the data / intermediates they need, which saves you from needing to regen everything every time you make a new checkout, lets you easily exchange large datasets with teammates etc.
In theory, you could store everything in git, but then every time you made a small change to your scripts that e.g. changed the way some model works and slightly adjusted a score for each of ten million rows, your diff would be 10m LOC, and all versions of that dataset would be stored in your repo, forever, making it unbelievably large.
amelius 3 days ago
Not everybody wants a framework.
JadeNB 3 days ago
> Not everybody wants a framework.
The second part of this comment seems strange to me. Surely nothing on Hacker News is shared with the expectation that it will be interesting, or useful, to everyone. Equally, surely there are some people on HN who will be interested in a framework, even if it might be too heavy for other people.
amelius 3 days ago
stochastastic 3 days ago
woodglyst 3 days ago
azinman2 4 days ago
thangngoc89 4 days ago
[0] https://dvc.org/doc/user-guide/data-management/remote-storag...
dmpetrov 4 days ago
1. File are too large for Git and Git LFS.
2. You prefer using S3/GCS/Azure as a storage.
3. You need to track transformations/piplines on the file - clean up text file, train mode, etc.
Otherwise, vanilla Git may be sufficient.
agile-gift0262 4 days ago
johanneskanybal 3 days ago
Another potential aspect would be tracking schema evolution in a nicer way than we currently do.
thx in advance, huge fan of anything-as-code and think it’s a great fit for data (20+ years in this area).
stochastastic 3 days ago
Is there any support that would be helpful? I’ll look at the project page too.
dmpetrov 3 days ago
Just shoot an email to support and mention HN. I’ll read and reply.
dpleban 3 days ago
Specifically, it's a genius way to store large files in git repos directly on any object storage without custom application servers like git-lfs or rewriting git from scratch...
At DagsHub [0], we've integrated directly with DVC for a looong time, so teams can use it with added features like visualizing and labeling datasets managing and models, running experiments collaboratively, and tracking everything (code, data, models, etc.) all in one place.
Just wanted to share that for those already using or considering DVC—there are some options to use it as a building block in a more end-to-end toolchain.
jiangplus 4 days ago
gregschoeninger 3 days ago
Happy to answer any thoughts or questions!
bagavi 3 days ago
jFriedensreich 3 days ago
my first impression: dvc is made to use with git where there are arbitrary folders handled by dvc INSIDE your git repo, where oxen is an alternative for a separate data repo. also oxen has lots of integration with dataframes and tabular, ai training and infernece data that dvc is missing. on the other hand dvc has a full DAG pipeline engine integrated as well as import/ export and pluggable backends.