Hacker News Reader

Comment by iamwil | Hacker News Reader

How many data scientists are interested in deploying their own models? And how many of you would learn docker in order to do so?

View on HN

There is a strong overlap between data science and devops, which is something not often discussed in all the data science/machine learning MOOCs.

I agree this is a big gap in the curricula; "engineering chops" (managing servers, environments, etc.) is what I've seen be the biggest force multiplier for data scientists (esp. at non-huge orgs), not how good at stats they are or how fancy a model they can build.

Which orgs have you seen this as the biggest force multiplier?

From the sibling comments in this thread, it seems like there are some agree, and others don't. I was curious if there's a segment that does, and who they might be.

Biased sample for sure, but me and my friends/colleagues in the midwest at companies with DS teams of <10 people, often <5. Companies/teams far too small to separate the builders from the shippers.

I also practice data science from a more engineering angle than many which further colors my opinions. Building models is fun, but I also enjoy deployment and maintenance, so I don't _want_ to hand that part off.

At my last job, my (Data Science) team all deployed production code including our models. We were using Scala, which made it fairly easy since we could essentially just build fat JARs and upload them.

In contrast, I've found trying to do the same thing with Python nightmarish - simple things like having Pandas .20 on one machine and .21 on another will result in silent changes in how some metrics are calculated.

Anaconda mostly, but not entirely, solves that problem with its superior environment management (significantly better than pip IME.) But given that it's imperfect, I'll probably look more into Docker soon.

How did you manage the dependency versioning problem? Did you set up automated tests for that? Or did you just make sure everyone installed the same version with a requirements.txt file?

Anaconda has a better tool for cloning identical environments as long as both machines are on the same OS: https://conda.io/docs/user-guide/tasks/manage-environments.h...

In theory, pip lets you do this with pip freeze, but I found that pip often broke on some finicky libraries, while Anaconda failed much less frequently (though still has occasional issues.) The main drawback is the same OS requirement – this makes it harder to e.g. develop on a mac and then launch a pipeline on an Ubuntu machine in AWS.

What do you mean by "same OS requirement"? Can't you take your environment.yml from a Mac and recreate the environment on Linux?

Anaconda has two environment-copying tools, one is environment.yml (which is analogous to pip's requirements.txt), and the other is the "explicit" spec file, which actually points to specific files for specific packages. I've found environment.yml to fail with finicky libraries, same as requirements.txt, while the explicit spec file almost always works.

Many data scientists want to operationalize their models. If you don't work at a hip startup with a killer dev ops team, then you are likely at a big enterprise shop where relying on anyone else to handle your infrastructure for you is a great way to have 90% of your work never see the light of day.

I use Docker daily for my needs. It ensures that I can easily prototype a scalable set of services on my local machine, and then deploy it to a multi-node environment on AWS, Gcloud, or our on-prem infrastructure. Good luck developing a Redis-backed ML app without Docker when it comes time for deployment. You'll get it done, but it'll be a lot slower and more difficult than if you had used Docker or containers of some sort.

Edit: Make sure to check out Yhat. https://www.yhat.com/

Huh, that's surprising. I would have thought that working at a big enterprise shop, you'd have enough dev ops engineers to help you deploy your model, and it's the small startups that can't afford to do that.

I set up Kubernetes to deploy Docker containers, and it took a little while to wrap my head around it. What's the painful part of doing the deploy with Docker like you've been doing?

I would agree, most data scientists are not required to deploy their own models, probably only for those in startups or small companies. I also introduce how Docker can be used for development. I think it is a big enough trend in CS that any data scientist should know some basics, similar to data science from the command line.

It seems like the baseline of DS skill sets is all over the place, depending on where you started off.

I would have thought most DS wouldn't be interested in learning docker just to deploy. But then again, I could be wrong. What made you write the post? Was it because you saw lots of DS wanting to deploy, or something else?

i'm not a data scientist, but i have several on my team. In my experience,(as your question suggests) the interest is quite low, particularly given how much knowledge is required to do so that would otherwise be out of scope

building the model and packaging it for deployment are two completely different sets of tasks, are they not?

much more useful, again in my experience, is a tool like vagrant, which allows a production environment to be provisioned onto a VM; said VM is then run from the data scientist's desktop (eg, so they can do their work with the same versions of the same tools available in prod)

deployment is not the only reason. distributed ml (not deepmind scale but we're still talking about several instances, usually for something like hyperparameter tuning) is fairly common in practice. without docker, id waste most of my time provisioning and getting things to work - even if it's just for myself!

Reply on news.ycombinator.com