Staying on Top of and Poking into Things

H2O is well-documented, so http://docs.h2o.ai should be your first port of call. The latest user guide is at http://docs.h2o.ai/h2o/latest-stable/h2o-docs/index.html.

If you want to see if, say, any new parameters have been added to GBM, you could go to the REST API Reference, then find GBMParametersV3. Alternatively, regularly check Changes.md over on the GitHub site!

If you wanted to see how GBM is implemented in Java you would start at the Javadocs, find "hex.tree.gbm,” then "GBM.” The corresponding code will be over on Github.

Random forest is called DRF in the REST endpoints, and hex.tree.drf in the Java source; everything else is fairly much named how you would expect.

Installing the Latest Version

Installing from packages, as shown back in the first chapter (“Install H2O with R (CRAN)” and “Install H2O with Python (pip)”) is going to be good enough for most people. However, installing the latest stable version (or even the latest bleeding-edge version) is not that much harder.

Unfortunately the latest versions do not have nice aliases, like “stable” and “nightly,” so I cannot just give you some instructions to copy and paste; it changes with each release. Instead, go to the H2O download page, click the link for the latest stable release of H2O, and follow the instructions for either R or Python there.

Instead, go to the H2O R download page or the H2O Python download page and follow the instructions given there.

Running from the Command Line

Throughout the book we have let our R or Python client start H2O for us. This is the easiest way, and also makes sure the versions are compatible.

But if the client finds H2O is already running, it will happily connect to that running instance. Starting H2O separately like this has some advantages. The main one is stability. When you close your client it closes H2O for you, too. If you only ever have one client, and you never need H2O running when that client is closed, that is just what you want; if not, it will cause problems!

The following example shows how to start H2O with 3GB of memory, on the local IP address and default port:

java -Xmx3g -jar /path/to/h2o.jar

The other reasons for using the command line usually have to do with starting clusters on a remote server. You can get help on all the current command-line options with:

java -jar /path/to/h2o.jar --help

If you need to pass authentication details to S3 or HDFS, you can specify "core-site.xml" like this:

java -jar h2o.jar -hdfs_config core-site.xml

See the documentation on what should go inside that XML file.

I mentioned in “Privacy” that H2O calls Google Analytics to record which versions are being used. If you need to opt out, the command-line argument -ga_opt_out is an alternative to creating the .h2o_no_collect file in your home directory:

java -Xmx3g -jar /path/to/h2o.jar -ga_opt_out

Clusters

H2O data structures, and its algorithms, have been built with clusters in mind, rather than as an afterthought. Even so, there are a few restrictions with H2O clusters:

• Each H2O node on the cluster must be the same size. So if the smallest machine in your cluster has 3GB free, every node must be given 3GB, even if some of them have 64GB.¹

• Machines cannot be added once the cluster starts up.

• If any machine dies, the whole cluster must be rebuilt.² No high availability support.

• Each node must be running the same version of h2o.jar. (And if you are planning to control the cluster from, say, an R client, then that also must be running the same API version as your h2o.jar.)

• Nodes should be physically close, to minimize network latency.

For more than one of those reasons, you should favor a few big nodes over lots of small nodes. And for models that take many hours to create, use regular checkpoints (see “Checkpoints” in Chapter 4) and model-saving (see “Model Files” in Chapter 2).

An H2O cluster can be created in one of two ways:

Flatfile

A simple textfile giving the IP address and port of each node in the cluster. You must prepare this file identically on each machine. You specify it when starting h2o.jar with -flatfile myfile.txt.

Auto-discovery

If you specify -network 192.168.1.0/24 when starting h2o.jar, then it will hunt through that subnet to find all nodes and join them together in a cluster. This is slower than the flatfile, but saves you having to create that file and upload it to every node beforehand.

You can also give your cluster a name, and specify this name when starting on each node. I recommend you do this (and name your flatfile with the same name). It becomes essential if you want to run two or more clusters on the same subnet.

You have a few minutes to get all the nodes started before the first one will complain and shut down. However, as soon as a client (R, Python, Flow) connects to any node in the cluster, the cluster will lock down, and no further nodes can be added.

To connect to your cluster, just use h2o.init() giving the IP address of any node. There is no master node; they are all equal peers. However, the first node listed in the cluster status (get it from Flow, h2o.clusterStatus() in R, or h2o.cluster_status() in Python) sometimes has special status when it comes to importing or exporting data or models. And sometimes it is the node your client is connected to. I recommend you connect to the first node when you plan to be using the local filesystem for import or export, to avoid any confusion.³ For importing data, the data has to be visible by all nodes in the cluster, which generally means you will need to have a copy on each node, in exactly the same place. I find it easier to be using S3 or HDFS. Alternatively, run your R or Python client on the node that has the data, and use upload file instead of import file.

securityGroupName = 'for_h2o'

Spark / Sparkling Water

In some ways Spark and H2O are competing products: they are both about analyzing Big Data, in-memory. However, each has its strengths,⁶ and “Sparkling Water” is a way to get them to work together closely so you can get the best of each world. There are versions for Spark 2.0, 1.6, 1.5, 1.4, and 1.3.

Sparkling Water is run as a regular Spark application. You run the H2O functions using Scala.⁷ Once the data is inside an H2O data frame, it can be shared with Spark functions, without involving a memory copy (using the asRDD() or asDataFrame() functions).

To learn more about Sparkling Water, the best resources are the booklet, which can be found at http://docs.h2o.ai or directly at http://bit.ly/2g2zfJg, and then the directory of examples on GitHub.

Naive Bayes

There is another supervised machine-learning algorithm, naive bayes. I didn’t look at it in the main section of the book, as it is a bit more limited, with binomial and multinomial classifications only, and not so many parameters, and well, basically, there wasn’t enough space to include everything.

Naive bayes is often associated with NLP (Natural Language Processing) applications, such as spam recognition or sentiment analysis. But, to get you started, Example 10-1 is the iris example from the first chapter (“Our First Learning”), done with naive bayes instead of deep learning.

library(h2o)
h2o.init(nthreads = -1)

datasets <- "https://raw.githubusercontent.com/DarrenCook/h2o/bk/datasets/"
data <- h2o.importFile(paste0(datasets",iris_wheader.csv"))
y <- "class"
x <- setdiff(names(data), y)
parts <- h2o.splitFrame(data, 0.8)
train <- parts[[1]]
test <- parts[[2]]

m <- h2o.naiveBayes(x, y, train)
p <- h2o.predict(m, test)

That manages the same 28 out of 30 score I got in the first chapter, so naive bayes is certainly not an algorithm just for NLP applications. Your next stop should be the API documentation (it is supported from R, Python, and also Flow).

Ensembles

Imagine you are putting together a team of three for a quiz night. Further, imagine that you are a god when it comes to Python, are rather good at math and physics, think sports are for losers, and don’t even own a TV, preferring to play online video games. For some of you that will require a lot of imagination, I’m sure. One option, what with you being so clever, is to just enter the quiz night solo. Alternatively, you could invite Bob (an R guy, but on the plus side he is better at statistics and League of Legends than you) and Betsy (she studied chemistry, but she is not so bad as she uses Python and you like the same video games) to be in your team, the Brainy Boffins. Or should you invite your brother-in-law, Viv, who is a lawyer and always watching the TV news and shouting at politicians to clean up their act; and old school friend, Valerie, who knows everything about hockey, football, and half a dozen other sports, and can also tell you who performed at the Super Bowl halftime show, every year, for the past 20 years? Valerie can be very boring.

I hope you chose wisely. This is the basic idea behind ensemble algorithms: a group of algorithms, conferring over their final answer, is better than a single algorithm, because it can balance out the weaknesses and oversights. And the greater the differences between the algorithms, the better.

Having decided to use an ensemble you have three main decisions to make:

• Whether to use a library, or roll your own

• What member models

• How to combine their results

Taking them in order: H2O has an ensemble package; it doesn’t come with H2O, so you need to install it separately. It only supports R currently.

You could make your member models by training the best model for each algorithm. An alternative approach is to run a random grid search over a wide range of parameters, and choose the best few models that have a good diversity of model parameters. For example, if your top-two deep learning algorithms had different network layouts, one with (200,200) hidden layers, and the other with (50,40,40,40), then they are likely to be useful ensemble members, as they will be seeing the world in different ways.

To combine results, you could take a page out of random forest’s book: use averaging for regression, and use the most common result for categorization. Or you could use any supervised learner introduced in this book, to take take the output of each member model, and decide the ensemble’s output.

library(h2oEnsemble)

source("load.building_energy.R")

RFd <- h2o.randomForest(x, y, train, model_id="RF_defaults", nfolds=10,
  fold_assignment = "Modulo", keep_cross_validation_predictions = T)
GBMd <- h2o.gbm(x, y, train, model_id="GBM_defaults", nfolds=10,
  fold_assignment = "Modulo", keep_cross_validation_predictions = T)
GLMd <- h2o.glm(x, y, train, model_id="GLM_defaults", nfolds=10,
  fold_assignment = "Modulo", keep_cross_validation_predictions = T)
DLd <- h2o.deeplearning(x, y, train, model_id="DL_defaults", nfolds=10,
  fold_assignment = "Modulo", keep_cross_validation_predictions = T)

models <- c(RFd, GBMd, GLMd, DLd)

m_stack <- h2o.stack(models, response_frame = train[,y])
h2o.ensemble_performance(m_stack, test)

Base learner performance, sorted by specified metric:
       learner      MSE
3 GLM_defaults 9.013281
4  DL_defaults 7.651445
1  RF_defaults 3.626491
2 GBM_defaults 2.547896

H2O Ensemble Performance on <newdata>:
Family: gaussian

Ensemble performance (MSE): 2.55156175744006

Base learner performance, sorted by specified metric:
       learner      MSE
1  RF_defaults 3.626491
2 GBM_defaults 2.547896

H2O Ensemble Performance on <newdata>:
Family: gaussian

Ensemble performance (MSE): 2.51780794131118

predict         Iris-setosa  Iris-versicolor  Iris-virginica
-----------     -----------  ---------------  --------------
Iris-setosa     0.999016     0.0009839        1.90283e-19
Iris-setosa     0.998988     0.0010118        1.40209e-20
...
Iris-virginica  1.5678e-08   0.3198963        0.680104
Iris-versicolor 2.3895e-08   0.9863869        0.013613

predictTeam <- function(models, data){
probabilities <- sapply(models, function(m){
  p <- h2o.predict(m, data)
  as.matrix(p[,setdiff(colnames(p), "predict")])
  }, simplify = "array")
apply(probabilities, 1, function(m) which.max(apply(m, 1, sum)) )
}

Summary

Well, that was a whirlwind tour of some things I didn’t have space in the book to go into in more detail. The next chapter, the final one in this book, will bring together all the results of the supervised learning experiments on each of the three data sets, and also give some ideas for what to do when they are not good enough.