Nick Elprin, Domino Data Lab Demo, SF Scala @Nitro 20150205
Recording: Nick Elprin, Domino Data Lab Demo, SF Scala @Nitro 20150205
so um like alexi mentioned at the beginning i'm nick by the way i work with chris uh like alexis mentioned in the beginning um uh we sort of weren't prepared to talk about the product or do a demo and so uh but i've sort of reluctantly agreed so i'll try to keep it brief i'll do a kind of a whirlwind tour in about 10 minutes to tell you a little bit about the problems that are motivating what we're doing so uh it's the backdrop which a lot of this may be obvious to a lot of people in this room but you know the world is getting more analytical um and what i think that means in particular is people are realizing that the old world model of pointing a bi tool at a database and just like querying data looking at data querying data looking at data doesn't scale to more sophisticated kinds of questions and kinds of work that people want to do so when you talk about predictive models or much more sophisticated attribution to explain why you're seeing certain behavior you need you need code to answer those questions so you need to do data science in something like python or r or scala and what we observed is that a lot of organizations trying to do that work don't have the analogous infrastructure that they have for software engineering that lets them um follow best practices collaborate effectively share their work scale up the actual work they're doing to sort of uh run things at scale and so that's broadly the the problem or the constellation of problems we're trying to address with domino it's sort of a platform for uh analysis at an enterprise scale and it can sit and so if you can deploy in the cloud you can deploy on-premise behind your firewall and i'll go through kind of the pillars of functionality so the first the first thing just to kind of understand what is all happening here you make projects in domino and a project looks a lot like a git repo so the first thing it has it has a bunch of files and these files get mirrored or manifest materialized on a folder on your computer and there's a command line client to control that synchronization one of the first things that's different about what we've done is domino projects track large files whereas git will kind of fall down with about 100 megs wasn't it was designed for code domino will handle basically as much as your network transfer can handle so if you're going back and forth to the cloud typically that means 30 40 gigs if you're on premise it's a lot faster and we'll keep a fully revisioned history of all your data in your project folder yeah so um so we got files that's all pretty basic stuff where things get interesting is that in addition to storing files we can run your code really easily and so the demo i'll do uses um well we can run kind of any language but i've got a demo prepared in python that i'll do because it's easy and the idea here is this uses um i know that text is big enough this is uh it's using it's a scikit-learn example so it does some topic classification on writer's articles and we pass in a parameter at the command line that's the number of documents to use in our validation set and then we generate some charts that show prediction times and training times and whatever and the idea here is you work locally on your machine we're not an ide we didn't want to be rebuilding an ide and you can run this particular file and i mentioned the particular file takes a parameter so i can pass that in it's just like running python of the command line but instead of running it on your machine what it does is it packages up any changes you've made it ships it off to a cluster either our cloud cluster or a cluster behind your firewall and it starts executing that code and so you'll see in a second you see this new sort of task queued up here and it's going to crank through and it's running on whatever hardware i picked what's nice about this is each of these experiments we kick off runs in parallel on its own machine so i can sort of try a couple different things at once and we handle spreading them out around around the machines available to you so it can you can parallelize your model development and and speed that up and then what we do is we keep a record of not just the version of your code and data that ran but also the results that generate that were generated so this particular run here produced these results which are going to be some charts that we were expecting this one that finished a second later generated some charts that'll be slightly different because they had a different parameter and take a second to so um so you know two different versions and we can kind of compare them and then this is all stored centrally so it's shareable it makes for a great reporting features we can render arbitrary html if you generate you know things that include widgets or whatever so that's um that's kind of how we think about version control and this iterative experimental workflow where you run something and you want a record of what you did and the results are produced and you want to see that that revision history over time and what we've kind of we're working on now you saw chris so you can start up you can run notebooks on on the remote hardware as well and we'll keep records of what you do there and we just added the scala notebook support i was also going to show running scala code as scripts which is just just have this in dev right now it'll get released at some point but the simple example i'll show you we just generate a random number and print something out so this is real this is a really early proof of concept but the idea here is i can run that scala code oops and uh it encues it on the server and runs it there and there's there's our output so the final thing i wanted to show about this is what i like to think of is like the end of an analytics project life cycle where you've developed something and you want to actually integrate it into your business process typically you want to deploy it in some way so that existing software systems or automated workflows can use it and our approach to doing that because we've already got your code stored centrally and we've got the ability to run arbitrary code on scalable machines so what we've done is we've added the ability to expose your code as a web service and i'll show you an example here so right now we can do this in our python and the problem we see a lot is people build predictive model data scientists build predictive models in one of these languages and software engineers need to consume them in a general purpose language for their application that could be scholar java or net or ruby or whatever and that communication either there's some painful work to translate the model or there's organizational friction involved in getting the dev team to actually do the work to integrate the data science model so we think web services are really nice layer to act as an interface between the two the way this works is you specify a file and a function in that file i'll do in python here and so this code in my project uses a um sort of a classifier that i've already trained and i've just saved as a pickle file and so we can train this on our large machines for running longer running tasks and then you know predict function just uses that to call predict on the features that i pass into this function so i specify those two things i hit publish and that basically stands up an in-memory python process on a web server it runs any initialization code and it sits around and waits for incoming http requests when those come in it'll pull the parameters out of the request it'll pass them into the function you specified and run your code and return the results as jason and it does this nice thing where it won't switch over to your new release until you uh until it's fully ready and initialized this is all tied into version control as well so you get the history of the releases you've done so we've published that and we can just kind of show you that it works this uses a the model i've deployed here predicts wine quality from some chemical features like ph and residual sugar so that's the end point i'm going to hit i pass in a feature vector and um that runs we've designed this to be very low latency to work in sort of real-time production settings and returns some metadata but the real interesting thing i care about is the result that my code calculated and that's that's the basic idea so um so language agnostic kind of run scale track share and deploy work designed around data science workflows and um up to now we've mainly focused on our pythons to matlab but uh increasingly hearing more interest in scala so working in that direction um yeah so i think the question is basically what's the advantage of um this this last feature i showed this api endpoints or deploying your models as our python is that like what what i guess what you said was this is a place where developers uh can interface with data scientists yeah yeah so my question is does this environment translate or is it no no it puts a web service interface in front of the code so a software engineer say say you're working on an application in java or c-sharp or whatever uh instead of having to translate code from python you can just call a web service so this web service becomes a nice clean interface and then behind that interface your data scientists can update models they can change the underlying implementation they can deploy updates whenever they want so it's removing a bottleneck it's sort of freeing up data scientists to deploy their models without having to go through software engineers saying that the data scientist right yeah as long as like the so the software engineering team writes once something that hits a web service and then that's the interface is in place any other questions yeah um so uh when you make your http request there are you have um post parameters and we pass those into your function as positional arguments um so if you pass three parameters in your post request those get passed in as the first second third arguments to your function um uh well that yeah that's part of the interface you're agreeing upon i guess i mean or maybe i'm not sure i follow um that's right yeah it's not enforced and tactically yeah because i mean it's a yeah it's a http request so i don't yeah all right thanks guys you