April’ 19 DVC❤️Heartbeat
Every month we are sharing here our news, findings, interesting reads, community takeaways, and everything along the way.
Some of those are related to our brainchild DVC and its journey. The others are a collection of exciting stories and ideas centered around ML best practices and workflow.
News and links
We have some exciting news to share this month!
DVC is going to Pycon 2019! It is the first conference that we attend as a team. When we say ‘team’ — we mean it. Our engineers are flying from all over the globe to get together offline and catch up with fellow Pythonistas.
The speaker pipeline is amazing! DVC creator Dmitry Petrov is giving a talk on Machine learning model and dataset versioning practices.
Stop by our booth at the Startup Row on Saturday, May 4, reach out and let us know that you are willing to chat, or simply find a person with a huge DVC owl on their shirt!
Speaking of the owls — DVC has done some rebranding recently and we love our new logo. Special thanks to 99designs.com for building a great platform for finding trusted designers.
DVC is moving fast (almost as fast as my two-year-old). We do our best to keep up and totally love all the buzz in our community channels lately!
Here is a number of interesting reads that caught our eye:
A great article about using DVC with a quite advanced scenario and docker. If you haven’t had a chance to try DVC.org yet — this is a great comprehensive read on why you should do so right away.
A short (only 8 minutes!) and inspiring talk by Alejandro Saucedo at FOSDEM. Alejandro covers the key trends in machine learning operations, as well as most recent open source tools and frameworks. Focused on reproducibility, monitoring and explainability, this lightning talk is a great snapshot of the current state of ML operations.
- Interview with Kaggle Grandmaster, Senior Computer Vision Engineer at Lyft: Dr. Vladimir I. Iglovikov by Sanyam Bhutani
There is no way you will become Kaggle Master and not learn how to approach anew, the unknown problem in a fast hacking way with a very high number of iterations per unit of time. This skill in the world of competitive learning is the question of survival
Discord gems:
There are lots of hidden gems in our Discord community discussions. Sometimes they are scattered all over the channels and hard to track down.
We are sifting through the issues and discussions and share with you the most interesting takeaways.
- It supports Windows, Mac, Linux. Python 2 and 3.
- No specific CPU or RAM requirements — it’s a lightweight command line tool and should be able run pretty much everywhere you can run Python.
- It depends on a few Python libraries that it installs as dependencies (they are specified in the `requirements.txt`).
- It does not depend on Git and theoretically could be run without any SCM. Running it on top of a Git repository however is recommended and gives you an ability to actually save history of datasets, models, etc (even though it does not put them into Git directly).
No server licenses for DVC. It is 100% free and open source.
- What is the storage limit when using DVC? I am trying to version control datasets and models with >10 GB (Potentially even bigger). Can DVC handle this?
There is no limit. None enforced by DVC itself. It depends on the size of your local or remote storages. You need to have some space available on S3, your SSH server or other storage you are using to keep these data files, models and their version, which you would like to store.
- How does DVC know the sequence of stages to run? How does it connect them? Does it see that there is a dependency which is outputted from the first run?
DVC figures out the pipeline by looking at the dependencies and outputs of the stages. For example, having the following:
you will end up with two stages: `download.dvc` and `duplicate.dvc`. The download one will have `joke.txt` as an output . The duplicate one defined `joke.txt` as a dependency, as it is the same file. DVC detects that and creates a pipeline by joining those stages.
You can inspect the content of each stage file here (they are human readable).
- Is it possible to use the same data of a remote in two different repositories? (e.g. in one repo `run dvc pull -r my_remote` to pull some data and running the same command in a different git repo should also pull the same)
Yes! It’s a frequent scenario for multiple repos to share remotes and even local cache. DVC file serves as a link to the actual data. If you add the same DVC file (e.g. `data.dvc`) to the new repo and do `dvc pull -r remotename data.dvc`- it will fetch data. You have to use `dvc remote add` first to specify the coordinates of the remote storage you would like to share in every project. Alternatively (check out the question below), you could use ` — global` to specify a single default remote (and/or cache dir) per machine.
Use ` — global` when you specify the remote settings. Then remote will be visible for all projects on the same machine. ` — global` — saves remote configuration to the global config (e.g. ~/.config/dvc/config) instead of a per project one — `.dvc/config`. See more details here.
We would recommend to skim through our get started tutorial, to summarize the data versioning process of DVC:
- You create stage (aka DVC) files by adding, importing files (dvc add / dvc import) , or run a command to generate files (dvc run — out file.csv “wget https://example.com/file.csv").
- This stage files are tracked by git
- You use git to retrieve previous stage files (e.g. git checkout v1.0)
- Then use dvc checkout to retrieve all the files related by those stage files
All your files (with each different version) are stored in a .dvc/cache directory, that you sync with a remote file storage (for example, S3) using the dvc push or dvc pull commands (analogous to a git push / git pull, but instead of syncing your .git, you are syncing your .dvc directory)
on a remote repository (let’s say an S3 bucket).
If you need to move your dvc file somewhere, it is pretty easy, even if done manually:
This is an expected behaviour. DVC saves files under the name created from their checksum in order to prevent duplication. If you delete “pushed” file in your project directory and perform `dvc pull`, dvc will take care of pulling the file and renaming it to “original” name.
Below are some details about how DVC’s cache works, just to illustrate the logic. When you add a data source:
It computes the (md5) checksum of the file and generates a DVC file with related information:
The original file is moved to the cache and a link or copy (depending on your filesystem) is created to replace it on your working space:
Absolutely! There are three ways you could interact with DVC:
1) Use subprocess to launch DVC;
2) Use from `dvc.main import main` and use it with regular CLI logic like `ret = main(‘add’, ‘foo’)`
3) Use our internal API (see `dvc/repo` and `dvc/command` in our source to get a grasp of it). It is not officially public yet, and we don’t have any special docs for it, but it is fairly stable and could definitely be used for a POC. We’ll add docs and all the official stuff for it in the not-so-distant future.
- Can I still track the linkage between data and model without using `dvc run` and a graph of tasks? Basically what would like extremely minimal DVC invasion into my GIT repo for an existing machine learning application?
There are two options:
1. Use `dvc add` to track models and/or input datasets. It should be enough if you use `git commit` on DVC files produced by `dvc add`. This is the very minimum you can get with DVC and it does not require using DVC run. Check the first part (up to the Pipelines/Add transformations section) of the DVC get started.
2. You could use ` — no-exec` in `dvc run` and then just `dvc commit` and `git commit` the results. That way you’ll get your DVC files with all the linkages, without having to actually run your commands through DVC.
If you have any questions, concerns or ideas, let us know here and our stellar team will get back to you in no time.
