Here, I'm quickly going to talk about MOJOs and POJOs. And mostly, I'm going to refer you to the manual, if you want to learn more. So, if you come to the manual and scroll down. Productionizing H2O, there's a section about POJOs and MOJOs. POJO is a plain old Java object. And the MOJO, they've squeezed some kind of, naming out of it. But it's just an enhanced version for really large models. The MOJO is also quicker. So, you should normally use a MOJO if it's available. The idea is your going to make a Java program, you're going to bring in the H2O-genmodel jar file along with the POJO or MOJO that you've exported. And you will then use this in production. And the manual goes into some quite a bit of detail about different design patterns to use these files. You can also export a model in a binary format. There's a couple of restrictions there. You need to be using exactly the same H2O version. And also, you will be running H2O as a server. The advantage of doing this way though, is you can carry on using your R, or Python or other language API. So when you want to productionize H2O, come and read this for the latest information. I'm just going to quickly jump into first Python and then R to show you what these look like. So I've gotten GBM model in m_GBM. And I can call save MOJO on it. And I give the directory to save it into. There's function, "download_mojo" which does exactly the same. And the but it tells me, the name of the model it's saved to. With a GBM, I've got the choice of MOJO or POJO. So, you can see it's made that. If we just jump over to a directory. The MOJO is 200k, the POJO, the Java object is 500 k. This was a simple default GBM model. So, theoretically they're going to get a lot bigger. You can also save muddled details. This has created a very large JSON object. Let's open it with RStudio. This is the same information that the flow interface stores about your model. So, you may find it useful, because the weights are in there, the training information is in there. Some information is in there. Basically, that isn't exported with your MOJO or POJO, but is kept in the binary model. So, that's where that might come in. And finally, for comparison you can save the binary model. Just a note at the moment, it's not available on the model object. So instead you use H2O save model, your model, and again the path. And that's 200K file, a binary file. And you load that back into H2O, with H2O, Load, Model, and then this file name. Okay, and I can now do M2, And I have the exact same model back in, with the same model ID it originally had. When you're using stacked ensembles, this is following on from our stacked ensemble video where I have an ensemble of a GLM, GBM and random forest in MSE. This function certainly isn't implemented at the moment, but you can save a binary model. And that's 13.6 megabytes. So, I believe this is including all three sub models and the cross validation information. And again, you can load that back in with load model. Just quickly take a look in R at these functions. So theise to save model, to save the binary version. H2O, download_ Pojo, to get the POJO. And by default it will also get this genmodel Jop Jar file for you. You probably don't want that every time so specify get Jar is false. Download_ Mojo to get the MOJO version. And again, for stacked ensembles you have to use save model currently.
